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

[qqqqqq]

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

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

[AndreyS]

Добрый день.


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

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

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

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

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

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

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

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

Удачи.

[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-х).

Удачи.

[Oldring]

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

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