Jump to content

    

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

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

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites
Неужели этого и добивались разработчики данной шины?

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

Share this post


Link to post
Share on other sites
Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.

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

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

 

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

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

 

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

 

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

Share this post


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

 

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

 

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

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

 

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

 

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

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

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

 

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

Share this post


Link to post
Share on other sites
Менять архитектуру выйдет недёшево... Проект не мой и исходников нет.

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites
interrupt - у него однонаправленный обмен. Вам ведь нужно двунаправленный?

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by oran-be

Share this post


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

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

Share this post


Link to post
Share on other sites
Спецификация USB (равно как и PCI) вроде бы эту латентность не ограничивает.
Так то оно так, но USB Root-Hub скорей всего подключен через шину PCI,

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

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

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

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

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

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

Edited by blackfin

Share this post


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

 

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

Share this post


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

 

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

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

Edited by Седой

Share this post


Link to post
Share on other sites
Давайте конкретизируем задачу.

 

...

 

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

Share this post


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

 

Я уже писал:

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

 

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

Share this post


Link to post
Share on other sites
Я уже писал:

 

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

 

Я уже писал:

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this