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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так то оно так, но 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

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

Давайте конкретизируем задачу.
Насколько я понял, автору ветки необходимо получить минимальное время реакции в процессе ЗАПРОС-ОТВЕТ. Сейчас у него следующая ситуация - 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

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

Я уже писал:


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

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



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