PPP - странное поведение на высоких скоростях

про паузы - я бы посмотрел статистику ошибок на интерфейса ppp. Если тестируется при помощи протокола tcp, то потери будут давать ощутимое снижение скорости.

И еще - на сколько симметрична скорость ?

А этот Raspberry Pi 2 не на 100% при этом загружен? Может просто не хватает производительности?

Что мешает использовать usb-ethernet? С точки зрения накладных расходов оно выгодно отличается от usb-rs232

Да, тестировалось по tcp, ошибки не смотрел. Основные данные гонятся по udp, и там проседание в скорости аналогичное.

Производительности должно хватать с головой, но это надо будет проверить.

Что мешает использовать usb-ethernet?

Проблема в том, что нужен именно rs232.

Тестировал путем бросания файлов через scp. Вначале передач скорость была повыше, потом в течение нескольких десятков секунд равномерно падала до указанных значений, по крайней мере по показаниям scp.

По поводу симметрии, кстати, интересно. В заглавном посте указана скорость передачи данных от платы к ноутбуку.

Канал от ноута в сторону платы при тестировании оказался примерно в два раза толще, на частотах 3 и 2 МГц. На 1 МГц они примерно одинаковы.

scp - это требование или что было под рукой ? scp очень специфический и достаточно тормозной протокол, да и cpu он должен жрать. А у тебя с одной стороны что-то не шибки шустрое. Ассиметрия скорости может быть изз-за нехватки производительности с одной стороны.

возьми iperf3 - он умеет в обе стороны скорость мерить и процессор не грузит.

Ты просто так изголяешься или какая-то цель есть?

Да, scp просто первое что в голову пришло. Попробую iperf.

Да, есть цель — нужно передавать видео с платы по уарту.

Вообще, плохая идея.

Я недавно пробовал использовать нульмодемный кабель + PPP между двумя серверами для организации heartbeat-линка для Pacemaker/Corosync. Даже на больших битрейтах оно работало так себе, а точнее никак.

С видео, уверен, будет ещё хуже.

а есть возможность сделать 5 проводов и перейти с xonxoff на ctsrts, который обычно поддерживается аппаратно.

Еще debug отключи.

В том то и дело, что работало все прекрасно. Гонялось 1920x1080@60 в реальном времени без каких-либо проблем.

Но потом что-то наворотили и скорость упала.

Нет, задача специфическая, нужно использовать только два провода — RX и TX.

Вообще говоря, желательно даже только один провод — TX в сторону ноута, на потери по барабану.

А ты не пробовал сравнивать скорости при включеном и выключеном ctsrts? Теоретически, после отключения ctsrts должно возрости число ошибок и упасть скорость. А если разницы не будет, то значит что-то не так в консерватории.

А minicom-ом с помощью z-modem-а не пробовал файлы передавать?

PS кроме ppp есть еще slip, он вообще простой и тупой. Правда последний раз я им польззовался в 98 году и как с ним сейчас дело обстоит - не знаю.

Похоже определился виновник — проблема явно на стороне платы.

Поставить дополнительный софт возможности пока не было, поэтому всё с помощью подручных средств. Тупо cat-ом выводился поток на виртуальный порт переходника /dev/ttyUSB0 и на осциллографе обнаружилось, что паузы возникают только на выходе переходника, подключенного к плате, с ноутбучного все нормально улетает.

Так что PPP здесь не при чем, похоже.

Проблема была в USB-драйверах RPi.

Ответ [1] от разработчика:

At high baud rates, you may hit the USB NAK packet throttle threshold on outbound data - we have a crude mechanism implemented to stop FTDI devices from causing interrupt storms that lock the CPU out for extended periods of time. You can probably live with the increased interrupt rate on a Pi2 that comes from reducing the throttle interval.

После отключения NAK holdoff (путем добавления dwc_otg.nak_holdoff=1 в /boot/cmdline.txt на плате) всё заработало как надо, на 3 Mбит/c. Остается правда вопрос, как оно работало раньше.

[1]: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=126010