Jump to content
Калькуляторы

проблема с шейпером Linux htb

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

 

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

Тестирую шейпер с 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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

этот ответ не канает=) Можно что-нибудь поконкретнее.

Share this post


Link to post
Share on other sites

часть ответа содержится тут http://www.soslan.ru/tcp/home.html в главах с 17 по 24

на ночь лучше не читать - травмирует психику и мозг

Share this post


Link to post
Share on other sites

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

 

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

Edited by shicoy

Share this post


Link to post
Share on other sites

Где qdisc для этих классов?

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

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

Share this post


Link to post
Share on other sites

nuclearcat, а это что ?

 

for if in $ifs; do

echo "Making Root qdisk"

/sbin/tc qdisc add dev $if root handle 1: htb default 20

Share this post


Link to post
Share on other sites

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

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

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

$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, и все они идут в одну очередь.

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

Share this post


Link to post
Share on other sites

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

Edited by fedusia

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
<...>

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

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

Share this post


Link to post
Share on other sites

Т.е. я так понимаю пользаков надо пересаживать на линукс? =))

Share this post


Link to post
Share on other sites

посмотрите на форумах торрентов - есть фиксы под винду, меняющие стандартное поведение ее tcp стека... может помочь ;)

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Да вам дали ссылку еще и пункт указали. Откуда столько нежелания разобраться?

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Nic - неверно, оно даже скорее всего не добавиться с одинаковым handle

 

Правильно так:

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

 

Share this post


Link to post
Share on other sites

ой, был невнимателен, забыл поменять цифири :(

Share this post


Link to post
Share on other sites

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this