Не растет TCP окно при ppp-подключении

[[anp/hsw]]

Здравствуйте!

Столкнулся с удивительной проблемой: у исходящего TCP трафика не происходит window update, в результате чего скорость крайне маленькая (1-2мбит).

Схема подключения такая:

клиент -> свич -> PPP NAS -> свич -> NAT BOX -> внешка

Все это добро подключено через гиговые порты, т.е. проблемы буферов нет (LACP на 2 порта у NAS и на 4 порта у NAT BOX, я пробовал их разваливать до одного порта - это не помогает).

PPP NAS занимается терминацией, NAT BOX - BGP+шейпер+NAT. Все это добро на linux 3.2.

 

До региональный и городских точек все нормально - и исходящий в иходящий в норме, но как только мы начинаем тест до москвы/забугра, так сразу исходящая резко падает с ростом RTT (>80мс).

 

Проверяем через iperf3 и speedtest.net

 

Клиент при подключении ppp (не важно - pptp, pppoe или l2tp) получает входящий поток в силу своих возможностей (в районе 300мбит), но исходящий от него колеблется от 1 до 3мбит.

Если этого же клента подключить по подключению не используя PPP (gre/ipip-тунель, vlan, untagged ethernet), то исходящего он может нагенерить в районе 50 мегабит, и все это пролазит.

UDP исходящий при этом всегда стабильно высокий и без потерь.

Меняем клиента на чистую Win7 с тесового ноутбука - ситуация повторяется.

 

Сняли дампы со всех интерфейсов по цепочке:

В случае с ppp они оказались полностью идентичны за исключением переговоров по MSS при разном MTU. При одинаковом - как зеркало. С ответной стороны не приходит ни tcp window update (а если и приходит - то один-два а весь сеанс) ни tcp window full

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

 

Что делалось и не помогает:

- смена MTU на всех интерфейсов до тунельного (на ethernet с пониженым MTU скорость также высокая)

- подкинуть реальный IP и выключить conntrack на NAS и NAT BOX

- полностью выключить шейперы (исходящий и входящий)

- Полное отключение offload на сетевухах в цепочке

 

Что помогает:

- Задушить исходящую шейпером до ~20мегабит, тогда окно начинает увеличиваться. От 1 до 20 мегабит скорость растет, дальше начинает резко падать. Совсем без шейпера - также низкая.

 

Вот пример iperf до амстердама:

 

gre-тунель до NAS, MTU=1420

Цитата

 

Connecting to host 163.172.208.7, port 5209
[  4] local 192.168.5.34 port 47358 connected to 163.172.208.7 port 5209
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  3.96 MBytes  33.2 Mbits/sec  134    428 KBytes       
[  4]   1.00-2.00   sec  4.83 MBytes  40.5 Mbits/sec    0    488 KBytes       
[  4]   2.00-3.00   sec  5.63 MBytes  47.3 Mbits/sec    0    533 KBytes       
[  4]   3.00-4.00   sec  5.63 MBytes  47.2 Mbits/sec    0    563 KBytes       
[  4]   4.00-5.00   sec  4.83 MBytes  40.5 Mbits/sec    0    582 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec  24.9 MBytes  41.7 Mbits/sec  134             sender
[  4]   0.00-5.00   sec  23.8 MBytes  40.0 Mbits/sec                  receiver
 

 

 

pppoe до NAS, MTU=1420

Цитата

 

[  4] local 192.168.5.34 port 55972 connected to 163.172.208.7 port 5209

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  38.7 KBytes   316 Kbits/sec    0   10.7 KBytes       
[  4]   1.00-2.00   sec  25.8 KBytes   211 Kbits/sec    0   10.7 KBytes       
[  4]   2.00-3.00   sec  40.8 KBytes   335 Kbits/sec    0   10.7 KBytes       
[  4]   3.00-4.00   sec  25.8 KBytes   211 Kbits/sec    0   10.7 KBytes       
[  4]   4.00-5.00   sec  25.8 KBytes   211 Kbits/sec    0   10.7 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec   157 KBytes   257 Kbits/sec    0             sender
[  4]   0.00-5.00   sec   144 KBytes   236 Kbits/sec                  receiver
 

 

 

Т.к. tcp window update посылает удаленный хост, а не локальный, напрямую я повлиять на все хосты интернета я не могу, то определенно должно быть условие, при котором окно начнет увеличиваться.

Но что это за условие?

Проблема определенно в pppd. Но что в ним не так? Обновил до последнего git-среза, но проблему это не решило.

[paradox_]

?

https://www.opennet.ru/base/net/pppoe_mtu.txt.html

[[anp/hsw]]

1 минуту назад, paradox_ сказал:

https://www.opennet.ru/base/net/pppoe_mtu.txt.html

С MTU проблем нет, discovery прекрасно отрабатывает.

К тому же специально проводил тесты с занижением MTU на ethernet и gre-туннелях.

[vlad11]

Наконец-то, хоть кто-то нормально продебажил и озвучил одну из проблем, которой много лет :)

[[anp/hsw]]

Суть бы проблемы еще понять. Я нашел очень много жалоб, где ломалось и чинилось pmtu, но тут оно как раз отрабатывает нормально.

Большинство этих жалоб было на ядрах 3.2.60, 3.2.63-3.2.65, но тут стоит распоследнее 3.2.102.

[sdy_moscow]

9 часов назад, [anp/hsw] сказал:

linux 3.2.

Ядрышко у Вас древнее кстати.

[[anp/hsw]]

3 минуты назад, sdy_moscow сказал:

Ядрышко у Вас древнее кстати.

Да уж какое есть. Но если обновляться на новое, там пол-системы сломается, вылезут новые грабли из разных мест, а это трудозатраты в разы большие, чем просто залатать дыру.

[Saab95]

На микротике нет таких проблем, как описано в первом посте, хотя ядро линукса там не самое последнее.

[[anp/hsw]]

15 минут назад, Saab95 сказал:

На микротике нет таких проблем, как описано в первом посте, хотя ядро линукса там не самое последнее.

Как раз на форуме микротика подобные проблемы я и наблюдал, но они остались без ответа.

[Ivan_83]

В 06.03.2021 в 08:04, [anp/hsw] сказал:

Меняем клиента на чистую Win7 с тесового ноутбука - ситуация повторяется.

У венды тоже есть крутилки.

[[anp/hsw]]

6 минут назад, Ivan_83 сказал:

У венды тоже есть крутилки.

Предлагаете крутить всем, кто заявит от проблеме?

А если там телефон на андроиде без рута или какая-нибудь проприетарная железка? Что крутить будем?

[Ivan_83]

На это форуме была проблема с какой то кошкой используемой в качестве роутера, там тоже решилось крутилками в венде.

Есть несколько вариантов:

1. Это венда тупит если она поднимает ппп подключение, тут или её лечить хотя бы настройками или ставить роутер, который поднимет ппп.

2. Это шейпер химичит с tcp служебкой.

 

Поставьте перед вендой роутер, который подмет ппп и станет понятно кто виноват и что делать.

 

1 час назад, [anp/hsw] сказал:

А если там телефон на андроиде без рута или какая-нибудь проприетарная железка? Что крутить будем?

Я лично предлагаю провайдеру с PPP сгореть в аду, это самый простой и очевидный вариант.

Мы в 2021 году, а PPP это наследие сраных телефонистов, которые привыкли тарифицировать звонки, и для них PPP был очередным звонком, а по другому они не умели.

Нынче телефонисты уже скорее в виде зомби трупа, и даже они много где осилили уход от PPP на своём провайдинге.

 

И как пользователь я голосую рублём и ухожу с корбины/билайна только из за ихнего дебильного PPP, просто 100м за 500 руб я бы ещё может стерпел, но когда рядом онлайм с 500 руб за 500 мегабит и без PPP - я не мазахист и не настолько ленив.

[[anp/hsw]]

44 минуты назад, Ivan_83 сказал:

Поставьте перед вендой роутер, который подмет ппп и станет понятно кто виноват и что делать.

Делали. И винду меняли на линкус. Проблема именно в прохождении ppp интерфейса, но не понятно, в чем конкретно (и когда она появилась, тоже никто не знает).

 

46 минут назад, Ivan_83 сказал:

И как пользователь я голосую рублём и ухожу с корбины/билайна только из за ихнего дебильного PPP, просто 100м за 500 руб я бы ещё может стерпел, но когда рядом онлайм с 500 руб за 500 мегабит и без PPP - я не мазахист и не настолько ленив.

Это уже попахивает фантомными болями, видимо протокол ppp доставляет вам мощные душевные страдания :)

Есть еще такая штука как биллинг, и если она на pppoe затоечна, будет вдвойне сложнее с него слезть.

Ну а уж про то, что 99% процентов людей знать не знают, pppoe там у них или что еще в роутере - свершившийся факт.

[Ivan_83]

8 часов назад, [anp/hsw] сказал:

Делали. И винду меняли на линкус. Проблема именно в прохождении ppp интерфейса, но не понятно, в чем конкретно (и когда она появилась, тоже никто не знает).

Тогда остаётся либо реализация шейпера либо реализация NAT, отключайте по очереди и смотри как оно будет.

Ещё может какие то оффлоадинги на сетевухах вашего сервера включены и они на что то влияют.

 

8 часов назад, [anp/hsw] сказал:

Это уже попахивает фантомными болями, видимо протокол ppp доставляет вам мощные душевные страдания :)

У меня действительно было много страданий с PPP на протяжении примерно двух лет, до тех пор пока я не начал использовать роутеры на базе BSD.

Но в целом и на BSD мне не нравится что нужно держать отдельную службу и если она не стартанула - то из инета уже не попасть.

Ну и применительно к роутеру в виде "железки" - оно там потребляет ресурсы и в пустую греет воздух.

 

8 часов назад, [anp/hsw] сказал:

Есть еще такая штука как биллинг, и если она на pppoe затоечна, будет вдвойне сложнее с него слезть.

Это ваш конкурентный недостаток.

 

8 часов назад, [anp/hsw] сказал:

Ну а уж про то, что 99% процентов людей знать не знают, pppoe там у них или что еще в роутере - свершившийся факт.

До тех пор, пока не нужно роутер поменять или не приспичит воткнуть провод напрямую в ноут/комп потому что роутер сдох а работать нада прямо щас а не за роутерами бегать или монтажопов ждать три дня.

[sdy_moscow]

59 минут назад, Ivan_83 сказал:

Тогда остаётся либо реализация шейпера либо реализация NAT, отключайте по очереди и смотри как оно будет.

Ещё может какие то оффлоадинги на сетевухах вашего сервера включены и они на что то влияют.

Что-то шепчет мне, что дело в ICMP... точнее в его отсутствии.

[[anp/hsw]]

5 часов назад, Ivan_83 сказал:

Тогда остаётся либо реализация шейпера либо реализация NAT, отключайте по очереди и смотри как оно будет.

В первом посте же написано: отключалось полностью, вплоть до выпиливания conntrack на nat box и давания реальника, шейперы также все удалялись. A на NAS так вообще их нет, они только на NAT BOX, куда трафик приходит через один и тот же канал вне зависимости от типа клиентского подключения.

6 часов назад, Ivan_83 сказал:

Ещё может какие то оффлоадинги на сетевухах вашего сервера включены и они на что то влияют.

Пробовали отключать все, которые нашлись в ethtool - gro, gso, vlan, txcsum на обоих машинах...

6 часов назад, Ivan_83 сказал:

Это ваш конкурентный недостаток.

Что, это уже и в рекламке прописывается? "А вот у нас не pppoe", "mtu 9000 и jumbo frame первое в городе!", "dual stack ipv4/6 только сегодня!"?

Вы как-то по-искаженному представляете конкурентое преимущество.

 

6 часов назад, Ivan_83 сказал:

а работать нада прямо щас а не за роутерами бегать или монтажопов ждать три дня

Пиццу и суши ждут час-два, а монтажника с преднастроеным роутером с какого-то перепуга три дня?

 

5 часов назад, sdy_moscow сказал:

Что-то шепчет мне, что дело в ICMP... точнее в его отсутствии.

Тогда бы не согласовался MSS. А с этим как раз все в порядке.

После гадания на tcpdump имеется подозрение на лишнюю задержку, но пока без доказательств, что она может иметь значение. Ищу способ повысить ее на gre/vlan канале, чтобы проверить.

Еще раз: такая байда начинается при росте RTT, т.е. до определенного момента и расстояния все OK....

 

[Saab95]

23 часа назад, [anp/hsw] сказал:

Как раз на форуме микротика подобные проблемы я и наблюдал, но они остались без ответа.

На микротике можно настраивать буфер пакетов в шейпере.

Если поставить PFIFO с дефолтными 50 или 100 пакетами, то просто идут дропы и наблюдаются проблемы со скоростью одноканальной закачки. Стоит увеличить пакетный буфер до 2000-5000, как при нагрузке растет задержка и окно увеличивается, скорость одноканальной закачки так же увеличивается, но уже задержка начинает сдерживать максимальную пропускную способность. И только тип буфера PCQ решает все проблемы. В этом случае вносится некая задержка на прохождение всего трафика в потоке абонента, но скорость выравнивается по всем протоколам и увеличения задержки не происходит (пинг в норме). Это как у вас в случае с шейпером на 20М.

[[anp/hsw]]

42 минуты назад, Saab95 сказал:

как при нагрузке растет задержка и окно увеличивается, скорость одноканальной закачки так же увеличивается

Вы не читали исходный пост. В данном случае как раз наоборот происходит, а шейпер вообще выключен.

[Ivan_83]

18 часов назад, [anp/hsw] сказал:

В первом посте же написано: отключалось полностью, вплоть до выпиливания conntrack на nat box и давания реальника, шейперы также все удалялись. A на NAS так вообще их нет, они только на NAT BOX, куда трафик приходит через один и тот же канал вне зависимости от типа клиентского подключения.

А точно ничего в фаере не забыли выключить, например mssfix какойнить или ещё чего то, что может лезть и менять содержимое TCP заголовков?

 

18 часов назад, [anp/hsw] сказал:

Что, это уже и в рекламке прописывается? "А вот у нас не pppoe", "mtu 9000 и jumbo frame первое в городе!", "dual stack ipv4/6 только сегодня!"?

Вы как-то по-искаженному представляете конкурентое преимущество.

Всё же "включил и работает" лучше и для абонента и для вас мороки меньше.

IPv6 уже заезжает и это вполне себе аргумент.

И до mtu 9к доберутся, не переживайте, лет через 10 за него возьмутся.

 

13 часов назад, [anp/hsw] сказал:

Вы не читали исходный пост. В данном случае как раз наоборот происходит, а шейпер вообще выключен.

Тем не менее он может быть прав - где то в PPP хрени может не хватать буферов.

Посмотрите на ретрансмиты в TCP соединении, может быть они как то неожиданно много прирастают?

 

То что без PPP оно жмёт 50 мегабит а PPP только 3 конечно загадка :)

Я бы попробовал снять полные tcpdump  в pcap формате, а потом их бы разгребал разбирая отличия в TCP сигнализации, что вы видимо и сделали.

 

У меня есть ещё гипотеза: микробёрсты.

Без PPP у вас передающий хост пакеты может равномерно по времени размазывать, а в случае PPP они могу где то внутри агрегироваться и потом улетать большой пачкой, которая где то может не пролезать по пути, и клиент с той стороны будет запрашивать ретрансмиты. При этом при включённом шейпере у вас шейпер гарантирует что таких бёрстов не будет.

Или всё таки где то у вас TCP может пересобираться и перефрагментироваться.

Те попробуйте сравнить дампы трафика на клиентском PPP интерфейсе и на выходе уже на физическом и посмотрите на таймстемпы.

[sdy_moscow]

1 час назад, Ivan_83 сказал:

IPv6 уже заезжает и это вполне себе аргумент

Вот что я бы в сеть оператора ставить не стал.... дыра на дыре  + куча лишней нагрузки на коммутаторы Л3. Тут как раз туннелирование будет спасением.

[edo]

В 06.03.2021 в 08:04, [anp/hsw] сказал:

 

- Задушить исходящую шейпером до ~20мегабит, тогда окно начинает увеличиваться. От 1 до 20 мегабит скорость растет, дальше начинает резко падать. Совсем без шейпера - также низкая.

 

2 часа назад, Ivan_83 сказал:

У меня есть ещё гипотеза: микробёрсты.

присоединяюсь

[[anp/hsw]]

8 часов назад, Ivan_83 сказал:

А точно ничего в фаере не забыли выключить, например mssfix какойнить или ещё чего то, что может лезть и менять содержимое TCP заголовков?

Точно. К тому же чем mssfix при работе с ppp отличается от mssfix при работе с vlan с точно таким же заниженым mtu? Ничем. ПО tcpdump все одинаково.

8 часов назад, Ivan_83 сказал:

Посмотрите на ретрансмиты в TCP соединении, может быть они как то неожиданно много прирастают?

В случае с медленным ppp ретрансмитов вообще нет. В случае с быстрыми vlan или gre, ретрансмитов куча (удаленный хост все же имеет лимит скорости), но и скорость высокая.

8 часов назад, Ivan_83 сказал:

Без PPP у вас передающий хост пакеты может равномерно по времени размазывать, а в случае PPP они могу где то внутри агрегироваться и потом улетать большой пачкой, которая где то может не пролезать по пути, и клиент с той стороны будет запрашивать ретрансмиты. При этом при включённом шейпере у вас шейпер гарантирует что таких бёрстов не будет.

Тоже на это грешу, но tcopdump показывает обратное: при ppp пакеты уходят в нужной очередности, просто медленно; при vlan/gre быстро, с берстами и реордеригном.

 

Вот дамп начала соединений:

*** gre
00:06:14.483075 IP 163.172.208.7.5209 > 192.168.5.34.36922: Flags [S.], seq 4084908873, ack 2960000570, win 43440, options [mss 1380,sackOK,TS val 3241808859 ecr 175168742,nop,wscale 13], length 0
00:06:14.483987 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], ack 1, win 432, options [nop,nop,TS val 175168765 ecr 3241808859], length 0
00:06:14.483992 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [P.], seq 1:38, ack 1, win 432, options [nop,nop,TS val 175168765 ecr 3241808859], length 37
00:06:14.574531 IP 163.172.208.7.5209 > 192.168.5.34.36922: Flags [.], ack 38, win 6, options [nop,nop,TS val 3241808881 ecr 175168765], length 0
00:06:14.577166 IP 163.172.208.7.5209 > 192.168.5.34.36920: Flags [P.], seq 3:4, ack 102, win 6, options [nop,nop,TS val 3241808882 ecr 175168753], length 1
00:06:14.578032 IP 192.168.5.34.36920 > 163.172.208.7.5209: Flags [.], ack 4, win 432, options [nop,nop,TS val 175168788 ecr 3241808882], length 0
00:06:14.662036 IP 163.172.208.7.5209 > 192.168.5.34.36920: Flags [P.], seq 4:5, ack 102, win 6, options [nop,nop,TS val 3241808903 ecr 175168788], length 1
00:06:14.662848 IP 192.168.5.34.36920 > 163.172.208.7.5209: Flags [.], ack 5, win 432, options [nop,nop,TS val 175168809 ecr 3241808903], length 0
00:06:14.663282 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 38:1406, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.663447 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 1406:2774, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.663455 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 2774:4142, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.663627 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 4142:5510, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.663700 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 5510:6878, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.663903 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 6878:8246, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.663909 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 8246:9614, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368
00:06:14.664095 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 9614:10982, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368

*** pppoe
00:11:26.005393 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [S.], seq 3533636946, ack 1882388010, win 43440, options [mss 1380,sackOK,TS val 3241886739 ecr 175246624,nop,wscale 13], length 0
00:11:26.006324 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], ack 1, win 432, options [nop,nop,TS val 175246645 ecr 3241886739], length 0
00:11:26.006329 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [P.], seq 1:38, ack 1, win 432, options [nop,nop,TS val 175246645 ecr 3241886739], length 37
00:11:26.089993 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 38, win 6, options [nop,nop,TS val 3241886760 ecr 175246645], length 0
00:11:26.090532 IP 163.172.208.7.5209 > 192.168.5.34.45110: Flags [P.], seq 3:4, ack 102, win 6, options [nop,nop,TS val 3241886761 ecr 175246635], length 1
00:11:26.091445 IP 192.168.5.34.45110 > 163.172.208.7.5209: Flags [.], ack 4, win 432, options [nop,nop,TS val 175246667 ecr 3241886761], length 0
00:11:26.170553 IP 163.172.208.7.5209 > 192.168.5.34.45110: Flags [P.], seq 4:5, ack 102, win 6, options [nop,nop,TS val 3241886781 ecr 175246667], length 1
00:11:26.171418 IP 192.168.5.34.45110 > 163.172.208.7.5209: Flags [.], ack 5, win 432, options [nop,nop,TS val 175246687 ecr 3241886781], length 0
00:11:26.171745 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 38:1406, ack 1, win 432, options [nop,nop,TS val 175246687 ecr 3241886760], length 1368
00:11:26.171951 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 1406:2774, ack 1, win 432, options [nop,nop,TS val 175246687 ecr 3241886760], length 1368
00:11:26.255526 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 1406, win 6, options [nop,nop,TS val 3241886802 ecr 175246687], length 0
00:11:26.255538 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 2774, win 6, options [nop,nop,TS val 3241886802 ecr 175246687], length 0
00:11:26.256789 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 2774:4142, ack 1, win 432, options [nop,nop,TS val 175246708 ecr 3241886802], length 1368
00:11:26.257080 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 4142:5510, ack 1, win 432, options [nop,nop,TS val 175246708 ecr 3241886802], length 1368
00:11:26.340544 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 4142, win 7, options [nop,nop,TS val 3241886823 ecr 175246708], length 0
00:11:26.340858 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 5510, win 7, options [nop,nop,TS val 3241886823 ecr 175246708], length 0

 

Обратите внимание, что хоть и sack включен, в ppp на каждые 2 пакета хост ожидает ack, хотя в gre очередь намного длиннее.

Использование accel-ppp несколько меняет картину относительно ванильного pppd: рост окна начинается примерно с 10-15 секунды соединения, но довольно вяло, совсем не как на ethernet.

 

Первые два пакета в pppoe можете не принимать во внимание: это пакеты от служебной сессии iperf, где передается имя хоста и параметры потока.

 

ps: Сообшение перечеркнуто хз, почему, тега такого в исходном посте нет, там spoiler и quote.

[edo]

1 час назад, [anp/hsw] сказал:

Обратите внимание, что хоть и sack включен, в ppp на каждые 2 пакета хост ожидает ack, хотя в gre очередь намного длиннее.

они случаем местами не перепутаны?

 

в каком месте снят трафик?

[[anp/hsw]]

2 часа назад, edo сказал:

они случаем местами не перепутаны?

Точно! Перепутаны. Исправил.

 

Именно этот снят на стыке NAS-NATBOX, но у меня есть дампы на всех интерфейсах одновременно по цепочке этого же самого трафика, если надо.

 

Не понятно, чем задается длина очереди при таком соединениии. Txqueuelen на интерфейсах крутить я пробовал, он не при делах.

[edo]

а ppp поднимается на windows? попробуйте поставить перед ней любой wifi-роутер (или не wifi) и поднять ppp на нём