qemu_kvm: проблемы при работе последовательного порта через tcp

Это надо в qemu-devel@ репортить. С подробным описанием.

Я практически только tcp и использую, брат жив. Но нагрузки небольшие - консоль.

А не может быть, что ты их быстрее чем 115Кбод передаёшь?

А не может быть, что ты их быстрее чем 115Кбод передаёшь?

Похоже. Мне между прочим даже на 300бодах iperf 172Kbps выдаёт. Так что быг на лицо

iperf умеет гонять через /dev/ttySX ?

iperf умеет гонять через /dev/ttySX ?

На /dev/ttySX поднимается ppp, а потом запускается iperf

Аааа, тогда точно здесь собака зарыта. Вот реально не помню уже кто лочил порт по скорости для диалапа, но емним это был chat который потом передавал его ppp. Сам ppp такого (установка параметров ком порта ) не умеет... вроде... но может и гоню...

Умеет.
PPP работает, даже если ты подцепишься через minicom, и запустишь pppd - то коннект установится
Ещё можно делать так:

ssh root@194.28.115.18 -t pppd noauth 172.20.1.1:194.28.116.1

PPP работает, даже если ты подцепишься через minicom

Здесь все понятно, так как параметры порта выставляет minicom
И с пулами так же понятно, так как есть «прослойка».
Но вот что у вас на данный момент является той самой «прослойкой» не понятно. Я знаю что в тупом варианте можно просто «дуть» в последовательный порт и также бездумно читать из него.
ЗЫ Этим грешили и старые атс-ки, и пром. контроллеры, для них специально приходилось оставлять старенькие машинки, например у меня под контроллеры 486й ноут был в работе как минимум до 2008-го года.
ЗЫЫ Я сам по лени писал софтинки которые просто «дули» в порт, по неопытности точнее, еще в 90-х :)