Время отклика 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 циклов - пауза. А проц в это время ждёт чего-то...