Быстродействие передачи данных в .NET

[jur]

Привет!

Что-то призадумался я в последнее время о переходе на .NET :-) Но пока не имею совершенно никакого опыта программирования под эту платформу. Система - стандартная PC-совместимая материнка с Win XP.

А вопрос у меня такой. В моем приложении мне нужно принимать поток данных из своего устройства по шине USB 2.0 со скоростью порядка <= 20 МБайт/сек. До сих пор я пользовался стандартным C++ и драйвером CyUSB.sys от фирмы Cypress (превосходная микросхема USB 2.0 этой фирмы применяется в нашем устройстве). Прием данных происходит, естественно, в отдельном треде в большой буфер памяти. Предельно-достижимая скорость приема получается порядка 40-43 МБайт/сек. Этого слихвой хватает для уверенного приема данных моим приложением.

Фирма Cypress также дает свой драйвер и для платформы .NET - SuiteUSB.NET. К нему прилагается несколько простеньких примеров. Я скомпилировал и запустил бессмертный BulkLoop (данные посылаются устройству и оно тут же отсылает их обратно), все заработало. Но у меня появились сомнения насчет быстродействия этого .NET'овского управляемого кода.

Скажите, пожалуйста, как в .NET'овских приложениях обстоят дела с производительностью передачи данных по USB? Какова предельно-достижимая скорость передачи? Сам я пока до таких тонкостей еще не поднялся :-)

Спасибо!

[Ochkarik]

хм. а какая связь между .NET, и драйвером?)))
драйвер в системе Windows может использовать либо WDM (98/2000/XP/Vista) либо KMDF (Vista) структуру.
и слово .NET к драйверу ИМХо вобще не применимо, разве только они с интерфесом чего нить перемудрили)
так что... подозреваю - сам драйвер там тот же. интерфесную библиотеку они могли переделать.
в любом случае... c БОЛЬШОЙ уверенностью могу сказать - наверняка он медленнее(по определению). но скорее всего незначительно...

PS да, судя по предыдущему вопросу о вызове драйвера из С# (тема "Создание библиотеки для работы с драйвером")
это просто обвязка для вызова драйвера из C# кода. короче ерунда это все)

[Джон]

Я тоже не совсем понял, что значит драйвер под .NET? Согласен с Ochkarik - скорее всего интерфейс доступа адоптирован для неё. На скорость самого драйвера это никак не должно повлиять. В любом случае USB-шные скорости покроются с лихвой.

[jur]

Да, вы совершенно правы, я недостаточно точно обрисовал ситуацию. Прошу простить за неточность.

Естественно, что WDM-драйвер, с которым я работаю, - он и в Африке WDM-драйвер :-) Меня интересует, конечно, приложение, которое осуществляет прием данных. Понятно, что альтернативы отдельному треду для высокоскоростной передачи данных нет. Но я пока не имею опыта работы с подобными приложениями на платформе .NET. Поэтому мне и интересно как обстоят дела с производительностью передачи данных по USB в подобных приложениях.

Я интуитивно чувствую, что управляемый код, по определению, должен быть помедленнее. Но насколько именно? Видимо этот вопрос имеет два возможных решения:

1. Если управляемый код позволяет получить необходимую мне скорость, то все в порядке, я могу его использовать без вопросов.

2. В случае возникновения затруднений со скоростью следует применить C++ для критических по производительности модулей, а остальной код (которого несравненно больше) писать на C#.

Я правильно понимаю?

[Алексей++]

jur, что значит - управляемый код?

[jur]

jur, что значит - управляемый код?

Не понял вопроса... Мы ведь о платформе .NET говорим, не так ли? Во всяком случае, я имею ввиду программирование приложений именно под .NET на C#.

[Ochkarik]

jur,
я к сожалению "слаб" в C#, посему ничего определенного сказать не смогу...
но. исходя из логики...

хм. мне тут подсказывают, что NET - это фактически интерпретатор, который работает всего   на 30% медленнее обычного кода? 
 

PS хотя операция копирования я НАДЕЮСЬ там не ПОСЛОВНО реализована)))))))))))))
PPS в общем, на диск вы скорее всего поток 20МБайт/с запишете, а вот сколь либо сложная обработка данных, подозреваю, просто умрет...
и последний вопрос... а оно вам вообще - зачем? на бейсике писать, веб использовать? на других платформах запускать? каков сакральный смысл перехода на NET?

[Алексей++]

насколько я слышал, там не так плачевно со скоростью, потому что интерпретация происходит один раз - при первой загрузке модуля , а потом используется уже исполняемый код. Но - не пользовался шарпом, не знаю точно

[jur]

хм. мне тут подсказывают, что NET - это фактически интерпретатор, который работает всего :idea2:  на 30% медленнее обычного кода?  :shock:
:undertable: :flag-to-hands:  :gygy: :lol2:

Да, сам по себе он довольно шустёр. Т.е. ситуация, насколько я понял, вроде современного Бэйсика :-) Это раньше Бэйсик был примитивным интерпретатором, а нынче его код компилируется в те же машинные команды, что и какой-нить C/C++/Asm. IMHO, замедление программы на платформе .NET происходит из-за усиленной проверки времени исполнения программы для повышения ее антисбойности. Но я пока в этом деле чайник...

PS хотя операция копирования я НАДЕЮСЬ там не ПОСЛОВНО реализована)))))))))))))

;-)

PPS в общем, на диск вы скорее всего поток 20МБайт/с запишете, а вот сколь либо сложная обработка данных, подозреваю, просто умрет...

Диск мне не нужен, я сохраняю данные в здоровенном массиве в памяти (просто для простоты реализации программы).

и последний вопрос... а оно вам вообще - зачем? на бейсике писать, веб использовать? на других платформах запускать? каков сакральный смысл перехода на NET?

Все дело в том, что я - инженер-разработчик. Я разрабатываю цифровую часть ультразвукового медицинского сканера на базе embedded-материнки (PC-совместимая). Простейшие варианты наших приборов созданы вообще на собственной цифровой плате с 16-разрядным микроконтроллером. Но более "крутые" модели нуждаются в здоровенной куче всякого дополнительного программного барахла для всевозможной обработки результатов, создания разнообразных отчетов, сохранения отдельных кадров или даже целого "кино" в файлах различных форматов и т.д. и т.п.

Все это делается небыстро и трудоемко в среде Win XP с применением обычного компилятора C/C++ и классов MFC. Но требования постоянно меняются, кроме того, замаячили перспективы освоения не только x86-совместимых аппаратных платформ, ну и всякое такое в этом роде.

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

Вот... Так я и пришел к изучению этой платформы... :-)

насколько я слышал, там не так плачевно со скоростью, потому что интерпретация происходит один раз - при первой загрузке модуля, а потом используется уже исполняемый код. Но - не пользовался шарпом, не знаю точно :)

Да, похоже, что дела обстоят именно так. Более того, Микрософт упоминает о компиляторах MSIL. Это, фактически, обычный скомпилированный код.

Дело в том, что я задал этот вопрос ввиду своей полной "чайниковости" в .NET :-) Все-таки серьезный переход... Это не от BC к MSVC переходить...

[Dimka]

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

В конце концов, это ещё и от производительности машины зависит.

P.S. Ещё в Windows 95 для Java было написано: "Не используйте Java для управления опасными объектами" (типа ядерных реакторов и т.п.)

[Dimka]

Все это делается небыстро и трудоемко в среде Win XP с применением обычного компилятора C/C++ и классов MFC. Но требования постоянно меняются, кроме того, замаячили перспективы освоения не только x86-совместимых аппаратных платформ, ну и всякое такое в этом роде.

Имхо, как раз для C/C++ переход на другую платформу более прост, если не делать ассемблерных вставок и прочих машинно-зависимых финтов, стараться использовать лишь стандартные (и широкораспространённые) библиотеки.

.NET существует там, где существует Windows. Есть проект Mono для UNIX-like платформ, и у них довольно впечатляющие результаты, но это не родной проект Microsoft, поэтому гарантировать его полное соответствие MS .NET хотя бы в нужной части довольно сложно.

[jur]

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

Спасибо за информацию! Сборку мусора я как-то упустил... Хотел спросить: если моя программа новых объектов не порождает, просто крутится на ожидании команд пользователя, то в этом случае сборка мусора под ногами мешаться не будет? Для меня критично, чтобы во время ультразвукового сканирования система ничего ресурсоемкого не делала.

А когда пользователь зафиксировал картинку и принялся делать всякие измерения, формировать отчеты, записывать результаты - то в этом случае мне паузы не страшны, пусть будут. Т.к. критичной для работы передачи данных в это время не происходит.

В конце концов, это ещё и от производительности машины зависит.

Никакого сомнения!

P.S. Ещё в Windows 95 для Java было написано: "Не используйте Java для управления опасными объектами" (типа ядерных реакторов и т.п.) :)

Слава Богу, мой прибор не приведет к серьезной катастрофе, даже если совсем сломается :-)

[jur]

Все это делается небыстро и трудоемко в среде Win XP с применением обычного компилятора C/C++ и классов MFC. Но требования постоянно меняются, кроме того, замаячили перспективы освоения не только x86-совместимых аппаратных платформ, ну и всякое такое в этом роде.

Имхо, как раз для C/C++ переход на другую платформу более прост, если не делать ассемблерных вставок и прочих машинно-зависимых финтов, стараться использовать лишь стандартные (и широкораспространённые) библиотеки.

.NET существует там, где существует Windows. Есть проект Mono для UNIX-like платформ, и у них довольно впечатляющие результаты, но это не родной проект Microsoft, поэтому гарантировать его полное соответствие MS .NET хотя бы в нужной части довольно сложно.

Да, я примерно так себе это и представлял. Спасибо за информацию!

[Джон]

jur, я думаю для твоих целей хватит с лихвой. Не стали бы они такую кашу с дот нетом заваривать, если бы она пасовала на скоростях до 100 мбит/с. Например сетевые .NET-приложения работают достаточно быстро на такой скорости.

Объективно - конечно она будет медленней в сравненнии с компилированным кодом (сравни с явой), но практически это не будет влиять при твоих скоростях.

[jur]

jur, я думаю для твоих целей хватит с лихвой. Не стали бы они такую кашу с дот нетом заваривать, если бы она пасовала на скоростях до 100 мбит/с. Например сетевые .NET-приложения работают достаточно быстро на такой скорости.

Объективно - конечно она будет медленней в сравненнии с компилированным кодом (сравни с явой), но практически это не будет влиять при твоих скоростях.

С одной стороны, это, вроде, так. Но с другой стороны... Я не знаю, как работает сетевой драйвер. Возможно, что он вполне допускает отдельные небольшие паузы в процессе передачи.

А у меня немножко другой случай. Мало того, что мне требуется гарантированная доставка пакетов (они - суть ультразвуковые лучи размером в 512 байт каждый), так еще критично и время этой доставки. Сейчас я работаю так, что поток считывания запрашивает у драйвера порции данных по 8К (16 лучей). Причем, выдает сразу очередь запросов (4 запроса) и ожидает поступления данных. Увеличивать размер очереди дальше бессмысленно, а запрашивать пакеты большего размера нельзя, т.к. в некоторых режимах работы к потоку данных примешиваются пакеты другого типа, которые нужно вылавливать очень шустро. При запросе более 16 лучей это вылавливание становится уже неприемлемо грубым.

Я еще подумываю о собственном драйвере, или драйвере-фильтре, который эти спецпакеты отлавливал бы сразу по их поступлению. Тогда я смог бы существенно увеличить размер запроса и это сняло бы остроту времязависимости приложения, т.к. предварительная сортировка обычных лучей и спецлучей происходила бы в драйвере навроде систем реального времени.

Но... Драйвера писать я тоже пока не умею... :-) Сейчас изучаю литературу и готовлюсь активизироваться в разделе "Drivers" ;-)

[Dimka]

Я еще подумываю о собственном драйвере, или драйвере-фильтре, который эти спецпакеты отлавливал бы сразу по их поступлению. Тогда я смог бы существенно увеличить размер запроса и это сняло бы остроту времязависимости приложения, т.к. предварительная сортировка обычных лучей и спецлучей происходила бы в драйвере навроде систем реального времени.

Эту мысль можно попытаться развить так:

Ты пишешь на C++ обёртку над драйвером, которая образует очередь с приоритетами обработки или две очереди с разными приоритетами обработки пакетов.

Ты на .NET заводишь две нити (thread) обработки, каждая из которых обслуживает пакеты своего приоритета обработки: одна с повышенным приоритетом исполнения читает поток (stream) редких спец-пакетов, но большую часть времени спит в ожидании данных; вторая читает поток (stream) основных данных, но из-за более низкого приоритета исполнения чаще всего (но не гарантированно) не будет тормозить первую нить (thread).

В конце концов, на .NET можно завести диспетчерскую нить с высоким приоритетом исполнения, которая занимается лишь сортировкой пакетов по очередям с разными приоритетами обработки. (Смотреть, чтобы при работе очередей не было операций выделения/освобождения памяти. Возможно, стандартные очереди .NET это умеют - надо их конструкторы смотреть, не помню.)

[jur]

В конце концов, на .NET можно завести диспетчерскую нить с высоким приоритетом исполнения, которая занимается лишь сортировкой пакетов по очередям с разными приоритетами обработки. (Смотреть, чтобы при работе очередей не было операций выделения/освобождения памяти. Возможно, стандартные очереди .NET это умеют - надо их конструкторы смотреть, не помню.)

Ты очень верно все расписал! В теории именно так и должно быть. Т.е. в идеальном случае все можно сделать очень просто и прозрачно:

1. Высокоприоритетный процесс (поток, нить) считывает по одному мои пакеты (лучи).

2. Когда попадется спецлуч, процесс помещает его в свой буфер, отличный от буфера основной массы обычных лучей.

3. Приложение берет лучи из двух буферов и строит изображение ультразвука и т.н. "ленты М-режима".

Именно это я и должен получить! :-) Но...

Чтобы жизнь не казалась Раем, система тут же ткнула меня носом в ..., ну в это самое :-) Считывание из драйвера по одному лучу немедленно гробит всю производительность. В смысле, совсем насмерть. Я не понимаю всех тонкостей и отличий режимов User-Kernel, но подозреваю, что накладные расходы переключения между этими двумя сущностями действуют наподобие серпа там, где мне не нужно...

Думаю, что исключив эти излишние накладные расходы я смогу существенно выиграть в быстродействии. Ведь, если разобраться, при считывании порции в 16 лучей драйвер все-равно каждый луч считывает в отдельности! Это значит, что очень легко можно помещать полученный луч в нужное место (обычные лучи в свой буфер, а спецлучи - в свой). И не понадобится вообще никаких извращений!

Только вот именно этого я пока делать и не умею! :-)

[Dimka]

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

Ещё выгоднее вообще иметь лишь один буфер типа массива (с циклическим переходом на начало при достижении конца), по которому "бегают" индексы разных нитей. Но тут, на вскидку, придётся больше мучаться с синхронизацией, чем при автономных буферах каждой нити - логика сложнее будет. И, главное, чтобы от этой логики не пострадала производительность.

[RXL]

Если минимизировать блокировку очереди пакетов (каждый поток будет блокировать очередь только на время вставки или изъятия одного пакета), то проблем возникнуть не должно.

[Алексей++]

а что если перед работой выделить всё доступное озу - и тупо кидать туда данные сканирования, а уж потом разбираться, где кто *ой* ? Или маловато озу будет ?

[Dimka]

Алексей1153++, это ж тебе не DOS. Любой чих винды, и начнётся своп. А что страшнее свопа в приложениях реального времени?

[Алексей++]

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

[jur]

Темное дело с этим буферированием... Сейчас я делаю так:

1. Имеется высокоприоритетный поток, запрашивающий у драйвера пачки по 16 лучей. Для максимального перекрытия операций запускается считывание сразу 4-х очередей (по 16 лучей в каждом запросе).

2. Принятые лучи распихиваются по своим буферам. Для этого при запуске приложения выделяются два буфера: буфер кадров для обычных лучей (256 лучей в кадре, 256 кадров) и буфер спецлучей для ленты М-режима (маленький буфер на 256 лучей).

3. Когда очередная порция лучей получена, этот высокоприоритетный поток смотрит на каждый луч (первый байт луча - его номер в кадре или 0xFF для спецлуча).

4. Обычные лучи фильтруются методом усреднения с предыдущим кадром и записываются в свой буфер, а спецлучи просто копируются в свой буфер.

5. Когда весь кадр сформирован выдается Event в основную программу. Также выдается другой Event для ленты М-режима, когда получена требуемая порция спецлучей (от 1 до 8 спецлучей в порции).

Вот примерно так у меня все и работает. Но иногда возникают неприятные моменты, когда Винда задумается о чем-то своем, девичьем... Тогда получается выпадение порции из нескольких лучей (порядка десятка лучей). Правда, такое бывает крайне редко (пока - единичный случай, в смысле в одном приборе).

В этой связи мне думается, что сортировка лучей в драйвере позволила бы мне решить задачу выпадения, т.к. я смог бы буферировать полученные лучи в высокоприоритетном коде драйвера, выполняющемся по прерыванию. А дальнейшая обработка лучей велась бы обычным образом, как это сейчас и делается.

Еще один положительный момент такого подхода со своим драйвером - возможность создания логически разных устройств-источников лучей: источник обычных лучей и отдельный источник M-лучей. Думаю, что при такой организации процедуры приема данных у меня и на платформе .NET проблем не возникло бы. Я верно понимаю?

[Dimka]

Но иногда возникают неприятные моменты, когда Винда задумается о чем-то своем, девичьем...

Во-во, на сборщик мусора похоже. Именно так он и проявляет себя в работе.

Копирование данных между буферами - операция сравнительно тяжёлая. Наверно, всё же, выгоднее хранить данные в общем массиве-буфере, а очереди составлять не из данных, а из индексов элементов буфера-массива.

Обычные лучи: 1, 2, 3, 5, 6, ...
Специальные лучи: 4, 10, ...

[Ochkarik]

копирование данных - отличная операция) быстрее этого только звезды) и вообще она помоему в тени от процессора выполняется...
при условии что адреса выровнены нормально.
остальное...
кадая передача события в приложение до единиц милисекунд. причем ОЧЕНЬ знависит он настроения винды.
вызовы IOCTL а так же R/W - тоже достаточно гадкие операции, особенно если их много.

что до вашего случая... честно говоря там все от размера пакета зависит. а вы его как раз и не указали...

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

[Dimka]

честно говоря там все от размера пакета зависит. а вы его как раз и не указали...

Если внимательно почитать, то:

доставка пакетов (они - суть ультразвуковые лучи размером в 512 байт каждый)

[Dimka]

копирование данных - отличная операция) быстрее этого только звезды) и вообще она помоему в тени от процессора выполняется...

Насчёт неучастия процессора ничего не скажу. Скорее всего так. Но перекачка несколько раз из одной очереди в другую до 20 Мб за секунду, имхо, тяжелее, чем однокоратная перекачка из драйвера в приложение. Сколько это займёт времени и насколько загрузит систему, не скажу.

[jur]

Копирование данных между буферами - операция сравнительно тяжёлая. Наверно, всё же, выгоднее хранить данные в общем массиве-буфере, а очереди составлять не из данных, а из индексов элементов буфера-массива.
Обычные лучи: 1, 2, 3, 5, 6, ...
Специальные лучи: 4, 10, ...

В общем случае я не могу прямо передать драйверу адрес, куда поместить лучи. Потому что, во-первых, лучи следует складывать по своему номеру (к примеру, от 0 до 127, или от 20 до 171). Во-вторых, перед сохранением в буфере i-того луча его следует усреднить с тем же i-тым лучем предыдущего кадра. Ну и в-третьих, нынешняя организация считывания данных допускает замешивание спецлучей в произвольные моменты последовательности обычных лучей.

А вот сохранение спецлучей в кольцевом буфере - самая благодатная для реализации в драйвере задача. Эти лучи не нужно усреднять и складывать их нужно просто все подряд. Т.е. положил порцию спецлучей (в порции от 1 до 8 лучей) в кольцевой буфер, и выдал Event: "Забирайте!".

Поэтому я и подумал, что разделение простых лучей и спецлучей в драйвере облегчило бы мою задачу хотя бы тем, что "Кесарю - кесарево, а слесарю - слесарево." (С) :-) Только я драйверов писать еще не умею...

что до вашего случая... честно говоря там все от размера пакета зависит. а вы его как раз и не указали...

Я запрашиваю у драйвера 16 лучей (8 КБайт) в каждой очереди. Число одновременно запущенных очередей - 4.

В общем-то нормально работает. Кроме единичного случая каких-то странных провалов, прием данных уверенный. Легко достигается частота кадров порядка 40-50 и более (при числе лучей 128). Вообще-то частота кадров зависит в бОльшей степени от самой физики ультразвука: если имеем глубину сканирования, скажем, 21 см, то время самого луча составляет порядка 300 мксек. А это диктует время одного кадра порядка 300 х 128 = 38 миллисек. Т.е. примерно 26 кадров/сек. Конечно, на меньших глубинах частота кадров возрастает.

Я призадумался о своем драйвере потому, что, IMHO, на платформе .NET у меня будут возникать более заметные паузы, чем сейчас. Поэтому представляется разумным реализовать несложные, но критические по времени, операции прямо в драйвере. Тогда основное приложение можно разрабатывать обычным образом, а важные операции по приему и отображению данных будут выполняться в драйвере и высокоприоритетном потоке соответственно.

Кроме того, если собирать весь кадр в драйвере (а это до 256 лучей по 512 байт каждый луч), для чего следует иметь буфер минимум на два кадра (чтобы можно было усреднять лучи с предыдущим кадром), то появляется возможность пересылать весь необходимый объем данных за одну операцию, а не за целую кучу отдельных пересылок. IMHO, время переключения памятей, Lock'и там всякие, - это довольно серьезный процесс, который гораздо разумнее было бы минимизировать. Т.е. довести до единственной пересылки массива данных за один кадр.

Тогда я еще больше облегчу жизнь моему .NET-овскому приложению :-)

[Dimka]

В общем случае я не могу прямо передать драйверу адрес, куда поместить лучи. Потому что, во-первых, лучи следует складывать по своему номеру (к примеру, от 0 до 127, или от 20 до 171). Во-вторых, перед сохранением в буфере i-того луча его следует усреднить с тем же i-тым лучем предыдущего кадра. Ну и в-третьих, нынешняя организация считывания данных допускает замешивание спецлучей в произвольные моменты последовательности обычных лучей.

Видимо, я не вполне донёс мысль. Я не говорил о передаче адресов и индексов драйверу, я говорил о помещении получаемых из драйвера данных в массив без всякой обработки и в порядке их прихода от прибора. И только потом к этому массиву применять разные алгоритмы анализа данных. Каждый алгоритм формировал бы свою очередь из индексов на интересующие его лучи.

Кроме того, если собирать весь кадр в драйвере

Тогда зачем .NET?

Это уже вопрос архитектуры. Либо "лёгкий" драйвер, и вся логика в .NET-приложении, либо "тяжёлый" драйвер с собственной логикой, но тогда его придётся поддерживать в будущем наравне с .NET-приложением, если есть риск смены логики первичной обработки данных, увеличение объёмов передаваемых данных, смены форматов и т.д.

[jur]

Кроме того, если собирать весь кадр в драйвере

Тогда зачем .NET?
Это уже вопрос архитектуры. Либо "лёгкий" драйвер, и вся логика в .NET-приложении, либо "тяжёлый" драйвер с собственной логикой, но тогда его придётся поддерживать в будущем наравне с .NET-приложением, если есть риск смены логики первичной обработки данных, увеличение объёмов передаваемых данных, смены форматов и т.д.

Да, это непонятный вопрос. Просто я, по своей неопытности, подозреваю, что получение данных и их первичная сортировка (разделение по типу лучей) в драйвере будет осуществляться с высоким приоритетом. Лучше всего вообще по прерыванию. Тогда притормаживания .NET-овского приложения мне не страшны.

Кстати, пользуясь случаем, хотел спросить. Драйвер USB (прикладной, т.е. написанный мною) каким-то образом обращается с запросами к драйверу USBD нижнего уровня. И этот "нижний" драйвер получает пакеты USB из железа по прерыванию, да? Можно ли каким-то образом вклиниться в этот процесс и получать эти пакеты USB тоже по прерыванию? Тогда моя задача решалась бы гораздо удобнее.

А что касается сопровождения драйвера... Ну там настолько все просто, что и сопровождать-то нечего :-) Да и логика работы предельно простая и пока нет перспектив ее изменения. Нужно только научиться драйвера писать... Буду пробовать...