[wans]

Привет всем.

 

Не могу понять почему толком не работают pipe

есть клиент которому надо дать 448/128Кбит

 

сделал пайпы

 

ipfw pipe 1 config bw 448Kbit/s queue 3

ipfw pipe 2 config bw 128Kbit/s queue 3

 

прописал правила

 

01001 pipe 1 ip from any to 81.24.137.48/28 via vlan1002

01002 pipe 2 ip from 81.24.137.48/28 to any via vlan1002

 

Но они не могут прокачать свои 448

 

вот что показывает ipfw pipe list

 

00001: 448.000 Kbit/s 0 ms 3 sl. 1 queues (1 buckets) droptail

mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000

BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp

0 tcp 87.247.20.65/80 81.24.137.50/3944 10770996 5440637675 2 3000

705552

 

00002: 128.000 Kbit/s 0 ms 3 sl. 1 queues (1 buckets) droptail

mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000

BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp

0 tcp 81.24.137.50/1128 205.188.9.88/5190 11094955 1232925217 0 0

539773

 

Хотя по графику вижу что не прокачивают они свою полосу.

[Kuzmich]

А если пайпы убрать, они смогут выкачать хотя-бы 449 ?

[wans]

А если пайпы убрать, они смогут выкачать хотя-бы 449 ?

А почему ВЫ считаете что не смогут?

[jab]

А почему ВЫ считаете что не смогут?

Вот просто интересно, c какой целью поставлено queue 3 ?

[wans]

Вот просто интересно, c какой целью поставлено queue 3 ?

Если честно пока не совсем разобрался как работает этот параметр

если указывать большое число то возрастают задержки.

[jab]

Если честно пока не совсем разобрался как работает этот параметр

если указывать большое число то возрастают задержки.

Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит

просветление.

[wans]

Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит

просветление.

да может быть наступит, но пока не наступает

может подскажете?

[snark]

Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление.

воистину! аминь.

[v-m-k]

queue = количество пакетов в очереди. Меньше, меньше надёжность, больше, больше надёжность но и больше задержки, всё просто...

[wans]

queue = количество пакетов в очереди. Меньше, меньше надёжность, больше, больше надёжность но и больше задержки, всё просто...

В общем-то я так и понял из описания, такое значение поставил потому что клиент жаловался на большие задержки, как правильно рассчитать это значение, и может есть более правильный шейпер?

:( вопрос был в другом, почему Pipe работают не правильно.

[snark]

англицкий [1], [2] Вы не осилили, надеюсь русский [1], [2] осилите ;)

[wans]

англицкий [1], [2] Вы не осилили, надеюсь русский [1], [2] осилите ;)

Спасибо за ссылки, но как не странно нового они мне не чего не дали.

Давайте разберемся по шагам.

 

Правила привязываться к интерфейсу что исключает двойного попадания пакета в трубу.

01001 pipe 1 ip from any to 81.24.137.48/28 via vlan1002

01002 pipe 2 ip from 81.24.137.48/28 to any via vlan100

 

далее

 

ipfw pipe 1 config bw 448Kbit/s queue 3

ipfw pipe 2 config bw 128Kbit/s queue 3

 

в первом pipe указанна очередь в 3 слота. считаем задержки

1500(MTU)*3(слоты)*8(биты)/1024(Кбит)=35КБит (размер очереди)

35Кбит/448Кбит=0,078секунд или 78 миллисекунд. Уже достаточно ощутимая задержка.

 

Расчеты сделаны из тех ссылок что Вы мне привели.

 

И где я именно не прав!

[snark]

попробуйте так:

ipfw pipe 1 config bw 448Kbit/s
ipfw pipe 2 config bw 128Kbit/s

01001 pipe 1 ip from any to 81.24.137.48/28 via vlan1002 
01002 pipe 2 ip from 81.24.137.48/28 to any via vlan100

т.е. с точностью до наоборот и без указания размера queue, т.к. MTU 1500 в Ваших расчетах - это на мой взгляд что-то из разряда фантастики, т.е. это max значение, в реальной жизни его практически не случается хотя бы из за того что у Вас роутер...

[Kuzmich]

Молодец, делить и умножать умеешь (наверное, не проверял).

 

Как ты думаешь, в каком случае задерзки будут больше - если пакет постоит лишние 0,5 секунды в очереди, или если пакет будет перепосылаться сервером заново? Причем не в момент сброса пакета в dummynet, а только тогда, когда сервер догадается, что его пакет где-то пропал без вести?

 

Грамотные реализации tcp после нескольких таких потерь начинают уменьшать размер окна tcp, и в твоем случае размер этого окна будет уменьшен до 2х-3х пакетов. Это означает, что на каждые 2-3 посланных пакета сервер будет ожидать от клиента подтверждения получения пакета... какой пинг до того сервера? Пусть будет 0.1 сек.

 

Послав 2-3 пакета (которые идут 0.1 секунду до юзера) сервер будет ждать подтверждения доставки (еще 0.1 секунда). Т.е. пакеты сервером будут отправляться в лучшем случае 5 раз в секунду порциями по 2-3 пакета. Итого 5*3*1.5к = 22.5 килобайта в секунду, или 180 килобит полезного трафика. И это только после того, как и сервер и клиент поймут, что окно нужно уменьшить до 3-4.5 килобайт.

 

Ае если клиент пытается установить одновременно 2 коннекта, то :

а) размер окон будет постоянно переконфигурироваться

б) будут опять происходить потери пакетов внутри окна, что вызовет долгий рестарт tcp.

 

А теперь прикинь размер очередей заново...

[Kuzmich]

MTU 1500 в Ваших расчетах - это на мой взгляд что-то из разряда фантастики, т.е. это max значение, в реальной жизни его практически не случается хотя бы из за того что у Вас роутер...

Да ну?

 

gw# ipfw show 1
00001 3242  131347 count tcp from not me to not me tcpdatalen 0-1450
00001 3192 4788000 count tcp from not me to not me tcpdatalen 1451-1500

 

Это результат скачивания файлика с ftp.

Если учесть, что часть пакетов - это подтверждения доставки с близким к нулевому размером, и вычесть из 1500 длины заголовков IP и TCP, то получается, что весь download идет на пакетах длиной 1500.

 

 

До ftp-сервера от меня - 5 хопов

...
3  r3-ge-0-0-0-2-Mow-M9.RU.DataBone.net (217.28.244.12)  22.307 ms  22.628 ms  22.808 ms
4  M9-IX-1.free.net (193.232.244.36)  23.964 ms  25.651 ms  24.025 ms
5  ftp.chg.ru (193.233.9.194)  26.925 ms  27.547 ms  27.978 ms

 

Так что не такая уж и редкость пакеты в 1500 байт.

[snark]

Kuzmich с hub.ru??? если "да" то я в сторонке тихо простою... из увжения...

Так что не такая уж и редкость пакеты в 1500 байт

не знаю... не знаю... я такими пакетами линки меряю... точнее 1500+оверхед... пакеты бОльше просто не юзал ;) опять же чту не только Вас но и RFC которое гласит

The minimum length of the data field of a packet sent over an Ethernet is 1500 octets, thus the maximum length of an IP datagram sent over an Ethernet is 1500 octets.

собсно отсюда и вывод что оно редкость (до тотальной поддерржки Jumbo frames на ethernet думаю еще далеко)... но если Вы так говорите... лично Вам я всегда верю на слово ;) хотя Ваше

До ftp-сервера от меня - 5 хопов

говорит мне что там возможно не совсем ethernet... ведь согласно правилам TTL с каждым роутером уменьшается на 1...

[Kuzmich]

Kuzmich с hub.ru??? если "да" то я в сторонке тихо простою... из увжения...

Да. Только выйди из сторонки - я тоже умею ошибаться.

 

обсно отсюда и вывод что оно редкость

 

Отсюда как раз вывод, что 1500 байт - самый распространенный размер для IP-датаграммы. Ни один нормальный программист стека tcp-ip, если у него есть 10 кб данных на отправку, не будет посылать их датаграммами по 1499 байт и меньше (если, конечно, MTU-discovery не доложил о меньшем значении MTU на промежуточных узлах).

 

Другое дело, что объем полезных данных в этой датаграмме (1500-заголовок IP-заголовок TCP) меньше 1500, но dummynet считает именно полные датаграммы.

 

хотя бы из за того что у Вас роутер.

А это-то здесь при чем? "фотография" ipfw была снята как раз с роутера (Ethernet-Ethernet).

 

говорит мне что там возможно не совсем ethernet

Вполне возможно. У меня сейчас Ethernet-моу роутер-Ethernet-VDLS-провайдер. Что там за провайдером - мне не сильно интересно. А какая разница, что там вдалеке? ATM, SDH... главное, 1500 байт в датаграмме проходят :)

 

ведь согласно правилам TTL с каждым роутером уменьшается на 1...

Какое имеет отношение TTL к MTU и Эзернету?

 

 

P.S. Кажется, мы просто говорим о разных вещах, и ниака не можем понять, кто же и что именно имееет ввиду.