Время отклика 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

[Oldring]

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

Вопрос в том, как драйвер узнает о завершении прокачки пакета? Несколько лет назад железо раз в миллисекунду выдавало прерывание, по которому софт завершал обработку предыдущего фрейма. И И инициализировало прокачку очередного фрейма по заранее составленному расписанию. Сейчас это уже не так?

[Седой]

Вопрос в том, как драйвер узнает о завершении прокачки пакета? Несколько лет назад железо раз в миллисекунду выдавало прерывание, по которому софт завершал обработку предыдущего фрейма. И И инициализировало прокачку очередного фрейма по заранее составленному расписанию. Сейчас это уже не так?

Давайте конкретизируем задачу.
Насколько я понял, автору ветки необходимо получить минимальное время реакции в процессе ЗАПРОС-ОТВЕТ. Сейчас у него следующая ситуация - USB устройство может отвечать быстро, а хост не готов принимать.
Разрешить эту проблему можно (ИМХО)только в драйвере устройства совместно с firmware устройства следующим образом:

1. Устройство реализует два endpoint - одно OUT (запрос) и одно IN (ответ).
2. Драйвер реализует обработчик определенного DeviceControl - запрос/ответ, запрашиваемый приложением.
3. В этом обработчике драйвер делает следующее:
3.1. Создает URB для IN и направляет его нижележащему драйверу (шины), обязательно указывая функцию завершения, назовем ее CompleteIN .
3.2. Создает URB для ОUТ с данными, полученными от приложения, и также направляет его драйверу шины с функцией завершения CompleteOUT.
3.3. Устанавливает флаг PENDING.
4. Функции завершения делают следующее:
CompleteIN: завершает DeviceControl с данными полученными от устройства (ответ).
CompleteOUT: если произошла ошибка, то прерывает запрос IN и завершает DeviceControl c ошибкой, если нет - не делает ничего.

Реализация такого механизма позволит устройству не только максимально быстро ответить на запрос (даже в пределах одного фрейма), но и передавать данные хосту во время приема пакетов транзакции запроса.

PS0. Насколько я знаю, ни один из фирменных драйверов (Cypress, Silabs, NXP, Atmel, FTDI) не имеет такого механизма, так что придется делать свой драйвер.
PS1. Для транзакций, больших длины пакета, возможно можно поменять местами 3.1. и 3.2.
PS2. Возможно, такой механизм можно использовать и с фирменным драйвером, запуская функцию чтения в отдельном потоке раньше функции записи в другом потоке. Но это потребует работы с синхронизацией потоков. ИМХО, возни больше чем с драйвером.
PS3. Можно также попробовать с фирменными драйверами, если они позволяют, поиграть с overlapped.
PS4. Вышеизложенный механизм работает - используем в своих драйверах.

Сообщение отредактировал Седой - Oct 21 2007, 11:06

[Oldring]

Давайте конкретизируем задачу.

...

3. В этом обработчике драйвер делает следующее:
3.1. Создает URB для IN и направляет его нижележащему драйверу (шины), обязательно указывая функцию завершения, назовем ее CompleteIN .
3.2. Создает URB для ОUТ с данными, полученными от приложения, и также направляет его драйверу шины с функцией завершения CompleteOUT.
3.3. Устанавливает флаг PENDING.
4. Функции завершения делают следующее:
CompleteIN: завершает DeviceControl с данными полученными от устройства (ответ).
CompleteOUT: если произошла ошибка, то прерывает запрос IN и завершает DeviceControl c ошибкой, если нет - не делает ничего.

И какое в результате получилось минимальное наблюдаемое время отклика? У меня, когда я пытался добиться от такой схемы минимального времени от USB 1.1 - 2 мс на цикл. И, кстати, при прерывании IN запроса иногда время уходило в десятки миллисекунд.