Есть прибор с хитрой и неоднородной организацией памяти.
Компьютеру эта память представляется в виде отдельных файлов, которые надо с прибора считывать.
Если использовать READ_10, то из-за неизбежных задержек сектор (512байт) из памяти прибора может считываться до 0.3сек. Не могу понять ( найти в спецификациях ) что нужно делать по USB в течение этого времени. Если я в течение этого времени отзываюсь NAKами по OUT и по IN, то Windows переклинивает. Т.е. вылезает букет ошибок и как результат винда сбрасывает USB-функцию.
Что делать ? Поддерживается ли в MassStorage/SCSI какое-нибудь отложенное чтение ? Или как-то подругому можно решить проблему ?
Заранее спасибо.

Вообще это странно. Вы уверены? Тут вроде только на IN NAKи приходится слать. А что такое винда запрашивает в том CBW, на который вы NAKи на OUT шлёте? Я давным-давно такое делал, поэтому не уверен, но у меня вроде 5 секунд NAKи на IN до ошибки слались.

Можно винде слать CSW с ошибкой, а на следующий REQUEST SENSE послать, что ошибка CRC была "ID CRC ERROR" - SenseKey=3, ASC=0x10, ASCQ=0. В этом случае точно ДОЛГО тот-же READ(10) шлётся. В смысле с теми-же параметрами. Проверял. Из-за этого даже новую флешку, у которой CRC в 0м секторе не совпадает, отформатировать невозможно.
А м.б. логичнее что-то типа "LOGICAL DRIVE NOT READY - BECOMING READY" послать (SenseKey=2, ASC=4, ASCQ=1). Или ещё что-нибудь - попробуйте.

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

Если не принимать никаких мер, то да, уверен. CBW во время этой задержки я не смотрел, т.к. OUT отключен. Попробую проанализировать.

Идеи интересные, но весь смысл затеи в максимально быстром чтении. Мне кажется с подобными ухищрениями получится сильное торможение обмена.
В принципе MSC не самоцель, главное чтобы все было быстро. Если не получится я другой класс сделаю, CDC например. Просто сделано много, и, чтобы это не потерять, хочется четко понять всю физику процесса и убедиться что MSC здесь не катит.

Скажу сразу, пока реально не использовал, т.к. здесь это не нужно. Но видел в MSDN в описании функции CreateFile вот такую вещь:
HANDLE CreateFile(
...
DWORD dwFlagsAndAttributes, // file attributes
...
);
dwFlagsAndAttributes - Specifies the file attributes and flags for the file.
FILE_FLAG_NO_BUFFERING
Instructs the system to open the file with no intermediate buffering or caching. When combined with FILE_FLAG_OVERLAPPED, the flag gives maximum asynchronous performance, because the I/O does not rely on the synchronous operations of the memory manager. However, some I/O operations will take longer, because data is not being held in the cache.
Попробуйте, может быть это оно.

Что-то я не понял:
1. В 1м посте вы спрашиваете как притормозить чтение, а во 2м - вам нужно максимально быстро.
2. "Если использовать READ_10". Что значит "если"? Что разве имеется к.л. другой способ?
3. Почему ухищреия? Это стандартный протокол обмена.
Изложите ситуацию подробнее.

Насчёт максимально бысто: мой самодельный full speed MassStorage 1 мБайт/сек выдавал. И это теоретический предел - 16 пакетов по 64 байта за кадр USB (1 мс).

1. Неоднозначно высказался, извиняюсь. Нужно максимально быстрое чтение из прибора, который каждый запрашиваемый сектор готовит до 300мсек. Нужно, чтобы комп получил этот сектор с минимальной задержкой с момента готовности этого сектора. Сейчас это не работает вообще. Почему ? Это я и хочу понять. Те сектора, которые не требуют времени на подготовку, читаются быстро и четко (500КБайт/сек), поэтому в самом ядре mass storage сомнений нет. Пока ищу причину, может действительно что-то не то делаю.
2. Не придирайтесь к словам.
3. Ухищрениями я это назвал по следующей причине. Мне кажется, что задержка при чтении информации с носителя - это достаточно распространенная ситуация. Поэтому должна быть какая-то стандартная процедура разруливания, подробно описанная в литературе. Поэтому использование Medium Error мне показалось все-таки нестандартным "обманом".

Стандартная процедура - это посылка NAKов (до 5 секунд). Очень странно, что у вас при этом возникают ошибки. А что в USB логах? Кстати вы их чем смотрите? Лично мне SnoopyPro нравится. Только вот с сохранением логов в нём какая-то ерунда. Формат странный какой-то - не разобрался. Да и не надо особо-то было. Ну хотя-бы в виде скриншота выложите.

Посидел в сниффере/отладчике... Действительно, Вы оказались правы, как минимум 3 секунды IN шлется. У меня в программе просто трудноуловимый косяк вкрался. Спасибо огромное за наводку!

По поводу кэширования при чтении ... попробовал упомянутый ранее FILE_FLAG_NO_BUFFERING, действительно работает ( перечитывает вновь запрашиваемые сектора). Еще вскользь упоминается кэширование в коммандах MODE SENSE/MODE SELECT, но я не понял в каком контексте. Посмотрите, может там что-то есть. ( упоминается в книге Jan Axelson "USB mass storage : Designing and Programming Devices and Embedded Hosts" ). Для борьбы с кэшированием при записи еще индивидуально каждый носитель можно в винде настраивать (Device Manager -> Disk drives -> Kingston Data Traveller -> Properties -> Policies -> Optomize for performance).