-Al- 0 20 января, 2007 Опубликовано 20 января, 2007 · Жалоба Потом я еще увеличил число пакетов и длину очереди, скорость еще чуток возросла, но ненамного. Однако, выплыл ньюанс, гробящий на корню мою быструю передачу. После примерно полутора минут передачи скорость падает больше чем на порядок и дальше болтается у этой очень небольшой величины. Что бы это могло значить? Вот поясняющие скриншоты: .... Особенно настораживает падение скорости передачи после полутора минут (!) после начала передачи. Не обращайте на падение скорости внимания, это ошибка программы. Такое происходит потому, что расчет скорости ведется по формуле <суммарное переданное число байт>/<время передачи>. Просто суммарное переданное число байт быстро выходит за пределы unsigned long (32бита, 4ГБ), ну и соответсвенно, отсчет опять начинается с нуля, а время продолжает тикать как обычно :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 20 января, 2007 Опубликовано 20 января, 2007 · Жалоба Не обращайте на падение скорости внимания, это ошибка программы. Такое происходит потому, что расчет скорости ведется по формуле <суммарное переданное число байт>/<время передачи>. Просто суммарное переданное число байт быстро выходит за пределы unsigned long (32бита, 4ГБ), ну и соответсвенно, отсчет опять начинается с нуля, а время продолжает тикать как обычно :)Огромное спасибо, коллега, за разъяснение! Господи, сколько бессмысленных усилий пришлось бы потратить, чтобы понять этот момент! Я исправил переменную с ULONG на _int64 и все стало нормально: уже более 15 минут скорость держится стабильно на уровне 39957 КБайт/сек. Т.е. этот вопрос полностью снят. Большое спасибо! :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 21 января, 2007 Опубликовано 21 января, 2007 · Жалоба Привет! "Играем дальше." (С) Жванецкий :-) Немножко исправил приложение Streamer, сделал передачу данных по Interrupt endpoint. Получил, как и положено, 8000 КБайт/сек. Так получилось потому, что я задал период опроса 1 микрофрейм, а величина ендпойнты составляет 1024 байт. Для контроля правильности эксперимента я параллельно запустил прежний Streamer с Bulk endpoint, который выжимает канал USB досуха. Как и следовало ожидать, эти 8000 КБайт были "откушены" от канала Bulk. Вот скриншоты (Interrupt и Bulk): После этого я обратился к спецификации USB 2.0 (раздел 5.9 High-Speed, High Bandwidth Endpoints, стр. 56) и выставил число транзакций на микрофрейм равным 3-м. Однако, скорость передачи не изменилась! Вот скриншот: Причем, число принимаемых байт верное (т.е. если задано 256 буферов по 3072 байта, то именно столько и принимается). Как это понимать? Что я делаю не так? P.S. Настораживает то, что эти биты, которые задают число транзакций на микрофрейм, не маскируются приложениями. Т.е. USB View, к примеру, рапортует: wMaxPacketSize: 0x1400 (5120). Правда Streamer понимает правильно, но все равно как-то криво рапортует размер пакета в 3072 байта. Это ведь неверно! Размер пакета остался 1024 байт, это число пакетов на микрофрейм должно было бы быть три. А при задании 2-х пакетов на микрофрейм передача вообще не работает... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 22 января, 2007 Опубликовано 22 января, 2007 · Жалоба 2 ALL... похвастайтесь...Попробую ;-) Сегодня запустил свое приложение на дохлой embedded-материнке от VIA (плата EPIA SP). Удивился немерянно! На рабочем месте у меня компьютер Intel P4, 3066 MHz, плата MSI 865PE Neo3-V, чипсет i865PE, который дает 40000 КБайт/сек, а эта слабенькая платка качает со скоростью порядка 44000 КБайт/сек! Вот скриншот: Однако!... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Warlord 0 22 января, 2007 Опубликовано 22 января, 2007 (изменено) · Жалоба Проделал те же шаги, что и jur, касательно bulk передачи, вот мой скриншот: результаты - один в один :) Блок питания не шумит, никаких подозрительных звуков не заметил :) Результат очень похож на практический потолок для Bulk. Изменено 22 января, 2007 пользователем Warlord Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Warlord 0 22 января, 2007 Опубликовано 22 января, 2007 (изменено) · Жалоба Проделал тоже самое для Interrupt, и здесь результаты одинаковы: Что касается числа принимаемых байт, то здесь вот какие дела. Камень дает хосту дескриптор, где в младших 11 битах поля wMaxPacketSize указывает размер буфера и в следующих 2-х еще что-то (спецификации 2.0 нет:(. Так вот, Streamer как это сказано в хелпе берет это значение и вычисляет MaxPktSize как If wMaxPacketSize is 0x1400 (binary = 0001 0100 0000 0000) MaxPktSize = [100 0000 0000 binary] * [10 binary + 1] = 1024 * 3 = 3072 далее это число, умноженное на кол-во посылок за раз (Packets per Xfer) передается драйверу, который заготавливает место под данные. Далее, драйвер получает за один прием это число байт и передает аппилкухе. Все. Т.е. те 3072 байта что показывает Streamer никоем образом не влияют на размер передаваемого пакета за микрофрейм. Вот сколько там действительно передается, это вопрос. Судя по тому что скорость предачи не изменилась и осталась на уровне 8МБ\с, то могу предположить что за 1мкФрэйм передаются те же самые 1024 байта :\ Изменено 22 января, 2007 пользователем Warlord Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 24 января, 2007 Опубликовано 24 января, 2007 · Жалоба Результат очень похож на практический потолок для Bulk.Точно! Наверное, это зависит от современных чипсетов. Т.е. 44 тысячи Байт/сек. - это максимально достижимая цифра без каких-то специальных (экзотических) уловок на текущих материнках. (Что интересно, сегодня гонял микросхему (FX2LP) на максимальной скорости весь день - температура ничуть не возросла! Комнатная!) Что касается числа принимаемых байт, то здесь вот какие дела. Камень дает хосту дескриптор, где в младших 11 битах поля wMaxPacketSize указывает размер буфера и в следующих 2-х еще что-то (спецификации 2.0 нет:().Думаю, что стоит скачать. Полезный документ. Хотя и тяжелый для усвоения... Вот что написано в разделе 5.9 High-Speed, High Bandwidth Endpoints: Table 5-11. wMaxPacketSize Field of Endpoint Descriptor: Bits 15..13 - Reserved, must be set to zero Bits 12..11 - Number of transactions per microframe Bits 10..0 - Maximum size of data payload in bytes Т.е. число транзакций на микрофрейм устанавливается равным трем, а число передаваемых байт не изменяется, как было 8000 Байт/сек так и остается... При двух - вовсе не работает... Чертовщина какая-то... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Warlord 0 24 января, 2007 Опубликовано 24 января, 2007 (изменено) · Жалоба Остается только вопрошать технарей Cypress. Пробовал создать аккаунт у них на сайте - дохлый номер, ошибка на странице :( Изменено 24 января, 2007 пользователем Warlord Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 24 января, 2007 Опубликовано 24 января, 2007 · Жалоба Остается только вопрошать технарей Cypress.Да, ты прав. Только... Общение с их техподдержкой - спорт не для слабых :-) Нужно будет филигранно сформулировать вопрос, отточить каждую букву. Т.к. первым ответом у них обычно бывает повторение половины моего же вопроса :-) Но, нужно отдать им должное, при достаточной настойчивости ответ получить все-таки можно. По поводу аппаратной проблемы с их CY7C68001 они мне даже раза два на работу звонили! Правда, я не понял ни хрена, сказал, что письмом отвечу :-) Оказалось, моя ошибка была... Я на эту тему в этом форуме даже тред поднимал. Пробовал создать аккаунт у них на сайте - дохлый номер, ошибка на странице :(А я создал год-полтора назад. Думаю, что ошибка на странице возникает из-за их идиотского сайта, написанного какими-то web-пионэрами, мать их... Попробуй с другого броусера зайти, с Оперы какой или Мозиллы. Пошел формулировать вопрос... Полученные ответы сразу озвучу в этом треде. Думаю в начале следующей недели, т.к. остаток этой недели придется угробить на донесение до них сути моего вопроса ;-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Warlord 0 24 января, 2007 Опубликовано 24 января, 2007 · Жалоба Давай я переведу вопросы, если ты собираешься писать их на английском, а на ту страницу я с трех браузеров заходил - бесполезно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 26 января, 2007 Опубликовано 26 января, 2007 · Жалоба Давай я переведу вопросы, если ты собираешься писать их на английскомСпасибо, я уже послал вопрос. Уже завершился первый раунд :-) На мой вопрос про передачу 1024-байтных блоков мне посоветовали применить Bulk endpoint :-))) "Играем дальше..." © М.Жванецкий. а на ту страницу я с трех браузеров заходил - бесполезно.Во, ёлки... Вот бы пройтись серпом по избранным местам их web-дезайнера... Мечта... ;-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 22 февраля, 2007 Опубликовано 22 февраля, 2007 · Жалоба Я обещал сообщить результаты переписки с фирмой Сайпресс в этой теме. Напоминаю, что речь идет о достижении приемлемой скорости передачи данных по Interrupt endpoint с размером пакета 1024 байта. Вы не подумайте, я не забыл и не забросил. Просто я их настолько озадачил, что уже заканчивается третья неделя с тех пор, как я послал им результаты своих экспериментов, а они до сих пор "переваривают"... ;-) В начале недели я им напомнил о себе, что, мол, "Ау! Люди!", но они пока молчат... И CASE не закрывают... Ждем... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
torik 0 24 февраля, 2007 Опубликовано 24 февраля, 2007 · Жалоба Думается мне, что они не хотят отвечать... Просто игнорируют нехорошые люди :( Завалить их надо письмами! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jur 0 7 марта, 2007 Опубликовано 7 марта, 2007 · Жалоба Думается мне, что они не хотят отвечать... Просто игнорируют нехорошые люди :( Завалить их надо письмами! Есть новости! Мое упорство вызвало у них реакцию отторжения... Несколько недель назад они мне писали, что, цитирую, "микросхема CY7C680013A позволяет передавать данные по Interrupt endpoint с размером пакета 1024 со скоростью 20 и более МБ/сек". У меня это не получилось и я послал им два своих проекта: для микросхемы и для компьютера. Несколько дней назад был получен ответ (после моего напоминания, что я совсем не забыл ;-) ). Типа, извиняемся за долгое молчание. Проверьте, в чем проблема на вашем компьютере. Не является ли система "бутылочным горлышком", которое не позволяет передавать быстрее, чем 8000 КБ/сек. И вообще, мол, не парь нам мозги, а делай на булке :-) Встает резонный вопрос: "А за базар кто ответит?!" :-) Раз микросхема позволяет - в чем проблема? В моей системе? Вполне возможно. Тогда я пробую на разных материнках (на Интелловских 848 и 865, а также на слабой встроенной embedded-материнке от VIA и более мощной от Kontron). Везде получаю стабильный результат: 40 и более МБ/сек на булке и те же 8000 КБ/сек на Interrupt. Хочу спросить уважаемых коллег: может быть кто-то из Вас желает присоединиться к эксперименту? Я могу предоставить два проекта (под Кейл для микросхемы, и под VC 6.0 для компьютера) для проверки результатов. Может нам удастся найти ошибку в моих проектах (это, по сути, собственные образцы примеров от Сайпресса)? Анализ этих моих проектов в самой Сайпресс (вот как раз на это они и потратили более двух недель) криминала не выявил, но может быть на самом деле что-то было упущено? Если же окажется, что в проектах все хорошо, то, на самом деле, давайте завалим их письмами! :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
torik 0 8 марта, 2007 Опубликовано 8 марта, 2007 (изменено) · Жалоба С удовольствием присоединюсь, тема интересная - сам пишу на Кейл. Думаю, может стоит попробовать это дело под свой проект приспособить, чтобы ощутить разницу Изменено 8 марта, 2007 пользователем torik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
