Седой 0 23 октября, 2007 Опубликовано 23 октября, 2007 · Жалоба До сих пор не до конца понимаю. Последовательность команда-ответ-команда-ответ, если вторая команда зависит от первого ответа и не может быть выдана программой до его получения, сколько миллисекунд по минимуму займет? Если вести речь о задержке между запрос-ответ и вторым запрос-ответ - то точно не меньше 1 мс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Oldring 0 23 октября, 2007 Опубликовано 23 октября, 2007 · Жалоба Если вести речь о задержке между запрос-ответ и вторым запрос-ответ - то точно не меньше 1 мс. Вот и я о чем. Мне удавалось из USB 1.1 выжать 2 миллисекунды на транзакцию в подобном режиме. Было интересно, помогают ли чем-либо микрофреймы в 2.0, по которым могут генерироваться прерывания в 8 раз чаще, но которые должны быть активированы в регистрах хоста? Если не помогают - значит, Винды их не используют. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 23 октября, 2007 Опубликовано 23 октября, 2007 (изменено) · Жалоба помогают ли чем-либо микрофреймы в 2.0, по которым могут генерироваться прерывания в 8 раз чаще, но которые должны быть активированы в регистрах хоста? Если не помогают - значит, Винды их не используют. Не знаю. Но судя по требованию Microsoft - минимальной длительности обработчика прерывания (конкретное значение не указывается, но судя по требованию на spinlock не более 25-30 мкс) - то вряд ли. Изменено 23 октября, 2007 пользователем Седой Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
codavr1 0 23 октября, 2007 Опубликовано 23 октября, 2007 · Жалоба Чего то как то совсем непонятно.... У шины время кадра на полной скорости 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 циклов - пауза. А проц в это время ждёт чего-то... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 24 октября, 2007 Опубликовано 24 октября, 2007 · Жалоба Получается время от 20 до 100 мс. 40 мс в среднем. Все правильно, так и будет при таком использовании. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
codavr1 0 24 октября, 2007 Опубликовано 24 октября, 2007 · Жалоба Все правильно, так и будет при таком использовании. Непонятно, что мешает драйверу при свободной шине отправить запрос на чтение сразу при получении этого запроса от приложения? Зачем ждать 40мс? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 24 октября, 2007 Опубликовано 24 октября, 2007 · Жалоба Непонятно, что мешает драйверу при свободной шине отправить запрос на чтение сразу при получении этого запроса от приложения? По CyUSB ничего сказать не могу, нет исходников. Попробуйте EzUsb. Зачем ждать 40мс? Это вы спросите у Microsoft и Cypress. PS. Какую версию SuiteUSB используете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
codavr1 0 24 октября, 2007 Опубликовано 24 октября, 2007 · Жалоба PS. Какую версию SuiteUSB используете? Версия драйвера CYUSB 1.07.0000.0, но пробовал и с более старыми - результат такой же. Команда IOCTL_ADAPT_SEND_NON_EP0_TRANSFER директовую команду не пробовал, но кажется, результат не изменится... Попробую EZUSB... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
codavr1 0 26 октября, 2007 Опубликовано 26 октября, 2007 · Жалоба Попробую 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 мс, как и измерилось приложением. По итогам данного измерения можно резюмировать, что основную задержку даёт микрософтовский диспетчер ввода-вывода... Осталось его как-то обойти и латентность уменьшится ещё в несколько раз. до полмиллисекунды. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 26 октября, 2007 Опубликовано 26 октября, 2007 (изменено) · Жалоба Осталось его как-то обойти и латентность уменьшится ещё в несколько раз. до полмиллисекунды. Для EzUsb можно только через использование раздельных потоков чтения и записи, запуская чтение раньше записи. Изменено 26 октября, 2007 пользователем Седой Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
codavr1 0 26 октября, 2007 Опубликовано 26 октября, 2007 · Жалоба Для 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 26 октября, 2007 Опубликовано 26 октября, 2007 · Жалоба Проверил ваше утверждение. Результат отрицательный. Время от 20 до 60мс. Вот лог: Судя по логу, Вы что-то не так сделали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
codavr1 0 26 октября, 2007 Опубликовано 26 октября, 2007 · Жалоба Судя по логу, Вы что-то не так сделали. Возможно.. Вы говорили, что надо запускать чтение раньше записи и делать это в отдельном потоке. Так я и сделал. И по логу видно, что я сделал именно так. Судя по логу, Вы что-то не так сделали. Прошу прощения. Поставил sleep(0) в цикл ожидания готовности приёма и всё стало гораздо лучше. Среднее время отклика = 0.9 мс. Спасибо. Я наверно, и с CYUSB-драйвером погорячился, когда его обругал... надо будет ещё раз попробовать когда-нибудь... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 26 октября, 2007 Опубликовано 26 октября, 2007 · Жалоба Я наверно, и с CYUSB-драйвером погорячился, когда его обругал... надо будет ещё раз попробовать когда-нибудь... Да, в отличие от EzUSB, на нем можно получить больше 64000 байт в секунду на bulk передаче. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 27 октября, 2007 Опубликовано 27 октября, 2007 (изменено) · Жалоба Да, в отличие от EzUSB, на нем можно получить больше 64000 байт в секунду на bulk передаче. Откуда Вы это взяли. В первый раз слышу, а по исходнику не вижу. Если Вы имеете в виду MAX_TRANSFER_SIZE = 64 kb, то это к скорости никакого отношения не имеет. Если Вам нужно за один раз передавать больше, что мешает изменить это значение? http://support.microsoft.com/default.aspx?...b;en-us;Q832430 Изменено 27 октября, 2007 пользователем Седой Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
