Jump to content

Recommended Posts

Posted

Доброго времени суток уважаемые знатоки.

 

Столкнулся со следующей проблемой:

Тестирую шейпер с 2 компьютеров (на одном Ubuntu-desktop на втором Windows Xp)

Для каждого выделен свой дочерний подкласс и фильтр настроен на каждый Ip отдельно.

Для проверки работы шейпера захожу на ftp.altlinux.org и начинаю качать первый попавшийся дистрибутив.

С компа, где стоит Ubuntu:

Скорость скачки с фтп в районе 120 КБ/сек (т.е. гейпер работает отлично).

С компа, где стоит Win XP:

И вижу следующее, что скорость скачки 30-40 КБ/сек, т.е. что должно равнятся порядка 256 Кбит/сек, а шейпер настроен на 1 Мб/сек.

Ребята в чем грабли?

Проверял с разных машин, с разными Ip, но Win Xp качать с отведенной ему скоростью качать не хочет.

НО заметил один подвох, что если поставить на Win XP еще 1 поток закачки, то он подключается и опять на такой скорости 30-40 КБ/сек.

Т.е. в итоге можно качать в 4 потока в 30-40 КБ/сек, что будет равно как раз 1 Мбит/сек, но почему же он не хочет брать 1 поток во всю ширь полосы?

        tc='/sbin/tc class add dev'

        for if in $ifs; do
                echo "Making Root qdisk"
                /sbin/tc qdisc add dev $if root handle 1: htb default 20
                echo "Making Root class"
                $tc $if parent 1: classid 1:1 htb rate 1000000Kbit ceil 1000000Kbit prio 1
                         echo "Makin Inet "
                        $tc $if parent 1:1 classid 1:20 htb rate 2Mbit ceil 3 Mbit prio 1
                                 echo "Making Rules for shape"
                                $tc $if parent 1:20 classid 1:23 htb rate 1Mbit
                                $tc $if parent 1:20 classid 1:24 htb rate 1Mbit
            /sbin/tc filter add dev $if protocol ip parent 1:0 prio 1 handle $inet_traf_mark fw classid 1:20
            /sbin/tc filter add dev $if protocol ip parent 1:20 prio 2 u32 match ip dst 172.19.101.12/32 flowid 1:24
            /sbin/tc filter add dev $if protocol ip parent 1:20 prio 2 u32 match ip dst 172.19.101.2/32 flowid 1:23

 

Posted

типо как бы по идее, виндовый tcp делает вид, что устает биться с неприступной крепостью в виде полисера, постоянно подстраивая размер окна под текущую ситуацию, махает рукой и зависает... Т.е. смысл в том, что tcp реагирует на уровень потерь на канале, а полисер эти самые потери создает. Винда по-началу размер окна регулирует, а потом забивает. По крайней мере я так представляю себе (но сам с таким не встречался). Меня может виста спасает.

Posted (edited)

Бритни убей себя, такое прочитать может только студент 2го курса маниакально увлеченый теоритическими предпосылками возникновения IP протокола, и гипотетической реализации в различных ОС.

 

На самом деле как шейпить под Linux, 1000 статей написано, 1000 разных методик и т.п. но реально, ни ж. ничего не помогает. То под XP кривит, то какой нить роутер не хочет работать.

Edited by shicoy
Posted

Либо я что-то недопонял, либо мы друг друга недопонимаем.

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

Для этих подклассов

$tc $if parent 1:20 classid 1:23 htb rate 1Mbit
$tc $if parent 1:20 classid 1:24 htb rate 1Mbit

1:20 является родителем, в свою очередь, для 1:20 родителем является 1:1, и все они идут в одну очередь.

Если я не прав поправьте или приведите конфиг, на основе примера указанного в первом посте, для понимания, что вы имеете ввиду.

Posted (edited)

Если бы я хотел дальше рыться в доках я бы рылся и не спрашивал бы у вас совета. Однако же я пришел сюда спросить так как устал читать доки, в которых я доконца не могу понять. Вот я и пришел к вам.

Edited by fedusia
Posted

Если вы не хотите рыться в доках - я ничем вам не могу помочь. Тем более в том примере все очевидно.

Одно дело помочь изучить что-то новое, другое думать чужими мозгами.

 

Posted
<...>

То под XP кривит, то какой нить роутер не хочет работать.

Видел следующую ситуацию: шейпер на линуксе, клиент с вистой. Скорость с локального хттп - 50-70 процентов, от того что должно быть. Бились некоторое время, попробовали из-под линукса вгетом - то что надо, погрешность в пределах нескольких процентов. Вот так...
Posted

Господа, не мелите ерунды, какие tcp стеки, каие 50-60%? Вам написали, что нет исходящих очередей классов ( qdisc ). Все пакеты валяться в одну корневую очередь, отсюда дропы пакетов и не полная скорость. Повесьте на лиф классы очереди и будет вам счастье.

 

А вообще читайте доки, потому как Вы прочли их не внимательно.

Posted (edited)

tc qdisc add dev $dev parent 1:23 handle 10: sfq perturb 10
tc qdisc add dev $dev parent 1:24 handle 10: sfq perturb 10

А то классы есть, а очередей нет. оно и глючит...

ЗЫ. Доку читать до конца. Пример для htb последний.

 

ЗЫЫ.Кстати, навеска фильтров на подклассы корректна? Т.е. я в свое время где-то читал, что пакет нельзя переклассифицировать.

Edited by Nic
Posted

Nic, огромное спасибо проблема решилась. Вы ткнули носом, где косяк, стал рыть документацию, которую советовали выше. Все понял и исправил. Не хватало очередей для клиентов. Огромное спасибо.

Posted
ЗЫЫ.Кстати, навеска фильтров на подклассы корректна? Т.е. я в свое время где-то читал, что пакет нельзя переклассифицировать.
насколько я знаю, фильтры нельзя навешивать на классы которые не являются конечными (т.е. у них есть дочерние).

класс с фильтром становится leaf in tree, т.е. "листиком на дереве" в дословном переводе. К сожалению точно нигде это не вычитал, но идеологически выходит так.

Posted (edited)

2nuclearcat: Навешивать фильтры на не leaf классы можно, но траффик при этом не классифицируется этим классом, хотя фильтры настроены верно, кроме того нельзя будет повесить на такой класс qdisc. Причем повесить уже не даст сама утилита tc.

 

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

 

Была другая проблема: нужно было вешать очередь на промежуточный класс, т.к. он являлся агрегативным и заранее меньшим по размеру, чем все leaf классы, по параметру ceil. Соответственно, отдавая пакеты в рутовую очередь, мог переполняться. Повесить такую очередь было нельзя. Вернее можно, но при этом класс становился leaf и на него повесть дочерние классы было нельзя. Они-то добавлялись, но работали не корректно.

 

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

Edited by Dark_Angel

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.