Цитата(Dr.Alex @ Jun 23 2017, 01:13)

Есть WinDriver.
Работает так (в моём понимании):
При инициализации я задаю размер буфера для IN пакетов, он может быть хоть гигабайт.
Ядрёная (kernel) часть драйвера выгребает заданный BULK ендпойнт САМА, без пинков от медленной юзерской программы.
А когда я в юзерской программе делаю чтение, то оно происходит уже из ядрёного буфера.
Не так. Если бы было так, как вы описали, то при открытии чтения из юзерской программы вы бы получали данные, выгребенные из устройства полчаса назад.
При открытии чтения драйвер (или цепочка драйверов) выделяет буфера и строит цепочку дескрипторов на заявленную длину чтения (которая может быть много больше размера эндпойнта), после чего практически не участвует в чтении (разве что обрабатывает прерывания) - обработку транзакций и слив данных в буфера производит USB-контроллер
аппаратно, посредством DMA-механизма, согласно цепочке дескрипторов обмена.
Цитата(Dr.Alex @ Jun 23 2017, 01:13)

Есть libusb.
Работает так (в моём понимании):
Когда я вызываю чтение, то только тогда на шине инициируется IN-транзакция. Никаких буферов нет.
Поэтому когда прога работает, а я давлю "обновить" в браузере на каком-нить тяжёлом сайте,
то чтение прекращается на сотню миллисекунд, и не слишком длинный буфер в моём устройстве переполняется.
Насколько я понимаю, libusb также опирается на kernel-драйвер, только расположенный ниже по иерархии, который предоставляет generic-доступ к устройству, то есть на уровне "осуществить bulk-чтение" в размере конечной точки. Поэтому, чтобы выгрести приличный объем данных, libusb вынуждена много раз "слазить" на уровень kernel и обратно, что довольно затратно для системы, ну и другие процессы тоже могут "перебивать" эту неспешную процедуру.
"... часами я мог наблюдать, как люди работают." (М. Горький)