wans Опубликовано 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 Хотя по графику вижу что не прокачивают они свою полосу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 23 июня, 2006 · Жалоба А если пайпы убрать, они смогут выкачать хотя-бы 449 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wans Опубликовано 25 июня, 2006 · Жалоба А если пайпы убрать, они смогут выкачать хотя-бы 449 ? А почему ВЫ считаете что не смогут? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 июня, 2006 · Жалоба А почему ВЫ считаете что не смогут? Вот просто интересно, c какой целью поставлено queue 3 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wans Опубликовано 25 июня, 2006 · Жалоба Вот просто интересно, c какой целью поставлено queue 3 ? Если честно пока не совсем разобрался как работает этот параметр если указывать большое число то возрастают задержки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 июня, 2006 · Жалоба Если честно пока не совсем разобрался как работает этот параметресли указывать большое число то возрастают задержки. Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wans Опубликовано 25 июня, 2006 · Жалоба Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление. да может быть наступит, но пока не наступает может подскажете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 29 июля, 2006 · Жалоба Рекомендую перечитывать соответствующий абзац в man'е со словарем до тех пор пока не наступит просветление. воистину! аминь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v-m-k Опубликовано 31 июля, 2006 · Жалоба queue = количество пакетов в очереди. Меньше, меньше надёжность, больше, больше надёжность но и больше задержки, всё просто... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wans Опубликовано 1 августа, 2006 · Жалоба queue = количество пакетов в очереди. Меньше, меньше надёжность, больше, больше надёжность но и больше задержки, всё просто...В общем-то я так и понял из описания, такое значение поставил потому что клиент жаловался на большие задержки, как правильно рассчитать это значение, и может есть более правильный шейпер?:( вопрос был в другом, почему Pipe работают не правильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 1 августа, 2006 · Жалоба англицкий [1], [2] Вы не осилили, надеюсь русский [1], [2] осилите ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wans Опубликовано 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 миллисекунд. Уже достаточно ощутимая задержка. Расчеты сделаны из тех ссылок что Вы мне привели. И где я именно не прав! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 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 значение, в реальной жизни его практически не случается хотя бы из за того что у Вас роутер... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 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. А теперь прикинь размер очередей заново... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 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 байт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 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... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kuzmich Опубликовано 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. Кажется, мы просто говорим о разных вещах, и ниака не можем понять, кто же и что именно имееет ввиду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...