Время отклика USB-устройства.... Опции

[qqqqqq]

Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.
Что-то не этого я ожидал от HS USB.
Длина пакетов была 10 байт. Драйвер CYUSB, микросхема CY7C68001, на выходе которой стоит CPLD, разворачивающая приходящий пакет, инвертируя его, в синхронном режиме на скорости 48МГц 8бит.

Как бы сократить это время раз этак в 40тысяч?...
Похоже, где-то я действую неправильно...
В интернете ничего на данную тему найти не смог, кроме упоминаний, что "USB response time is unacceptably slow". Неужели этого и добивались разработчики данной шины?
Даже не верится...

[VDG]

Неужели этого и добивались разработчики данной шины?

Они в первую очередь добивались от канала высокой пропускной способности, востребованной компьютерной мультмедией. А высокая частота "опроса" бытовухе не нужна. Синхронности в _событие->реакция_ и малой латентности от USB не ждите.

[Oldring]

Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.
Что-то не этого я ожидал от HS USB.
Длина пакетов была 10 байт. Драйвер CYUSB, микросхема CY7C68001, на выходе которой стоит CPLD, разворачивающая приходящий пакет, инвертируя его, в синхронном режиме на скорости 48МГц 8бит.

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

По моему собственному опыту можно добиться 2-3 миллисекунд. Если кто-то видел меньше - было бы интересно узнать.

Получить latency микросекунду иногда нереально даже на PCI шине. Меняйте архитектуру системы.

[qqqqqq]

По моему собственному опыту можно добиться 2-3 миллисекунд. Если кто-то видел меньше - было бы интересно узнать.

Получить latency микросекунду иногда нереально даже на PCI шине. Меняйте архитектуру системы.

Менять архитектуру выйдет недёшево... Проект не мой и исходников нет.
По идее, должно быть около 1/8 миллисекунды на интерраптных ендпоинтах, т.к. микрокадр именно такого размера. Но мне этого будет недостаточно.

На LPT-EPP латентность 2 мкс (при 8битном обмене). На PCI почему-то получается также, только ширина 32бита и больше.

Спецификация USB (равно как и PCI) вроде бы эту латентность не ограничивает. Похоже зависит в основном от программного обеспечения - драйвера хоста, ну и от самого хоста, конечно.
Блин... не хотелось бы драйвер хоста переписывать... На него даже даташита не дают... (VT6212)
Да и смысла в этом никакого... может разве драйвер шины, но он, поди, ещё страшнее...

Придётся на PCMCIA переезжать, похоже

[Oldring]

Менять архитектуру выйдет недёшево... Проект не мой и исходников нет.
По идее, должно быть около 1/8 миллисекунды на интерраптных ендпоинтах, т.к. микрокадр именно такого размера. Но мне этого будет недостаточно.

interrupt - у него однонаправленный обмен. Вам ведь нужно двунаправленный?
latency PCI шины еще ограничено количеством промежуточных мостов. Чем современнее компьютер - тем он больше.

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

[qqqqqq]

interrupt - у него однонаправленный обмен. Вам ведь нужно двунаправленный?
latency PCI шины еще ограничено количеством промежуточных мостов. Чем современнее компьютер - тем он больше.

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

На АРМ надо будет перетащить довольно много PC-шного софта, к которому как раз нет исходников... Проще будет поставить туда целиком PC да ещё и с WINXP системой, т.к. софт под неё (хотя, может и на 95й пойдёт...), прицепив её изернетом. но в планируемые 50$ (сейчас девайс на LPT столько стоит) или хотя бы в 100$ это уже не впишется. А посему и связываться смысла нет.

[qqqqqq]

Возникло у меня тут предположение одно....
Если практически возможно получить поток 40 Мбайт/с и отклик при этом не менее 2мс, то объём данных, которые уже ушли из источника, но ещё не дошли до приёмника, составляет примерно 80 кбайт. Это суммарный объём всех фиф устройств/мостов/драйверов.

В CY7C68001 фифа 1 кбайт.
В мосте PCI-USB (он же USB-хост) не знаю, но быть ей больше двух макс. пакетов тоже смысла нет.
В мосте (внешняя шина процессора)-PCI вроде как одна страница (4 кбайта), т.к. при непрерывной записи в PCI, он выставляет STOP после каждых 4х кбайт.
Осталось ещё около 70 кбайт. Подозреваю, что они находятся в драйверах.
Осталось как-то их у драйверов выцарапать... Может быть у них даже есть какие-нибудь функции для этого.
У меня нехватка информации по общению с драйвером шины. Где бы почитать про него?

[oran-be]

Чего то как то совсем непонятно.... У шины время кадра на полной скорости 1 мС, а на высокой микрокадр - 0.125 мс. В течении этого времени в самом худшем случае ( это тот случай, если имеется простейший планировщик пакетов - один запрос в кадре) мы буим иметь задержки 2 мСек и 0.25 мСек соответственно. Хотя я еще ни разу не видел простых планировщиков пакетов. На полной скорости шина умудряется в течении 1 мсек пропустить 64 булк пакета туда и обратно при условии, что функция не тормозит с ответом и она на шине единственная. Вопрос заключается в том, каким образом измерялось время реакции. Если через GUI, то можно получить время реакции и больше.
Вообще при таких скоростях самая большая проблема - это грамотная организация потока записи в драйвер и вычитывания из него.

Сообщение отредактировал oran-be - Oct 20 2007, 11:11

[Седой]

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

a также организация обмена драйвера с устройством - ведь можно запустить чтение IN пакета до записи OUT.

[blackfin]

Спецификация USB (равно как и PCI) вроде бы эту латентность не ограничивает.

Так то оно так, но USB Root-Hub скорей всего подключен через шину PCI,
так что для него тоже имеет значение установки BIOS'а.
Попробуйте уменьшить в BIOS'е PCI_Latency_Timer, скажем, до восьми.
По умолчанию, PCI_Latency_Timer обычно равен 32, а это при частоте PCI шины 33 МГц
дает задержку на доступ к шине равную 32*30 нс = 0.96 мкс.
Поскольку для обслуживания прерывания требуется несколько обращений к шине PCI,
это может приводить к задержке в несколько мкс.

Сообщение отредактировал blackfin - Oct 20 2007, 15:40

[Oldring]

Чего то как то совсем непонятно.... У шины время кадра на полной скорости 1 мС, а на высокой микрокадр - 0.125 мс. В течении этого времени в самом худшем случае ( это тот случай, если имеется простейший планировщик пакетов - один запрос в кадре) мы буим иметь задержки 2 мСек и 0.25 мСек соответственно. Хотя я еще ни разу не видел простых планировщиков пакетов. На полной скорости шина умудряется в течении 1 мсек пропустить 64 булк пакета туда и обратно при условии, что функция не тормозит с ответом и она на шине единственная.

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

[Седой]

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

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

1. Устройство реализует два endpoint - одно OUT (запрос) и одно IN (ответ).
2. Драйвер реализует обработчик определенного DeviceControl - запрос/ответ, запрашиваемый приложением.
3. В этом обработчике драйвер делает следующее:
3.1. Создает URB для IN и направляет его нижележащему драйверу (шины), обязательно указывая функцию завершения, назовем ее CompleteIN .
3.2. Создает URB для ОUТ с данными, полученными от приложения, и также направляет его драйверу шины с функцией завершения CompleteOUT.
3.3. Устанавливает флаг PENDING.
4. Функции завершения делают следующее:
CompleteIN: завершает DeviceControl с данными полученными от устройства (ответ).
CompleteOUT: если произошла ошибка, то прерывает запрос IN и завершает DeviceControl c ошибкой, если нет - не делает ничего.

Реализация такого механизма позволит устройству не только максимально быстро ответить на запрос (даже в пределах одного фрейма), но и передавать данные хосту во время приема пакетов транзакции запроса.

PS0. Насколько я знаю, ни один из фирменных драйверов (Cypress, Silabs, NXP, Atmel, FTDI) не имеет такого механизма, так что придется делать свой драйвер.
PS1. Для транзакций, больших длины пакета, возможно можно поменять местами 3.1. и 3.2.
PS2. Возможно, такой механизм можно использовать и с фирменным драйвером, запуская функцию чтения в отдельном потоке раньше функции записи в другом потоке. Но это потребует работы с синхронизацией потоков. ИМХО, возни больше чем с драйвером.
PS3. Можно также попробовать с фирменными драйверами, если они позволяют, поиграть с overlapped.
PS4. Вышеизложенный механизм работает - используем в своих драйверах.

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

[Oldring]

Давайте конкретизируем задачу.

...

3. В этом обработчике драйвер делает следующее:
3.1. Создает URB для IN и направляет его нижележащему драйверу (шины), обязательно указывая функцию завершения, назовем ее CompleteIN .
3.2. Создает URB для ОUТ с данными, полученными от приложения, и также направляет его драйверу шины с функцией завершения CompleteOUT.
3.3. Устанавливает флаг PENDING.
4. Функции завершения делают следующее:
CompleteIN: завершает DeviceControl с данными полученными от устройства (ответ).
CompleteOUT: если произошла ошибка, то прерывает запрос IN и завершает DeviceControl c ошибкой, если нет - не делает ничего.

И какое в результате получилось минимальное наблюдаемое время отклика? У меня, когда я пытался добиться от такой схемы минимального времени от USB 1.1 - 2 мс на цикл. И, кстати, при прерывании IN запроса иногда время уходило в десятки миллисекунд.

[Седой]

И какое в результате получилось минимальное наблюдаемое время отклика? У меня, когда я пытался добиться от такой схемы минимального времени от USB 1.1 - 2 мс на цикл. И, кстати, при прерывании IN запроса иногда время уходило в десятки миллисекунд.

Я уже писал:

позволит устройству не только максимально быстро ответить на запрос (даже в пределах одного фрейма), но и передавать данные хосту во время приема пакетов транзакции запроса

Если вы переводите IN в stall - то так и будет.

[Oldring]

Я уже писал:

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

Я уже писал:
Если вы переводите IN в stall - то так и будет.

Уже точно не помню - кажется я OUT в STALL пытался переводить.

[Седой]

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

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

[Oldring]

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

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

[Седой]

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

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

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

[qqqqqq]

Чего то как то совсем непонятно.... У шины время кадра на полной скорости 1 мС, а на высокой микрокадр - 0.125 мс. В течении этого времени в самом худшем случае ( это тот случай, если имеется простейший планировщик пакетов - один запрос в кадре) мы буим иметь задержки 2 мСек и 0.25 мСек соответственно. Хотя я еще ни разу не видел простых планировщиков пакетов. На полной скорости шина умудряется в течении 1 мсек пропустить 64 булк пакета туда и обратно при условии, что функция не тормозит с ответом и она на шине единственная. Вопрос заключается в том, каким образом измерялось время реакции. Если через GUI, то можно получить время реакции и больше.
Вообще при таких скоростях самая большая проблема - это грамотная организация потока записи в драйвер и вычитывания из него.

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

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

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

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

Так то оно так, но USB Root-Hub скорей всего подключен через шину PCI,
так что для него тоже имеет значение установки BIOS'а.
Попробуйте уменьшить в BIOS'е PCI_Latency_Timer, скажем, до восьми.
По умолчанию, PCI_Latency_Timer обычно равен 32, а это при частоте PCI шины 33 МГц
дает задержку на доступ к шине равную 32*30 нс = 0.96 мкс.
Поскольку для обслуживания прерывания требуется несколько обращений к шине PCI,
это может приводить к задержке в несколько мкс.

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

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

[Седой]

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

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

[qqqqqq]

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

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

[Седой]

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

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

Зачем ждать 40мс?

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

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

[qqqqqq]

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

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

Попробую EZUSB...

[qqqqqq]

Попробую 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

[qqqqqq]

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

Проверил ваше утверждение. Результат отрицательный. Время от 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

[Седой]

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

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

[qqqqqq]

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

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

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

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


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

[aaarrr]

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

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

[Седой]

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

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

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

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

[AndreyS]

Добрый день.


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

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

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

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

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

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

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

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

Удачи.

[Седой]

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

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

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

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

Единственное что интересно кто как решает проблему передачи?? Мне пришлось завести в железке таймер по которому в тото же пайп кидается спец пакет. Дабы не завесить поток на вычитку. Ну нехотел я заводить второй канал для проверки наличия данных да еще на интеррапт. Да и буфер у нас для сих вещей маловат. А входной поток большой (ну не дикий, но большой для такого буфера и всяких там паралельных задачь).

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

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

[qqqqqq]

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

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

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

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

Единственное что интересно кто как решает проблему передачи?? Мне пришлось завести в железке таймер по которому в тото же пайп кидается спец пакет. Дабы не завесить поток на вычитку. Ну нехотел я заводить второй канал для проверки наличия данных да еще на интеррапт. Да и буфер у нас для сих вещей маловат. А входной поток большой (ну не дикий, но большой для такого буфера и всяких там паралельных задачь).

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

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

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

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

[Седой]

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

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

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

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

[AndreyS]

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

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

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

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

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

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

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


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

Удачи.

[Седой]

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

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

[Oldring]

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

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

[AndreyS]

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

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

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

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

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

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

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

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

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

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

[qqqqqq]

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

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

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

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

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

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

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

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

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

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

[Oldring]

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

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

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

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

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

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

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

[Седой]

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

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