мотивация
При скорости передачи 480 Мбит / с устройства USB 2.0 должны иметь возможность передавать данные со скоростью до 60 МБ / с. Однако современные устройства, кажется, ограничены 30-42 МБ / с при чтении [ Wiki: USB ]. Это 30 процентов накладных расходов.
USB 2.0 является стандартом де-факто для внешних устройств уже более 10 лет. Одним из наиболее важных приложений для интерфейса USB с самого начала было портативное хранилище. К сожалению, USB 2.0 быстро стал узким местом, ограничивающим скорость для этих приложений, требующих пропускной способности. Сегодняшний жесткий диск способен, например, поддерживать последовательное чтение со скоростью более 90 МБ / с. Учитывая длительное присутствие на рынке и постоянную потребность в более высокой пропускной способности, следует ожидать, что эко-система USB 2.0 была оптимизирована за эти годы и достигла производительности чтения, близкой к теоретическому пределу.
Какова теоретическая максимальная пропускная способность в нашем случае? Каждый протокол имеет служебную нагрузку, включая USB, и в соответствии с официальным стандартом USB 2.0 он составляет 53,248 МБ / с [ 2 , таблица 5-10]. Это означает, что теоретически современные устройства USB 2.0 могут быть на 25 процентов быстрее.
Анализ
Чтобы приблизиться к корню этой проблемы, следующий анализ продемонстрирует, что происходит на шине во время чтения последовательных данных с устройства хранения. Протокол разбивается слой за слоем, и нас особенно интересует вопрос, почему 53.248 МБ / с является максимальным теоретическим числом для массовых восходящих устройств. Наконец, мы поговорим об ограничениях анализа, которые могут дать нам некоторые намеки на дополнительные издержки.
Заметки
В этом вопросе используются только десятичные префиксы.
Хост USB 2.0 способен обрабатывать несколько устройств (через концентраторы) и несколько конечных точек на устройство. Конечные точки могут работать в разных режимах передачи. Мы ограничим наш анализ только одним устройством, которое напрямую подключено к хосту и способно непрерывно отправлять полные пакеты через объемную конечную точку восходящего потока в высокоскоростном режиме.
обрамление
Высокоскоростная связь USB синхронизируется в фиксированной рамочной структуре. Каждый кадр имеет длину 125 мкс и начинается с пакета начала кадра (SOF) и ограничен последовательностью конца кадра (EOF). Каждый пакет начинается с SYNC и заканчивается и End-Of-Packet (EOF). Эти последовательности были добавлены к диаграммам для ясности. EOP является переменным по размеру и зависит от пакетных данных, для SOF это всегда 5 байтов.
Откройте изображение в новой вкладке, чтобы увидеть увеличенную версию.
операции
USB является ведущим протоколом, и каждая транзакция инициируется хостом. Временной интервал между SOF и EOF может использоваться для транзакций USB. Однако время для SOF и EOF очень строгое, и хост инициирует только транзакции, которые могут быть полностью завершены в течение свободного временного интервала.
Транзакция, в которой мы заинтересованы, - это успешная массовая транзакция. Транзакция начинается с входного пакета токена, затем хосты ожидают пакет данных DATA0 / DATA1 и подтверждают передачу с помощью пакета квитирования квитирования. EOP для всех этих пакетов составляет от 1 до 8 бит в зависимости от данных пакета, мы предположили наихудший случай здесь.
Между каждым из этих трех пакетов мы должны учитывать время ожидания. Они находятся между последним битом пакета IN от хоста и первым битом пакета DATA0 устройства и между последним битом пакета DATA0 и первым битом пакета ACK. Нам не нужно учитывать дальнейшие задержки, так как хост может начать отправку следующего IN сразу после отправки ACK. Время передачи по кабелю не должно превышать 18 нс.
Массовая передача может отправлять до 512 байтов за транзакцию IN. И хост попытается выполнить как можно больше транзакций между разделителями кадров. Несмотря на то, что массовая передача имеет низкий приоритет, она может занимать все доступное время в интервале, когда нет других ожидающих транзакций.
Чтобы обеспечить правильное восстановление тактовой частоты, стандарты определяют заполнение битов вызова метода. Когда пакету потребуется очень длинная последовательность того же вывода, добавляется дополнительный фланг. Это обеспечивает фланг после максимум 6 бит. В худшем случае это увеличит общий размер пакета на 7/6. EOP не подлежит битовой начинке.
Откройте изображение в новой вкладке, чтобы увидеть увеличенную версию.
Расчет пропускной способности
Объемная транзакция IN имеет служебную нагрузку 24 байта и полезную нагрузку 512 байтов. Это в общей сложности 536 байтов. Временной интервал между ними составляет 7487 байт. Без необходимости вставки битов есть место для 13,968 пакетов. Имея 8000 микрокадров в секунду, мы можем читать данные со скоростью 13 * 512 * 8000 Б / с = 53,248 МБ / с.
Для полностью случайных данных мы ожидаем, что вставка битов необходима в одной из 2 ** 6 = 64 последовательностей из 6 последовательных битов. Это увеличение (63 * 6 + 7) / (64 * 6). Умножение всех байтов, которые подвергаются вставке битов на эти числа, дает общую длину транзакции (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 байта. В результате получается 13,932 пакета на микрокадр.
В этих расчетах отсутствует еще один особый случай. Стандарт определяет максимальное время отклика устройства 192 битных раза [ 2 , равное , глава 7.1.19.2]. Это необходимо учитывать при принятии решения о том, помещается ли последний пакет в кадр в случае, если устройству требуется полное время ответа. Мы могли бы объяснить это, используя окно из 7439 байтов. Результирующая пропускная способность, хотя и идентична.
То, что осталось
Обнаружение и устранение ошибок не покрывалось. Возможно, ошибки встречаются достаточно часто или устранение ошибок занимает достаточно много времени, чтобы оказать влияние на среднюю производительность.
Мы предположили мгновенную реакцию хоста и устройства после пакетов и транзакций. Лично я не вижу необходимости в больших задачах обработки в конце пакетов или транзакций с обеих сторон, и поэтому я не могу представить себе причину, по которой хост или устройство не смогут мгновенно реагировать с помощью достаточно оптимизированных аппаратных реализаций. Особенно при нормальной работе большая часть работы по учету и обнаружению ошибок может выполняться во время транзакции, а следующие пакеты и транзакция могут быть поставлены в очередь.
Переводы на другие конечные точки или дополнительное общение не рассматривалось. Возможно, стандартный протокол для устройств хранения требует некоторой непрерывной связи по побочному каналу, которая потребляет ценное время слота.
Могут быть дополнительные издержки протокола для устройств хранения для драйвера устройства или уровня файловой системы. (полезная нагрузка пакета == хранение данных?)
Вопрос
Почему сегодняшние реализации не поддерживают потоковую передачу со скоростью 53 МБ / с?
Где узкое место в сегодняшних реализациях?
И потенциальное продолжение: почему никто не пытался устранить такое узкое место?