мотивация
При скорости передачи 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 МБ / с?
Где узкое место в сегодняшних реализациях?
И потенциальное продолжение: почему никто не пытался устранить такое узкое место?
Ответы:
В какой-то момент в моей жизни я управлял бизнесом USB для большой компании. Наилучшим результатом, который я помню, был контроллер SEC NEC, способный выдавать фактическую пропускную способность 320 Мбит / с для хранения данных, вероятно, современные накопители SATA способны на это или чуть больше. Это было с использованием BOT (некоторый протокол запоминающего устройства работает на USB).
Я могу дать технический подробный ответ, но я думаю, что вы можете сделать вывод сами. Что вам нужно увидеть, так это то, что это игра экосистемы, любое существенное улучшение потребовало бы от кого-то, как Microsoft, изменения своего стека, оптимизации и т. Д., Чего не произойдет. Функциональная совместимость гораздо важнее, чем скорость. Поскольку существующие стеки тщательно скрывают ошибки множества устройств, потому что, когда выйдет спецификация USB2, вероятно, начальные устройства действительно не подтвердили спецификацию, что хорошо, так как спецификация была глючной, система сертификации глючила и т. Д. И т. Д. И т. Д. Если вы строите систему домашнего приготовления, используя Linux или пользовательские драйверы USB-хоста для MS и быстрый контроллер устройства, вы, вероятно, приблизитесь к теоретическим пределам.
С точки зрения потоковой передачи ISO должен быть очень быстрым, но контроллеры не очень хорошо это реализуют, так как 95% приложений используют пакетную передачу.
Например, если вы поймете, что если вы пойдете сегодня и построите IC-концентратор, если будете следовать спецификации до точки, вы практически продадите ноль фишек. Если вы знаете все ошибки на рынке и уверены, что ваша центральная микросхема может их терпеть, вы, вероятно, можете попасть на рынок. Сегодня я все еще поражаюсь, насколько хорошо работает USB, учитывая количество плохого программного обеспечения и микросхем.
источник
Это очень старая тема, но пока нет ответа. Это моя попытка:
Вычисления почти идеальны, но вы забыли пару вещей в доступном количестве байтов между маркерами кадра:
Каждый микрофрейм имеет два порога, называемых EOF1 и EOF2. Активность шины не должна происходить в / после EOF1. Размещение этой точки - сложная вещь, но типичная позиция - 560 битных раз перед следующей SOF. Хост должен планировать свои транзакции таким образом, чтобы любой возможный ответ канала не достиг этого порога. Который съедает около 70 байтов из ваших рассчитанных 7487 байтов.
Вы принимаете «случайные данные». Это совершенно необоснованно, данные могут быть чем угодно. Поэтому хост должен планировать транзакции для наихудшего полезного груза с максимальными издержками на вставку битов, 512 * 7/6 = ~ 600 байт. Плюс 24 байта накладных расходов транзакции, как вы правильно рассчитали. Это дает (7487-70) / 624 = 11,88 транзакций на микрокадр.
Хост должен зарезервировать около 10% пропускной способности для контрольных транзакций для любой другой деятельности, поэтому мы получаем около 10,7 транзакций.
Хост-контроллер также имеет определенную задержку при управлении своим связанным списком, поэтому между транзакциями существует дополнительный разрыв.
Устройство может находиться в 5 концентраторах / прыжках вдали от корня, а задержка ответа может составлять до 1700 нс, что потребляет еще 106 байтов бюджета каждой транзакции. По предварительным оценкам, он совершает только 10,16 транзакций на каждый фрейм, не считая зарезервированной полосы пропускания.
Хост не может выполнять адаптивное перепланирование на основе фактического поступления транзакции в uFrame, это было бы непомерно с точки зрения программного обеспечения, поэтому драйвер использует наиболее консервативный график, до 9 массовых транзакций на uFrame, что составляет 36 Мбайт / второй. Это то, что может дать очень хороший USB-накопитель.
Некоторые сумасшедшие искусственные тесты могут выполнять до 11 транзакций на uFrame, что составляет 44 МБ / с. И это абсолютный максимум для протокола HS USB.
Как видно из вышесказанного, ботлэнк не существует, все необработанное битовое пространство используется служебными данными протокола.
источник