Если вести речь о задержке между запрос-ответ и вторым запрос-ответ - то точно не меньше 1 мс.

Вот и я о чем. Мне удавалось из USB 1.1 выжать 2 миллисекунды на транзакцию в подобном режиме. Было интересно, помогают ли чем-либо микрофреймы в 2.0, по которым могут генерироваться прерывания в 8 раз чаще, но которые должны быть активированы в регистрах хоста? Если не помогают - значит, Винды их не используют.

Не знаю. Но судя по требованию Microsoft - минимальной длительности обработчика прерывания (конкретное значение не указывается, но судя по требованию на spinlock не более 25-30 мкс) - то вряд ли.

Сообщение отредактировал Седой - Oct 23 2007, 15:26

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

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

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

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




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

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

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

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

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


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

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

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

Попробую 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 мс, как и измерилось приложением.

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

Для EzUsb можно только через использование раздельных потоков чтения и записи, запуская чтение раньше записи.

Сообщение отредактировал Седой - Oct 26 2007, 09:56

Проверил ваше утверждение. Результат отрицательный. Время от 20 до 60мс.
Вот лог:

0.00001145 IRP_MJ_DEVICE_CONTROL
0.00002458 enter Ezusb_Read_Write()
0.00003716 enter Ezusb_CallUSBD
0.00004973 Calling USB Driver Stack
0.00013410 return from IoCallDriver USBD 103
0.00014499 Wait for single object
0.00033300 Wait for single object, returned 0
0.00034557 URB status = 0 status = 0 irp status 0
0.00035703 exit Ezusb_CallUSBD (0)
0.00036876 Successfully transfered 0xa bytes
0.02320407 Wait for single object, returned 0
0.02321692 URB status = 0 status = 0 irp status 0
0.02322837 exit Ezusb_CallUSBD (0)
0.02324066 Successfully transfered 0xa bytes
0.02806977 IRP_MJ_DEVICE_CONTROL
0.02808374 enter Ezusb_Read_Write()
0.02809603 enter Ezusb_CallUSBD
0.02810888 Calling USB Driver Stack
0.02820191 return from IoCallDriver USBD 103
0.02821308 Wait for single object

Судя по логу, Вы что-то не так сделали.

Возможно.. Вы говорили, что надо запускать чтение раньше записи и делать это в отдельном потоке. Так я и сделал.
И по логу видно, что я сделал именно так.




Прошу прощения. Поставил sleep(0) в цикл ожидания готовности приёма и всё стало гораздо лучше. Среднее время отклика = 0.9 мс. Спасибо.


Я наверно, и с CYUSB-драйвером погорячился, когда его обругал... надо будет ещё раз попробовать когда-нибудь...

Да, в отличие от EzUSB, на нем можно получить больше 64000 байт в секунду на bulk передаче.

Откуда Вы это взяли. В первый раз слышу, а по исходнику не вижу.
Если Вы имеете в виду MAX_TRANSFER_SIZE = 64 kb, то это к скорости никакого отношения не имеет.

Если Вам нужно за один раз передавать больше, что мешает изменить это значение?
http://support.microsoft.com/default.aspx?...b;en-us;Q832430

Сообщение отредактировал Седой - Oct 27 2007, 04:55