Мотивація

При швидкості сигналу 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 нас і починається з пакету Start-Of-Frame (SOF) і обмежений послідовністю End-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 B / s = 53,248 Мб / с

Для абсолютно випадкових даних ми очікуємо, що розряд бітів необхідний в одній із 2 ** 6 = 64 послідовностей з 6 послідовних біт. Це збільшення (63 * 6 + 7) / (64 * 6). Помноження всіх байтів, які підлягають набиванню бітів на ці числа, дає загальну довжину транзакцій (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 байт. Це призводить до отримання 13.932 пакетів на Micro-Frame.

У цих розрахунках відсутній ще один особливий випадок. Стандарт визначає максимальний час реакції пристрою в 192 бітних разів [ 2 , глава 7.1.19.2]. Це потрібно враховувати, вирішуючи, чи останній пакет все-таки вписується в кадр, якщо пристрою потрібен повний час відгуку. Ми могли б це пояснити, скориставшись вікном 7439 байт. Хоча отримана смуга пропускання однакова.

Що залишилося

• Виявлення помилок та відновлення не висвітлено. Можливо, помилки є досить частими або відновлення помилок займає багато часу, щоб вплинути на середню продуктивність.

• Ми припустили миттєву реакцію хоста та пристрою після пакетів та транзакцій. Я особисто не бачу необхідності великих завдань з обробки в кінці пакетів або транзакцій з обох боків, і тому я не можу придумати жодної причини, чому хост або пристрій не зможуть миттєво реагувати на достатньо оптимізованих апаратних реалізаціях. Особливо в звичайній роботі більшість робіт із зберігання книг та виявлення помилок можна проводити під час трансакції, а наступні пакети та транзакції можуть бути в черзі.

• Трансфери для інших кінцевих точок або додаткового зв'язку не враховувалися. Можливо, стандартний протокол для пристроїв зберігання даних вимагає деякого безперервного зв'язку з бічними каналами, який забирає цінний час слота.

• Можливо, додаткові накладні протоколи для пристроїв зберігання даних для драйвера пристрою або рівня файлової системи. (завантаження пакета == дані для зберігання?)

Питання

• Чому сьогоднішні реалізації не здатні передавати поточну передачу зі швидкістю 53 Мб / с?

• Де вузьке місце в сьогоднішніх реалізаціях?

І потенційне спостереження: чому ніхто не намагався усунути таке вузьке місце?

Список літератури

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

[2] Швидке дзеркало у форматі PDF

У якийсь момент свого життя я використовував USB-бізнес для великої напівкомпанії. Найкращий результат, який я пам’ятаю, - це контролер NEC SATA, здатний висувати фактичну пропускну здатність 320 Мбіт / с для масового зберігання, ймовірно, поточні накопичувачі sata здатні на це або трохи більше. Для цього використовували BOT (деякий протокол масового зберігання працює на USB).

Я можу дати технічну детальну відповідь, але, мабуть, ви можете зробити висновок самостійно. Що вам потрібно побачити, це те, що це гра в екосистему, будь-яке суттєве вдосконалення вимагатиме від когось, як Microsoft, змінити свій стек, оптимізувати і т.д., що не відбудеться. Сумісність є набагато важливішою, ніж швидкість. Оскільки існуючі стеки ретельно висвітлюють помилки набору пристроїв там, тому що, коли специфікація USB2 виходила, ймовірно, початкові пристрої насправді не підтвердили специфікацію, що добре, оскільки специфікація була баггі, система сертифікації була помилковою тощо. Якщо ви будуєте систему домашньої варіння за допомогою Linux або користувальницьких драйверів USB для MS та швидкого контролера пристроїв, можливо, ви можете наблизитися до теоретичних меж.

Що стосується потокової передачі, ISO повинна бути дуже швидкою, але контролери не дуже добре реалізують, оскільки 95% додатків використовують групову передачу.

Наприклад, як бонусне розуміння, наприклад, якщо ви сьогодні підете і побудуєте ІМ-центр концентратора, якщо ви будете дотримуватися специфікації до крапки, ви практично продаєте нульові фішки. Якщо ви знаєте всі помилки на ринку і переконайтеся, що ваш концентратор IC може терпіти їх, ви, ймовірно, можете потрапити на ринок. Я і сьогодні вражений тим, наскільки добре працює USB, враховуючи кількість поганого програмного забезпечення та мікросхем.

Це дуже стара тема, але відповіді поки немає. Це моя спроба:

Чому сьогоднішні реалізації не здатні передавати поточну передачу зі швидкістю 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.

Де вузьке місце в сьогоднішніх реалізаціях?

Як можна бачити вище, не існує перешкод, весь необроблений простір часу витрачається на протокол.