[codavr1 0]

Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.

Что-то не этого я ожидал от HS USB.

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

 

Как бы сократить это время раз этак в 40тысяч?...

Похоже, где-то я действую неправильно...

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

Даже не верится...

[VDG 0]

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

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

[Oldring 0]

Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.

Что-то не этого я ожидал от HS USB.

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

 

Как бы сократить это время раз этак в 40тысяч?...

Похоже, где-то я действую неправильно...

 

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

 

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

[codavr1 0]

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

 

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

 

Менять архитектуру выйдет недёшево... Проект не мой и исходников нет.

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

 

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

 

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

Блин... не хотелось бы драйвер хоста переписывать... На него даже даташита не дают... (VT6212)

Да и смысла в этом никакого... может разве драйвер шины, но он, поди, ещё страшнее...

 

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

[Oldring 0]

Менять архитектуру выйдет недёшево... Проект не мой и исходников нет.

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

 

interrupt - у него однонаправленный обмен. Вам ведь нужно двунаправленный?

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

 

По поводу того, что выйдет недешево в любом случае - это понятно.

Не хотите поставить какой-нибудь ARM прямо в систему для быстроты реакции?

[codavr1 0]

interrupt - у него однонаправленный обмен. Вам ведь нужно двунаправленный?

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

 

По поводу того, что выйдет недешево в любом случае - это понятно.

Не хотите поставить какой-нибудь ARM прямо в систему для быстроты реакции?

 

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

[codavr1 0]

Возникло у меня тут предположение одно....

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

 

В CY7C68001 фифа 1 кбайт.

В мосте PCI-USB (он же USB-хост) не знаю, но быть ей больше двух макс. пакетов тоже смысла нет.

В мосте (внешняя шина процессора)-PCI вроде как одна страница (4 кбайта), т.к. при непрерывной записи в PCI, он выставляет STOP после каждых 4х кбайт.

Осталось ещё около 70 кбайт. Подозреваю, что они находятся в драйверах.

Осталось как-то их у драйверов выцарапать... Может быть у них даже есть какие-нибудь функции для этого.

У меня нехватка информации по общению с драйвером шины. Где бы почитать про него?

[a_electronic 0]

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

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

Изменено 20 октября, 2007 пользователем oran-be

[Седой 0]

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

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

[blackfin 22]

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

Так то оно так, но USB Root-Hub скорей всего подключен через шину PCI,

так что для него тоже имеет значение установки BIOS'а.

Попробуйте уменьшить в BIOS'е PCI_Latency_Timer, скажем, до восьми.

По умолчанию, PCI_Latency_Timer обычно равен 32, а это при частоте PCI шины 33 МГц

дает задержку на доступ к шине равную 32*30 нс = 0.96 мкс.

Поскольку для обслуживания прерывания требуется несколько обращений к шине PCI,

это может приводить к задержке в несколько мкс.

Изменено 20 октября, 2007 пользователем blackfin

[Oldring 0]

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

 

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

[Седой 0]

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

 

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

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

Изменено 21 октября, 2007 пользователем Седой

[Oldring 0]

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

 

...

 

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 запроса иногда время уходило в десятки миллисекунд.

[Седой 0]

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

 

Я уже писал:

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

 

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

[Oldring 0]

Я уже писал:

 

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

 

Я уже писал:

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

 

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