wans Posted June 21, 2006 Posted June 21, 2006 Привет всем. Не могу понять почему толком не работают 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 Хотя по графику вижу что не прокачивают они свою полосу. Вставить ник Quote
Kuzmich Posted June 23, 2006 Posted June 23, 2006 А если пайпы убрать, они смогут выкачать хотя-бы 449 ? Вставить ник Quote
wans Posted June 25, 2006 Author Posted June 25, 2006 А если пайпы убрать, они смогут выкачать хотя-бы 449 ? А почему ВЫ считаете что не смогут? Вставить ник Quote
jab Posted June 25, 2006 Posted June 25, 2006 А почему ВЫ считаете что не смогут? Вот просто интересно, c какой целью поставлено queue 3 ? Вставить ник Quote
wans Posted June 25, 2006 Author Posted June 25, 2006 Вот просто интересно, c какой целью поставлено queue 3 ? Если честно пока не совсем разобрался как работает этот параметр если указывать большое число то возрастают задержки. Вставить ник Quote
jab Posted June 25, 2006 Posted June 25, 2006 Если честно пока не совсем разобрался как работает этот параметресли указывать большое число то возрастают задержки. Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление. Вставить ник Quote
wans Posted June 25, 2006 Author Posted June 25, 2006 Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление. да может быть наступит, но пока не наступает может подскажете? Вставить ник Quote
snark Posted July 29, 2006 Posted July 29, 2006 Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление. воистину! аминь. Вставить ник Quote
v-m-k Posted July 31, 2006 Posted July 31, 2006 queue = количество пакетов в очереди. Меньше, меньше надёжность, больше, больше надёжность но и больше задержки, всё просто... Вставить ник Quote
wans Posted August 1, 2006 Author Posted August 1, 2006 queue = количество пакетов в очереди. Меньше, меньше надёжность, больше, больше надёжность но и больше задержки, всё просто...В общем-то я так и понял из описания, такое значение поставил потому что клиент жаловался на большие задержки, как правильно рассчитать это значение, и может есть более правильный шейпер?:( вопрос был в другом, почему Pipe работают не правильно. Вставить ник Quote
snark Posted August 1, 2006 Posted August 1, 2006 англицкий [1], [2] Вы не осилили, надеюсь русский [1], [2] осилите ;) Вставить ник Quote
wans Posted August 1, 2006 Author Posted August 1, 2006 англицкий [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 миллисекунд. Уже достаточно ощутимая задержка. Расчеты сделаны из тех ссылок что Вы мне привели. И где я именно не прав! Вставить ник Quote
snark Posted August 1, 2006 Posted August 1, 2006 попробуйте так: 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 значение, в реальной жизни его практически не случается хотя бы из за того что у Вас роутер... Вставить ник Quote
Kuzmich Posted August 1, 2006 Posted August 1, 2006 Молодец, делить и умножать умеешь (наверное, не проверял). Как ты думаешь, в каком случае задерзки будут больше - если пакет постоит лишние 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. А теперь прикинь размер очередей заново... Вставить ник Quote
Kuzmich Posted August 1, 2006 Posted August 1, 2006 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 байт. Вставить ник Quote
snark Posted August 1, 2006 Posted August 1, 2006 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... Вставить ник Quote
Kuzmich Posted August 4, 2006 Posted August 4, 2006 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. Кажется, мы просто говорим о разных вещах, и ниака не можем понять, кто же и что именно имееет ввиду. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.