[Kopart 0]

странно, раньше альтеровцы юзали libusb, сейчас видно что в jtagd слинкована статически их либа работы с usb. если квартус юзается не последний - имеет смысл почитать RN на предмет исправления ошибок в jtagd - и если что заапгрейдиться. также можно глянуть что происходит, путем включения отладки в usbcore (modprobe usbcore usbfs_snoop=1)

В fstab аналогично.

Квартус версии 9.0 без sp1 (вроде sp1 не должен это исправить - хотя скачаю проверю). В 8.1 было аналогично.

[Harbour 0]

это ... а может шнурок глючный - сравнение скорости производилось на этой же тачке ?

[Kopart 0]

это ... а может шнурок глючный - сравнение скорости производилось на этой же тачке ?

Все было идентично, кроме ОСи.

Проверил 9.0сп1 - аналогично.

А где смотреть результат - modprobe usbcore usbfs_snoop=1?

 

 

Вот что ответил на форуме альтеры.

I guess, the performance difference is due to USB driver operation. I'm aware of similar effects with Windows applications that are operating the USB I/O in an inappropriate way. As long as the driver has no configurable settings (as the original Windows FTDI drivers have for FIFO latency), you have probably no option to influence the USB Blaster performance. Except for reporting to Altera support and hope for a change.

 

 

Но я так понял, что у Вас в слаке и на больших накопления разницы не заметно?!

[vadimuzzz 0]

Но я так понял, что у Вас в слаке и на больших накопления разницы не заметно?!

а насколько большие? вот сеегодня гонял 4096*24бит - пойдет? 1-2 секунды сливает.

[Kopart 0]

а насколько большие? вот сеегодня гонял 4096*24бит - пойдет? 1-2 секунды сливает.

Сейчас проверил другую глубину выборки.

Результаты:

16384*  ~80бит - 2 сек (винда)

2048  *  ~80бит - 5 сек (кубунту - уже в 2 раза больше, чем в винде)

16384*  ~80бит - 40 сек (кубунту)

 

Угадывается линейная зависимость...  

[vadimuzzz 0]

Сейчас проверил другую глубину выборки.

Результаты:

16384*  ~80бит - 2 сек (винда)

2048  *  ~80бит - 5 сек (кубунту - уже в 2 раза больше, чем в винде)

16384*  ~80бит - 40 сек (кубунту)

 

Угадывается линейная зависимость...  

фигасе у вас выборки :blink: тогда наверно у всех так тупит. можно конечно код драйвера ftdi поковырять на предмет размера буферов и тайм-аутов. на глаз видно, что в первом случае явно как full speed, а вот 2 последних смахивают на low speed. хотя это противоречит логам, что вы приводили.

[vadimuzzz 0]

поковырялся тут, есть версия. похоже usbblaster работает через libusb. этих libusb 2 версии: v0.1 и v1.0.

из документации на libusb v0.1:

"All functions in libusb v0.1 are synchronous, meaning the functions block and wait for the operation to finish or timeout before returning execution to the calling application. Asynchronous operation will be supported in v1.0, but not v0.1."

выдержка из логов:

"E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms

E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms"

сильно подозреваю, что обмен идет через libusb v0.1(судя по зависимостям, тьма пакетов в системе на нее завязаны, а на libusb v1.0 - только 1). фиг знает как работает виндовый драйвер, но синхронный режим с маленькими буферами(64 байта, см. логи) и большие объемы данных как-то плохо сочетаются.

[Harbour 0]

М-да, выборки однако ... нафига столько ? мож лучше триггер дописать до нужного участка ? с libusb - альтеру придеться долго пинать ногами, чтобы они чего-там пересобрали с новой либой - причем думаю что API libusb тоже слегка поменялись в v1.0 - так что еще придется слегка изменить jtagd

[Kopart 0]

М-да, выборки однако ... нафига столько ? мож лучше триггер дописать до нужного участка ? с libusb - альтеру придеться долго пинать ногами, чтобы они чего-там пересобрали с новой либой - причем думаю что API libusb тоже слегка поменялись в v1.0 - так что еще придется слегка изменить jtagd

Вопрос не в конкретной глубине накоплений, можно и меньшую использовать. А вот если сигналов надо много - то либо ждать, либо переразводить.

Основной вопрос был - от чего такая разница в Виндовс и в линукс. Может это от настроек зависит?

Но похоже на данный момент, что от либы...

сильно подозреваю, что обмен идет через libusb v0.1(судя по зависимостям, тьма пакетов в системе на нее завязаны, а на libusb v1.0 - только 1). 

А эта либа к чему привязана - к mainwin или к ядру?

[SM 0]

А эта либа к чему привязана - к mainwin или к ядру?

Ни к тому, ни к другому. Скорее всего к jtagd. Или к какой-нить квартусовой lib???.so - по крайней мере похоже, что она статически слинкована в 7.1 квартусе

[Kopart 0]

Проверил все тоже самое, только SignalTap запустил в гостевой ВинХР, которая работал VirtualBox на линукс.

Там подключил тот же самый USB blaster. (При этом как-то драйвера хостовго Линукса учавствуют в виртуалке?)

И итог - в виртуалке SignalTap работает также быстро как и в "чистой" WinXP.

 

Те это получается различия в дистрибутивы Ква для linux? 

[Harbour 0]

Различия, как уже было логически доказано, в способе работы с USBBB2 - в linux версии (jtagd) альтера чего-то намудрила своего, так как даже старый синхронный libusb v0.1 _так_ тормозить не может

[Kopart 0]

Различия, как уже было логически доказано, в способе работы с USBBB2 - в linux версии (jtagd) альтера чего-то намудрила своего, так как даже старый синхронный libusb v0.1 _так_ тормозить не может

Есть обновление по ситуации:

Возможно, оно как раз и подтверждает Ваши слова.

 

SignalTap в linux работает также быстро  как и в винде, если подключаться к удаленному jtag серверу на виндовой машине по сети. 

Т.е если шнурок подцеплен к винде - то даже работая по сети не заметно разницы в скорости, если управлять с линуксового SignalTap.