Перейти к содержимому
Калькуляторы

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

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

Столкнулся с удивительной проблемой: у исходящего 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-среза, но проблему это не решило.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

linux 3.2.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

 

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

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

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

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

 

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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....

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 интерфейсе и на выходе уже на физическом и посмотрите на таймстемпы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.