Перевага в швидкості, яке є у шини USB 3.0 в порівнянні з перед- шественніцей, загальновідомо. Але поки SuperSpeed-пристрою не ста-ли широко рас-про-стра-нен-ни-ми, давайте порівняємо їх з USB 2.0 ре-ше-ні-я-ми.
Предметом досліджень буде споживана потужність і тра-фік USB HCI-контролера.
Примітка. Термінологія, яка використовується в статті, стане більш дос-туп-ної, якщо попередньо ознайомитися з ма-те-ри-а-лом «Шина USB вимагає забезпечення сумісності».
Контролер EHCI завантажує шину
Зрозуміло, що обмін з периферійними USB-пристроями вимагає операцій на PCI-шині або внутрішньої шині на-бо-ра системної логіки. Набагато гірша ситуація виглядає тоді, коли, незалежно від наявності під-лю-чен-них пристроїв, запущений USB-контролер генерує трафік. Це архітектурний недолік реалізації USB 2.0, який не підлягає виправленню в силу ряду причин.
Переконатися в наявності шинного трафіку, ініційованого EHCI-контролером, можна спостерігаючи сигнали арбітражу Request і Grant на слоті PCI:
- REQ # (Request, контакт B18 слоти PCI) - запит до арбітра від bus-master пристрою;
- GNT # (Grant, контакт A17 слоти PCI) - підтвердження від арбітра для bus-master пристрою.
Якщо на будь-який із зазначених ліній є імпульси, це означає, що bus-master генерує трафік. Грамотніше на-блю-дати сигнал Grant, який повідомляє, що доступ надано. Але робити це слід строго в тому слоті, де встановлений контролер. Адже лінії Request і Grant розведені для кожного слота індивідуально.
Аналіз життєдіяльності USB 2.0 був би неповним, якби ми не проаналізували ситуацію з трафіком в сере-де операційних систем Microsoft. Виявилося, що Windows припиняє EHCI-контролер, якщо до нього не під-виключені периферійні пристрої. Але важливо те, що при наявності USB-пристрої трафік є завжди. неза-мо від того, чи відбувається передача даних чи ні.
Таким чином, в цілому, теза про неефективне трафіку підтверджується навіть в операційних системах. Але сле-ду-ет визнати, що драйверного підтримка Windows виявилася дещо розумніший, ніж очікувалося.
Чому ж EHCI так влаштований? Згідно зі специфікацією, його розробники прагнули до того, щоб звести спілкування драйвера з контролером до передачі інформації через оперативну пам'ять, використовуючи розклад транзакцій, періодично опитуване контролером. Це зроблено для того, щоб мінімізувати звернення драйвера до MMIO-регістрів контролера, тому що такі звернення займають більшу кількість тактів і збільшують утилізацію центрального процесора.
Як справи, xHCI?
Очевидно, що при розробці xHCI-контролера пріоритетом була економія електроенергії. Мета буде досягнута, якщо пристрій не стане постійно звертатися до оперативної пам'яті. Замість цього пропонується протокол, при якому драйвер готує блоки завдань в оперативній пам'яті (в кільцевому буфері, який називається CommandRing), після чого виконує запис в один з MMIO-регістрів блоку DoorbellRegisters. Запис в нього повідомляє xHCI-контролеру про підготовлений в оперативній пам'яті блоці завдань. І тільки після цього xHCI починає bus-master операції. Так контролер дізнається про нові завдання від драйвера, не звертаючись до RAM. У підсумку, споживана потужність контролера зменшується.
Неочевидні переваги обіцяють очевидні вигоди
Перевага EHCI перед xHCI в тому, що мінімізовано кількість операцій драйвера з MMIO-регістрами, що займає багато процесорних тактів.
Перевага xHCI перед EHCI в тому, що шинний трафік породжується виключно при виконанні завдань надійшли від драйвера, і в цьому випадку, xHCI економніше витрачає bus-master трафік.
Вказана обставина може призвести до необ'єктивності при вимірюванні утилізації процесора в системі з контролером xHCI:
- Зводячи результат до однієї цифри - утилізації процесора ми забуваємо про те, що EHCI-контролер використовує режим bus-master постійно, незалежно від наявності підключених пристроїв і завдань від драйвера. Це призводить до появи додаткового трафіку на шинах, що уповільнює роботу CPU, навіть тоді, коли в системі немає USB-пристроїв або пристрою є, але передачі даних не відбувається.
- Якщо ми вимірюємо утилізацію центрального процесора, оцінюючи, наскільки знизилася його продуктивність при виконанні операцій на USB, ми знову не враховуємо того, що для xHCI продуктивність процесора знижується тільки при виконанні завдань від драйвера.
Недоліки xHCI-контролера - витрата великої кількості тактів процесора при зверненні драйвера до MMIO регістру Doorbell - відразу видно. Його переваги - економія шинного трафіку в режимі очікування - при вимірах також бачиться як недолік, бо уповільнення процесора при USB-операціях в порівнянні з режимом простою занадто очевидні.
А недоліки EHCI нівелюються тим, що в ряді чіпсетів використовується режим кешування трафіку EHCI Caching (п.5.19.10 PCH Data Sheet для чіпсетів 8-ї серії і п.5.18.10 - для 7-ї серії). З його допомогою вдається уникнути доступу до оперативної пам'яті для ряду USB-операцій, що дає можливість знизити навантаження на шину. Додатковий бонус застосування EHCI Caching - використання енергозберігаючого стану процесора і оперативної пам'яті, не дивлячись на bus-master активність EHCI.
Якщо врахувати, що подібні поліпшення відбулися в процесі зміни поколінь чіпсетів, перспектива для зростання USB 3.0 більш райдужна. На порядку денному оптимізація шинної архітектури і використання механізмів відкладеного запису для регістра Doorbell, які допоможуть нівелювати наявний недолік xHCI шляхом скорочення кількості процесорних тактів, що витрачаються на запис в MMIO-регістр. І вони не змусять себе чекати. У підсумку, ми поквитаємося з USB 2.0. Доказ цього - можливість підтримки всіх видів USB-пристроїв (Low Speed, Full Speed, High Speed, Super Speed) одним контролером xHCI без використання контролерів-компаньйонів.