Почему устройства USB работают медленнее 480 Мбит /с

Мотивация

При скорости передачи данных 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 us и начинается с пакета Start-Of-Frame (SOF) и ограничен и последовательностью After-Of-Frame (EOF). Каждый пакет начинается с SYNC и заканчивается и End-Of-Packet (EOF). Эти последовательности были добавлены к диаграммам для ясности. EOP является переменной по размеру и зависит от пакетных данных, для SOF всегда 5 байтов.

введите описание изображения здесь Откройте изображение на новой вкладке, чтобы увидеть большую версию.

Сделки

USB - это управляемый ведущим протоколом, и каждая транзакция инициируется хостом. Временной интервал между SOF и EOF может использоваться для транзакций USB. Однако время для SOF и EOF очень строгое, и хост инициирует только транзакции, которые могут быть полностью завершены в течение свободного временного интервала.

Сделка, в которой мы заинтересованы, является успешной транзакцией в объеме IN. Сделка начинается с точечного пакета IN, после чего хосты ожидают пакет данных DATA0 /DATA1 и подтверждают передачу с помощью пакета подтверждения ACK. 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 МБ /с?

  • Где узкое место в сегодняшних реализациях?

И потенциальное продолжение: почему никто не пытался устранить такое узкое место?

Ссылки

[1] Официальная спецификация USB 2.0

[2] Быстрое pdf-зеркало спецификации

37 голосов | спросил Chris 7 Jam1000000amSat, 07 Jan 2012 06:48:16 +040012 2012, 06:48:16

2 ответа


15

В какой-то момент в моей жизни я использовал бизнес USB для большой полукомпании. Наилучшим результатом, который я помню, был контроллер NEC SATA, способный нажимать фактическую пропускную способность 320 Мбит /с для массового хранения, возможно, текущие диски sata способны на это или немного больше. Это использовало BOT (некоторый протокол массового хранения работает на USB).

Я могу дать технический подробный ответ, но, я думаю, вы можете вывести себя. Что вам нужно увидеть, так это то, что это игра в экосистеме, любое значительное улучшение потребует от кого-то вроде Microsoft изменения своего стека, оптимизации и т. Д., Чего не произойдет. Совместимость намного важнее скорости. Поскольку существующие стеки тщательно покрывают ошибки множества устройств, потому что, когда спецификация USB2 появляется, вероятно, исходные устройства на самом деле не подтвердили спецификацию, так как спецификация была глючной, система сертификации была глючной и т. Д. И т. Д. Если вы построите систему домашнего приготовления с использованием Linux или пользовательских драйверов USB-хоста для MS и быстрого контроллера устройства, вы, вероятно, сможете приблизиться к теоретическим пределам.

С точки зрения потоковой передачи, ISO должен быть очень быстрым, но контроллеры не очень хорошо реализуют, так как 95% приложений используют массовую передачу.

В качестве бонусного понимания, например, если вы идете и строите IC-концентратор сегодня, если вы будете следовать спецификации до точки, вы практически будете продавать нулевые чипы. Если вы знаете все ошибки на рынке и убедитесь, что ваш IC-концентратор может их терпеть, вы, вероятно, сможете выйти на рынок. Сегодня я все еще удивляюсь, насколько хорошо работает USB, учитывая количество плохого программного обеспечения и чипов.

ответил Frank 7 Jam1000000amSat, 07 Jan 2012 09:29:48 +040012 2012, 09:29:48
3

Это очень старая тема, но ответа пока нет. Это моя попытка:

  

Почему сегодняшние реализации не способны передавать потоки со скоростью 53 МБ /с?

Вычисления почти прекрасны, но вы забываете пару вещей в доступном количестве байт между маркерами кадров:

  1. Каждый микрокадр имеет два порога, называемых EOF1 и EOF2. В /после EOF1 не должно происходить шум. Размещение этой точки - сложная вещь, но типичная позиция составляет 560 бит раз перед следующим SOF. Хост должен планировать свои транзакции таким образом, чтобы любой возможный ответ от канала не попадал в этот порог. Который ест около 70 байт из ваших расчетных 7487 байт.

  2. Вы принимаете «случайные данные». Это абсолютно необоснованно, данные могут быть любыми. Поэтому хост должен запланировать транзакции для полезной нагрузки наихудшего случая, с накладными расходами на максимальный бит, 512 * 7/6 = ~ 600 байт. Плюс 24 байта транзакционных издержек, как вы по праву рассчитали. Это дает (7487-70) /624 = 11,88 транзакций на микрокадр.

  3. Хост должен зарезервировать около 10% пропускной способности для транзакций контроля для любой другой деятельности, поэтому мы получаем около 10,7 транзакций.

  4. Контроллер хоста также имеет определенную задержку при управлении связанным списком, поэтому существует дополнительный разрыв между транзакциями.

  5. Устройство может быть 5 хабов /переходов далеко от корня, а отсрочка ответа может достигать 1700 нс, которая ест еще 106 байтов каждого бюджета транзакции. По предварительным подсчетам, он делает только 10,16 транзакций на uFrame, не считая зарезервированную полосу пропускания.

Хост не может выполнять адаптивное перепланирование на основе фактического поступления транзакций в uFrame, это было бы непомерно с точки зрения программного обеспечения, поэтому драйвер использует наиболее консервативное расписание, до 9 массовых транзакций на uFrame, что составляет 36 Мбайт /с. Это то, что может обеспечить очень хороший USB-накопитель.

Некоторые сумасшедшие искусственные тесты могут увеличиться до 11 транзакций на uFrame, что составляет 44 Мбит /с. И это абсолютный максимум для протокола HS USB.

  

Где узкое место в сегодняшних реализациях?

Как видно из вышеизложенного, нет лотка, все необработанное битовое пространство съедается служебными данными протокола.

ответил Ali Chen 20 MaramTue, 20 Mar 2018 07:32:24 +03002018-03-20T07:32:24+03:0007 2018, 07:32:24

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132