Добрый день.


После прочтения топика, хочется вставить свою лепту в истории

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

Юзать рекомендую только по потокам (иначе подвесите всю систему как два пальца).

Сейчас тестим всю систему на двухядерных машинах и быть может (повторю быть может) именно из-за второго ядра (вернее болльше одного) происходят глюки (иногда драйвер виснит, как будто в пайпе нет данных и соответственно виснит вся винда). До этого открутились несколько лет на одноядерных и с нашей DLL и прошивкой все работало нормально (параллельно я уже по этому поводу тут спрашивал). Кто-нибудь на двухядерных крутил дивайс???

По поводу EzUSB, натолкнулись на то что дебаговая версия жрет кучу процессорного времени (а оно на вес золота). По сему работаем исключительно с free.

Вообще драйвером я доволен, а чего им быть не довольным - он ПРОСТОЙ. Все в ваших руках. У нас достаточно глубокая обратная связь в системе, по этому о латентности ничего сказать немогу. Единственное что интересно кто как решает проблему передачи?? Мне пришлось завести в железке таймер по которому в тото же пайп кидается спец пакет. Дабы не завесить поток на вычитку. Ну нехотел я заводить второй канал для проверки наличия данных да еще на интеррапт. Да и буфер у нас для сих вещей маловат. А входной поток большой (ну не дикий, но большой для такого буфера и всяких там паралельных задачь).

А какой буфер используют господа?? Ну так чтобы данные не потерялись и при условии то данные на вход Cypress остановить нельзя.

Вот пожалуй и все.

Удачи.

Это для всех драйверов так.
EzUsb - отличный пример драйвера c исходниками , тем более есть исходники для DriverStudio.
Использовали при разработке своих.


Проблема еще та. Дело в том, что Microsoft довольно смутно ( даже мутно) документирует свой планировщик потоков. Для однопроцессорной системы некоторые вещи проходили - забыл поставить SpinLock на возможно разделяемых данных и черт с ним, на многопроцессорной системе это уже не прокатывает. Много ли было раньше у разработчиков драйверов доступных для для теста многопроцессорных машин?



Посмотрите в исходнике того же EzUsb (лучше из DriverStudio, в нем нагляднее) на реализацию поллинга Interrupt Ep. Сделайте похожее для считываения во внутренний буфер драйвера для Bulk. Буфер сделайте побольше. А из приложения через DeviceIoControl считывание данных из него (см. исходник serial.sys в том же DDK или DriverStudio). И не будете связываться с потоками. У вас получится постоянно готовый для приема из устройства канал передачи данных. Если есть данные - устройство пишет их в него, нет - пишет пакет нулевой длины.

Сообщение отредактировал Седой - Oct 30 2007, 10:11

Пытаюсь пока обходиться одним абортом - дабы прибить читающий поток при выходе из приложения.



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



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



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

И ещё про латентность. Она, как и ожидалось, сильно зависит от производительности компа.
0.9мс было на 4м пне 2800МГц. А на ноутбучном целероне-633 оказалась аж 4мс. Причём около 3.5мс висим в шинном драйвере Т.е. обхождение IO-манагера выигрыша в скорости не даст

IO-манагер вы не обходили. Я уже здесь сообщал, как (ИМХО) правильно нужно сделать (в том числе и обойти IO-манагер).

1. Реализовать процедуру запрос-ответ в одном CONTROL_IO в драйвере, чтобы свести к минимуму обращения из приложения в драйвер и обратно. ( у вас 4, а получится 2)
2. Применять в драйвере асинхронные обращения к нижележащему драйверу, функции завершения которых работают в DISPATCH_IRQL. (EzUsb использует синхронные, которые выполняются в контексте ваших потоков, и ждет срабатывания Event от дравера шины)

PS. Можно также повысить приоритет потоков, но это не рекомендуется.

Хм, а сколько раз у вас при этом за одну загрузку компьютера происходит таких абортов? До следующей загрузки компа.



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




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

Чую все же прийдется уводить всю DLL в драйвер.


PS. А какой буфер используют господа?? Я имею ввиду в ЖЕЛЕЗКЕ!!! Не в компе!!! Опять же. Пауз в потоке нет!!! Т.е. потеря данных на входе - катастрофа. Ну у меня поток 1Мбит-3Мбит (сейча 1, будет до 3-х).

Удачи.

Из опыта: допустим проверили 2KB достаточно - нагрузили систему сторонними задачами , как только могли. На тачке разработчика все прекрасно работает, на других тачках в конторе тоже, отдаем знакомым геймерам - тоже работает. В конечное устройство ставим минимум 32KB.
К сожалению Windows не realtime система, живет собственной жизнью, да и пользователи имеют свойство использовать ее по собственному разумению.

"Катастрофой" обычно называется инцидент с человеческими жертвами. Если существует такая опсаность - лучше не используйте USB. Тогда лучше проектируйте специализированную систему с многократным дублированием. Потому что вообще-то никакая real-time система с конечным буфером не может гарантировать отсутствие потерь данных. Тем более, USB. В конце концов, что Вы будете делать если кто-нибудь выдернет кабель из компьютера?

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

USB - есть требование, которе нам навязали. Нам наоброт пришлось уйти от собственного интерфейса.

Потери в данном случае ассоциируются (это для тех кто не понял) исключительно с плохой работй прибора и соответственно все булыжники начнут лететь в наш огород.

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

Предлагаю не начинать полемику вокруг темы "реалтаймовая система и USB".

С уважением, Андрей.



Спасибо за ответ. Но по хоже ваша система с низким трафиком или поток модет быть приостановлен.

У нас стоит 64 Кбайт и иногда - этого мало.

Я и не говорю, что обходил. Думаю пока, как это сделать полегальнее, но ничего кроме своего шлюза в GDT не придумывается...



Ну это так... полумера, хотя попробовать тоже придётся..



Надеюсь, что это сократит время ожидания готовности. Интересно, насколько быстр механизм этих эвентов?...



Может и до этого дойти.. посмотрим.




Единицы раз. Равняется количеству запусков апликухи. А больше и не надо.

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



Я разве говорил что USB плохо? Сами знаете, что у USB есть несколько режимов. bulk - когда потерь быть не может, но могут быть задержки на неопределенное время. Иначе стоит реализовывать изохрон, когда выпадение допустимо но недопустима задержка. И пусть система выделяет полосу пропускаяни шины. В нормальных условиях шум на шине маленький и изохрон как я понимаю сбоить не должен. Иначе можно добавить в поток перемежение и коды коррекции ошибок, чтобы корректировать потери отдельных фреймов. Выбирайте. Но Вам заранее нужно решить, чем жертвовать: задержкой или данными, в тех случаях, когда приходится жертвовать. В любом случае можно сделать так, чтобы работа в Ворде не приводила к существенным проблемам. Что касается WinAmp - не знаю, нужно исследовать, не запускает ли он что-либо с realtime приоритетом.

Кстати, в NT совершенно реально реализуется мягкий realtime. Когда система работает "почти всегда realtime". В крайнем случае автоматом работающим на DPC уровне в ядре. Завершился предыдущий IRP - посылаете следующий сразу из Complete, а не просто event взводите. Нужно только от рекурсии в ошибочных ситуациях защититься...



Да уж, такое возможно. Запустят на этом компе 3D шутер во время сбора данных. Что делать, в такой ситуации единственный путь - отрывать глупому заказчику руки.

Да нет, такие же требования как у Вас.