Время отклика USB-устройства.... Опции

[qqqqqq]

Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.
Что-то не этого я ожидал от HS USB.
Длина пакетов была 10 байт. Драйвер CYUSB, микросхема CY7C68001, на выходе которой стоит CPLD, разворачивающая приходящий пакет, инвертируя его, в синхронном режиме на скорости 48МГц 8бит.

Как бы сократить это время раз этак в 40тысяч?...
Похоже, где-то я действую неправильно...
В интернете ничего на данную тему найти не смог, кроме упоминаний, что "USB response time is unacceptably slow". Неужели этого и добивались разработчики данной шины?
Даже не верится...

[oran-be]

Чего то как то совсем непонятно.... У шины время кадра на полной скорости 1 мС, а на высокой микрокадр - 0.125 мс. В течении этого времени в самом худшем случае ( это тот случай, если имеется простейший планировщик пакетов - один запрос в кадре) мы буим иметь задержки 2 мСек и 0.25 мСек соответственно. Хотя я еще ни разу не видел простых планировщиков пакетов. На полной скорости шина умудряется в течении 1 мсек пропустить 64 булк пакета туда и обратно при условии, что функция не тормозит с ответом и она на шине единственная. Вопрос заключается в том, каким образом измерялось время реакции. Если через GUI, то можно получить время реакции и больше.
Вообще при таких скоростях самая большая проблема - это грамотная организация потока записи в драйвер и вычитывания из него.

Сообщение отредактировал oran-be - Oct 20 2007, 11:11

[qqqqqq]

Чего то как то совсем непонятно.... У шины время кадра на полной скорости 1 мС, а на высокой микрокадр - 0.125 мс. В течении этого времени в самом худшем случае ( это тот случай, если имеется простейший планировщик пакетов - один запрос в кадре) мы буим иметь задержки 2 мСек и 0.25 мСек соответственно. Хотя я еще ни разу не видел простых планировщиков пакетов. На полной скорости шина умудряется в течении 1 мсек пропустить 64 булк пакета туда и обратно при условии, что функция не тормозит с ответом и она на шине единственная. Вопрос заключается в том, каким образом измерялось время реакции. Если через GUI, то можно получить время реакции и больше.
Вообще при таких скоростях самая большая проблема - это грамотная организация потока записи в драйвер и вычитывания из него.

1. Консольное приложение считывает тек. время (QueryPerformanceCounter),
2. отправляет драйверу CYUSB.SYS запрос на транзакцию по OUT-ендпоинту,
3. драйвер некоторое время думает, потом возвращает управление приложению,
4. приложение отправляет драйверу второй запрос уже по IN-ендпоинту,
5. драйвер опять думает, на этот раз гораздо дольше и снова возвращает управление, после чего принятый пакет появляется в буфере.
6. Приложение второй раз считывает время и считает разницу.

Получается время от 20 до 100 мс. 40 мс в среднем.

Для LPT-порта такой фокус выполняется около 2 мкс, только, естественно, драйвера там нет, а есть команды процессора IN и OUT.

Так что GUI тут ни при чём.

Так то оно так, но USB Root-Hub скорей всего подключен через шину PCI,
так что для него тоже имеет значение установки BIOS'а.
Попробуйте уменьшить в BIOS'е PCI_Latency_Timer, скажем, до восьми.
По умолчанию, PCI_Latency_Timer обычно равен 32, а это при частоте PCI шины 33 МГц
дает задержку на доступ к шине равную 32*30 нс = 0.96 мкс.
Поскольку для обслуживания прерывания требуется несколько обращений к шине PCI,
это может приводить к задержке в несколько мкс.

Попробовал... Похоже или виндоз при загрузке её переопределяет всегда как 32, или это число вообще ни на что не влияет. Всегда примерно 1мкс...

Забавно выглядит на анализаторе: два-три цикла шины - обмен, 30 циклов - пауза. А проц в это время ждёт чего-то...

[Седой]

Получается время от 20 до 100 мс. 40 мс в среднем.

Все правильно, так и будет при таком использовании.

[qqqqqq]

Все правильно, так и будет при таком использовании.

Непонятно, что мешает драйверу при свободной шине отправить запрос на чтение сразу при получении этого запроса от приложения? Зачем ждать 40мс?

[Седой]

Непонятно, что мешает драйверу при свободной шине отправить запрос на чтение сразу при получении этого запроса от приложения?

По CyUSB ничего сказать не могу, нет исходников.
Попробуйте EzUsb.

Зачем ждать 40мс?

Это вы спросите у Microsoft и Cypress.

PS. Какую версию SuiteUSB используете?

[qqqqqq]

PS. Какую версию SuiteUSB используете?

Версия драйвера CYUSB 1.07.0000.0, но пробовал и с более старыми - результат такой же.
Команда IOCTL_ADAPT_SEND_NON_EP0_TRANSFER
директовую команду не пробовал, но кажется, результат не изменится...

Попробую EZUSB...

[qqqqqq]

Попробую EZUSB...

попробовал EZUSB. сразу получилось около 1.9 мс, но иногда (достаточно редко) бывает и до 4мс.
Т.е. по латентности этот драйвер шустрее CYUSB в десятки раз..
Этот результат получен при включенном отладочном протоколировании.
Вот протокол драйвера:
0.00001090 IRP_MJ_DEVICE_CONTROL
0.00002403 enter Ezusb_Read_Write()
0.00003632 enter Ezusb_CallUSBD
0.00004889 Calling USB Driver Stack
тут ок. 70 мкс передаём запрос на запись шинному драйверу
0.00012599 return from IoCallDriver USBD 103
0.00013689 Wait for single object
тут 140 мкс ждём, когда шинный драйвер обработает запрос
0.00027797 Wait for single object, returned 0
0.00029026 URB status = 0 status = 0 irp status 0
0.00030143 exit Ezusb_CallUSBD (0)
0.00031373 Successfully transfered 0xa bytes
тут где-то 650мкс мы пребывали в диспетчере ВВ (в приложении между двумя DeviceIOControlами находятся с десяток ассемблерных команд (PUSH в основном)) И это при прямом методе (METHOD_IN_DIRECT, METHOD_OUT_DIRECT) общения с драйвером.
0.00095990 IRP_MJ_DEVICE_CONTROL
0.00097191 enter Ezusb_Read_Write()
0.00098281 enter Ezusb_CallUSBD
0.00099482 Calling USB Driver Stack
ок. 90 мкс передаём запрос на чтение шинному драйверу
0.00108338 return from IoCallDriver USBD 103
0.00109427 Wait for single object
180 мкс ждём, когда шинный драйвер обработает запрос
0.00127390 Wait for single object, returned 0
0.00128620 URB status = 0 status = 0 irp status 0
0.00129709 exit Ezusb_CallUSBD (0)
0.00130855 Successfully transfered 0xa bytes

и где-то 170 мкс находимся в драйвере EZUSB (в основном выдаём отладочные сообщения)
Плюс в лог не вошло время входа в первую функцию и выхода из второй - ещё 650 мкс в дисп. ВВ.
Итого получается 1.95 мс, как и измерилось приложением.

По итогам данного измерения можно резюмировать, что основную задержку даёт микрософтовский диспетчер ввода-вывода...
Осталось его как-то обойти и латентность уменьшится ещё в несколько раз. до полмиллисекунды.