Лишняя задержка перед каждой USB Bulk тразакцией Опции

[ValeraVi]

Может кто встречался с проблемой:
Есть USB full speed девайс с двумя bulk ендпоинтами (один на вход, другой на выход). Написана фирмвара, драйвера под линух и винду, все работает.
Для проверки работоспособности имеется простейшая апликуха, которая пишет 30 байт (это меньше wMaxPacketSize = 32) в девайс и сразу же вичитывает оттуда. Все это в цикле до бесконечности.
Но по хардварному анализатору видно, что виндовский драйвер перед каждой транзакцией делает задержки в 1 мс, т.е. булк пакет посылается (принимается) только в каждом 2-м микрофрейме, т.е. перед каждой транзакцией я в логе анализатора вижу 2 SOF.
При этом линуховый драйвер работает четко - задержек нет, перед каждой транзакцией по одному SOF, а в некоторых случаях умудряется даже в одном фрейме влепить по 2 транзакции (IN, потом OUT).
Девайс и к линуху и к винде подключается один и тот же. Компы с виндой и линухом - разные, но другой периферии кроме этого девайса не подключено. Испытывали на нескольких виндовых компах - все одно и тоже - видна шлет булк пакет только в каждом 2-м фрейме (не первом, не 3-м, не 4-м...).
Это какая-то особенность винды? Глюк моего драйвера виндовского? Писал его на базе примера из ДДК bulkusb. Может нужны какие-то хитрые настройки Дескрипторов usb девайса, которые для линуха подходят а для винды приводят к задержкам?

[misyachniy]

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

USB хост обслуживается драйвером Windows.

Стандартно для FS секунда разбивается на 1000 фреймов.
Драйвер windows подстраивается под такое деление.
Раз в 1 миллисекунду, драйвер хоста (точнее планировщик задач для хоста) делит полосу пропускания USB между устройствами.
Таким образом в 1 фрейм планируется одна передача для устройства.
После передачи, планировщик получает задание на прием 30 байт и в следующий фрейм ставит задачу хосту получить 30 байт.
Таким образом, меньше чем в 2 фрейма ping-pong не получится.

Так что, по моему никакой проблемы в драйвере и устройстве нет.

[Седой]

....
Таким образом в 1 фрейм планируется одна передача для устройства.
После передачи, планировщик получает задание на прием 30 байт и в следующий фрейм ставит задачу хосту получить 30 байт.
Таким образом, меньше чем в 2 фрейма ping-pong не получится.

Так что, по моему никакой проблемы в драйвере и устройстве нет.

Вы немного ошиблись - правильнее будет так: Таким образом в 1 фрейм планируется одна транзакция для 1-го endpoint.
Таким образом, если запрошено несколько endpoints для одного устройства, то транзакции могут идти и в одном фрейме.
Я уже здесь в форуме писал, как получить запрос - ответ в одном фрейме.

[alex33]

Если я правильно понял то одна транзакция (в интервале 1 мс) для одой конечной точки. Это соотвествует всем типам передач (bulk, изохорные, управление и прерывания) ?