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

Обновился до ядра 2.6.35.8 перестал работать шейпер pptp

Обновился до ядра 2.6.35.8. Перестал работать шейпер, но не совсем перестал, а очень странно перестал. Поясню.

 

Ставим лимит скорости на вход-выход 4000 кбит/с, коннектимся к серверу, получаем адрес и выходим в инет.

 

Заходим на тест internet.yandex.ru и проверяем скорость. Значения в тесте скорости соотвествуют 100%. Далее пробуем скачать большой файл с гарантированно быстрого тестового хоста во внешней сети в надежде увидеть скорость порядка 500 кбайт/с, но скорость не превышает 20-30 кбайт/с (забираю файл через браузер, отдача веб-сервером).

 

Выключаю шейпер, пересоединяюсь к серваку, снова провожу тест. Скорость на пределе. Скачиваю файл ... прекрасно тянет до 100 Мбит/с, т.е. на полную.

 

Основной код шейпера таков:

 

/usr/sbin/tc qdisc del dev $interface root
/usr/sbin/tc qdisc add dev $interface root tbf rate ${upload}kbit burst $[1500+$upload*10] latency 50

/usr/sbin/tc qdisc del dev $interface ingress handle ffff:
/usr/sbin/tc qdisc add dev $interface ingress handle ffff:
/usr/sbin/tc filter add dev $interface parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate ${download}kbit buffer $[7000+$download*40] drop flowid :1

 

Шейпер поднимается в ip-up, а все остальное обертка и к делу отношения не имеет.

 

Вопрос в том, почему тест internet.yandex.ru выдает нормальные результаты по скорости, которые соотвествуют тарифу, а реальная скорость передачи файла никакая.

 

И что такого надо покрутить в ядре, чтобы вернуть все в рабочее состояние. Подозреваю что это что-то находится в секциях QoS и Netfilter, но вот никак не могу понять что именно.

 

И стоит ли по этой причине обновлять iproute2 и в нем ли могут быть проблемы?

 

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

Edited by replicant

Share this post


Link to post
Share on other sites
Не было печали, апдейтов накачали?
Была печаль и были веские причины в переходе именно на это ядро именно для этого сервера. В данный момент починка старого или прикручивание другого шейпера выглядят мелочью по сравнению с проблемами, которые были.

 

Я не сторонник самых новых ядер, но так было необходимо сделать.

Share this post


Link to post
Share on other sites

Странно как-то: upload шейпится, а download полисится. Лучше бы наоборот. Может burst для полисеров надо увеличить? Иначе они нужную скорость держать не будут.

Edited by photon

Share this post


Link to post
Share on other sites
Странно как-то: upload шейпится, а download полисится. Лучше бы наоборот. Может burst для полисеров надо увеличить? Иначе они нужную скорость держать не будут.

Как раз все нормально, там возможно просто термины upload и download местами переставлены. Грубо говоря это одна и та же переменная, потому что канал симметричный. burst сделан таким образом, что на работающих системах корректно шейпит до 100 Мбит/с включительно с погрешностью около 1% в ту или иную сторону и размер burst оптимален для любых тарифов и скоростей.

 

Меня волнует почему разница в тесте и в реальной работе и даже не почему шейпер отказал, а почему именно так странно стал работать. Оснований не доверять internet.yandex.ru пока не было.

Edited by replicant

Share this post


Link to post
Share on other sites

Полисинг и шейпинг -- разные вещи. Для полисинга burst (или buffer) должен быть больше, чем для шейпинга, иначе в начале будет большой всплеск, но потом скорость резко падает и не достигает нужного значения. Посмотрите еще, что там в 2.6.35.x изменилось по поводу параметра HZ и таймеров. Это тоже влияет на подсистему QoS.

Edited by photon

Share this post


Link to post
Share on other sites

Теория про полисинг и шейпинг мне известна. Факт в том что этот код работает на 2.6.27.х ядрах и вы наверное не обратили внимания на пример с тестом, который на мой взгляд намного показательнее кода, потому что код совершенно правильный. Если бы он был неправильный, то шейпинг не работал бы на более старых ядрах. Может быть в коде и есть ошибки, но только применительно к подсистемам нового ядра, а не в принципе вообще ошибки. По поводу того что буфер должен быть больше тоже ясно. Он и так больше в 4 раза + 5500, если внимательно посмотреть код.

 

Почему internet.yandex.ru четко показывает 4000 кбит/с по тесту, а когда скачиваешь файл допустим с mirror.yandex.ru то скорость не поднимается выше 20 кбайт!

Edited by replicant

Share this post


Link to post
Share on other sites

Сейчас буду с нуля собирать ОС и все ПО для полноценного теста шейпера на 2.6.35.8 ядре. Я не верю что код шейпера содержит ошибки или какие-то вещи, которые несовместимы с новым ядром. Возможно конфиг ядра был не оптимален.

 

В данном случае upload и download - это просто числа, а не суть направление трафика. $interfaces - это ppp.

 

Пока ядро будет с конфигом по-умолчанию и все остальные параметры системы тоже. Дальше буду записывать в журнал все коррективы, пока не протестирую всю линейку безлимитных тарифных планов от 4 до 40 Мбит/с.

Share this post


Link to post
Share on other sites
Полисинг и шейпинг -- разные вещи.
У него и туда и обратно полисер

 

Share this post


Link to post
Share on other sites
Полисинг и шейпинг -- разные вещи.
У него и туда и обратно полисер

На одном интерфейсе и в обе стороны полисер? А дисциплина TBF тогда что тут делает?

tc qdisc add dev $interface root tbf rate ${upload}kbit burst $[1500+$upload*10] latency 50

Share this post


Link to post
Share on other sites

Ну так tbf ведь и есть полисер, там при переполнении буфера пакеты дропает

Share this post


Link to post
Share on other sites

stelsik

Любой шейпер при переполнении буфера будет дропать, на то оно и переполнение, другой вопрос, что у полисера буфера-то нет...

Share this post


Link to post
Share on other sites

tbf = token bucket filter -- это шейпинг. У полисера буфер тоже есть. Отличие от шейпинга состоит в том, что он не вносит между пакетами задержки по определенному алгоритму, т.к. отсутствует очередь для отправки, а только отбрасывает пакеты, превышающие допустимый rate. Более подробно о различиях написано здесь: http://www.cisco.com/en/US/tech/tk543/tk54...0800a3a25.shtml

Edited by photon

Share this post


Link to post
Share on other sites

Решил проверить на заново поставленной ОСи.

 

Короче на ядре 2.6.33.4 и 2.6.33.7 работает и не шуршит. Все в обе стороны как надо ограничивает и никаких дропов пакетов.

 

Надо пинать ведро 2.6.35.8, видимо придется подбирать опции конфига ядра по образцу с 2.6.33.4, которое я конфигурил под это дело вдумчиво и долго. Потому что в тот факт, что этот шейпер не будет работать я нифига не верю. Этот код работает всегда на всех ядрах 2.6.х еще со времен динозавров и даже на 2.4.х работает. Он простой как три копейки, но он работает великолепно для тупого ограничения полосы пропускания в обе стороны на скоростях от 1 до 100 Мбит/с включительно.

Edited by replicant

Share this post


Link to post
Share on other sites
Решил проверить на заново поставленной ОСи.

 

Короче на ядре 2.6.33.4 и 2.6.33.7 работает и не шуршит. Все в обе стороны как надо ограничивает и никаких дропов пакетов.

 

Надо пинать ведро 2.6.35.8, видимо придется подбирать опции конфига ядра по образцу с 2.6.33.4, которое я конфигурил под это дело вдумчиво и долго. Потому что в тот факт, что этот шейпер не будет работать я нифига не верю. Этот код работает всегда на всех ядрах 2.6.х еще со времен динозавров и даже на 2.4.х работает. Он простой как три копейки, но он работает великолепно для тупого ограничения полосы пропускания в обе стороны на скоростях от 1 до 100 Мбит/с включительно.

Во первых строках спасибо за идею использовать производную от скорости в burst (раньше мы руками его правили вслед за повышением скоростей на тарифах).

Во вторых для меня тема использования ядра 35 очень актуальна. Я под это дело новый сервак хочу поставить. Старый боевой уже подходит к своему пределу. Вот xeon'ы во вторник приедут и начну собирать....

 

Отсюда вопросы: Вы говорите, что вэб-измерители скорости показывают должный результат (в обе стороны???), а передача реального файла (кстати, ftp или http одинаково???) идет плохо... А Вы в обе стороны пробовали??? Количество PPP сессий на сервере??? PPP под новое ядро пересобирали???

У Вас PPtP или PPPoE?

Это я к тому, что может новое ядро плохо стыкуется с какими-либо старыми компонентами системы... Например, PPPoE если ядерный, то край под новое ядро компилить... Iproute2 то же не мешало бы новый поставить, например http://mirror.yandex.ru/fedora/linux/relea...-3.fc14.src.rpm

Ведь не даром его обновляют почти под каждое ядро!

В общем, давайте эту проблему вместе пилить, ибо мне то же очень бы не хотелось отказываться от "вкусностей" нового 35 ядра)))))

Share this post


Link to post
Share on other sites

Вобщем так: система Slackware 13.1

У меня pptp accel 0.8.5 и ppp-2.4.5, который был в системе

На сервере кроме моей сессии никакой другой нет, потому как это тест

Iproute 2 последний, тестировал и с тем, что в системе и с тем что собирал из исходников

--------------------

Под новое ядро пересобирал все что только можно и со скоростью все равно беда.

Пока дошел до ядра 2.6.33.7 и на всех ядрах до него включительно все прекрасно работает, т.е. и на 2.6.32.х и на 2.6.31.x

Сегодня проводил тест на 2.6.34.7 и как и ожидалось все заработало как надо.

На боевых серверах стоят ядра 2.6.27.54-55

 

100% что-то накрутили разработчики ядра и теперь вылезает этот косяк, хотя если отключить шейпер, то 500-600 сессий легко прокидываются при нагрузке на CPU около 10%.

 

Intel Quad 9550| 4Gb RAM| Eth Intel E1G42ET Gigabit Adapter Dual Port PCI-E x4 10/100/1000Mbps

 

Тюнинг sysctl, ethtool и прочих компонент системы присутствует, но это роли не играет т.к. опции на других ядрах я не отключал.

 

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

 

У меня есть сомнения относительно переменных, которые передаются в IP-UP в качестве расчета размера burst от скорости. А вдруг в новом ядре они не передаются шейперу вообще?

 

Как проверить какой в реальности поднимается размер burst при открытии сессии ip-up? Это последняя и единственная догадка, потому что со сборкой ядра я не мог так сильно ошибиться, не первый день ядра подпиливаю и кой чего в этом деле понимаю. В сборке ошибок нет и все зависимости удовлетворены и железо учтено и все особенности системы тоже. В ядре ничего лишнего, только под конкретное железо.

 

В итоге задача сводится к тому, чтобы отмониторить работу tc и в частности посмотреть какой размер burst поднимается и поднимается в системе на конкретное pptp соединение.

Вопрос как это сделать? У меня есть ощущение, что с ядром 2.6.35.8 перестает работать вот этот кусок кода и соответственно такой же кусок ниже.

 

burst $[1500+$upload*10]

 

Особенность теста internet.yandex.ru такова, что burst может не так задействоваться как при реальном скачивании и передаче файла. Надо поиграться на тарифе 4000 кбит/с с явным указанием размера burst и сделать его согласно формуле равным 41500.

 

Вторая версия - это слегка измененный синтаксис работы с tc, но это уже попахивает бредом.

 

Вот тут есть похожая тема http://forum.nag.ru/forum/index.php?showtopic=61363 , но там источник проблемы понятен сразу и ежу.

Edited by replicant

Share this post


Link to post
Share on other sites
Есть подозрения что TBF как-то иначе работает. С чего бы в тестах показывать нормальную скорость, а в реальности лимитировать.

 

У меня есть сомнения относительно переменных, которые передаются в IP-UP в качестве расчета размера burst от скорости. А вдруг в новом ядре они не передаются шейперу вообще?

 

Как проверить какой в реальности поднимается размер burst при открытии сессии ip-up? Это последняя и единственная догадка, потому что со сборкой ядра я не мог так сильно ошибиться, не первый день ядра подпиливаю и кой чего в этом деле понимаю. В сборке ошибок нет и все зависимости удовлетворены и железо учтено и все особенности системы тоже. В ядре ничего лишнего, только под конкретное железо.

 

В итоге задача сводится к тому, чтобы отмониторить работу tc и в частности посмотреть какой размер burst поднимается и поднимается в системе на конкретное pptp соединение.

Вопрос как это сделать? У меня есть ощущение, что с ядром 2.6.35.8 перестает работать вот этот кусок кода и соответственно такой же кусок ниже.

 

burst $[1500+$upload*10]

Попробуйте другую очередь.

У меня это ESFQ

.....

в код добавьте

echo $[1500+$upload*10] >> /var/log/messages

 

И Вы не ответили, скорость деградирует в обе стороны???

Всплеск скорости в начале и уменьшение потом присутствует?

Share this post


Link to post
Share on other sites
И Вы не ответили, скорость деградирует в обе стороны???

Всплеск скорости в начале и уменьшение потом присутствует?

Деградирует в обе стороны. Всплеска никакого вообще нет. Просто ровно и не быстро без рывков. Вот данные из файла интерфейса /tmp/ppp158

 

interface = ppp158

remote ip = 10.168.1.113

download = 12000

upload = 12000

burst = 121500

buffer = 487000

 

Веб-страницы и файлы еле открываются, а при этом тест internet.yandex.ru показывает

 

скорость скачивания : 11973 Кбит/с

скорость закачки : 11730 Кбит/с

 

Скачивание с mirror.yandex.ru в тот же момент 18-20 кбайт/с (выше 20.4 не поднимается, как будто что-то лимитирует)

Edited by replicant

Share this post


Link to post
Share on other sites

Вообще, очень странно.....

А скорость закачки файла на ftp, например, какая?

Еще попробуйте, пожалуйста, speedtest.net

 

 

 

И Вы не ответили, скорость деградирует в обе стороны???

Всплеск скорости в начале и уменьшение потом присутствует?

Деградирует в обе стороны. Всплеска никакого вообще нет. Просто ровно и не быстро без рывков. Вот данные из файла интерфейса /tmp/ppp158

 

interface = ppp158

remote ip = 10.168.1.113

download = 12000

upload = 12000

burst = 121500

buffer = 487000

 

Веб-страницы и файлы еле открываются, а при этом тест internet.yandex.ru показывает

 

скорость скачивания : 11973 Кбит/с

скорость закачки : 11730 Кбит/с

 

Скачивание с mirror.yandex.ru в тот же момент 18-20 кбайт/с (выше 20.4 не поднимается, как будто что-то лимитирует)

Share this post


Link to post
Share on other sites
Вообще, очень странно.....

А скорость закачки файла на ftp, например, какая?

Еще попробуйте, пожалуйста, speedtest.net

FTP то же самое. В обе стороны не более даже 10-12 кбайт/с. Speedtest даже начать тест не может ... интерфейс загрузился и на этом все. Никаких ошибок ни в логах, ни в файлах, куда вывожу параметры работы туннелей.

Сдается мне что надо что-то делать с ядром, но вот понять бы что именно. QoS и в модулях был и в ядро собирал ... все едино.

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

 

При тесте internet.yandex.ru незначительно увеличивается время отклика в момент прохождения теста, но так и должно быть, когда скорость в туннеле приближается к 100% значению для данного соединения

 

Обмен пакетами с ya.ru [77.88.21.3] с 32 байтами данных:

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=6мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=5мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=4мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=7мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=5мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=4мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=6мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=5мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=10мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=21мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=4мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

Ответ от 77.88.21.3: число байт=32 время=3мс TTL=59

 

Результаты:

скорость скачивания : 11428 Кбит/с

скорость закачки : 11510 Кбит/с

Edited by replicant

Share this post


Link to post
Share on other sites
Попробуйте другую очередь.

У меня это ESFQ

Можно чуть больше деталей по этому вопросу?

Share this post


Link to post
Share on other sites
Попробуйте другую очередь.

У меня это ESFQ

Можно чуть больше деталей по этому вопросу?

У меня корневая очередь htb, а далее по esfq. Можно попробовать SFQ.

##### speed server->client

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

/sbin/tc class add dev $1 parent 1:0 classid 1:10 htb rate 95mbit burst 512k

/sbin/tc class add dev $1 parent 1:0 classid 1:20 htb rate ${UPSPEED}kbit burst 30k

/sbin/tc qdisc add dev $1 parent 1:10 handle 10: esfq limit 128 depth 128 divisor 12 hash dst

/sbin/tc qdisc add dev $1 parent 1:20 handle 20: esfq limit 128 depth 128 divisor 12 hash dst

/sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip src "локальные IP" flowid 1:10

 

##### speed client->server

/sbin/tc qdisc add dev $1 handle ffff: ingress

/sbin/tc filter add dev $1 parent ffff: protocol ip prio 49 u32 match ip dst "локальные IP" police rate 95mbit burst 1000k drop flowid :1

/sbin/tc filter add dev $1 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${DOWNSPEED}kbit burst 30k drop flowid :1

 

 

Share this post


Link to post
Share on other sites

Тоже не работает как надо. На ядре 2.6.33.4 ваша версия нормально работает, а на 2.6.35.8 нет. В итоге откатываюсь на старое ядро, а эксперименты буду продолжать, потому что там работает четко.

 

Значения для тарифа 4000 кбит/с прыгают в диапазоне от 3 до 15 мбит/с, что просто неприемлимо.

 

А вы тестировали на 2.6.35.8?

 

С моим шейпером вот так 1022319538.png

 

И по internet.yandex.ru так

 

скорость скачивания : 3964 Кбит/с

скорость закачки : 3873 Кбит/с

Edited by replicant

Share this post


Link to post
Share on other sites

У меня траблы с 35-тым ядром впереди... Сервер пришел, а вот ксионы только 10-го будут)))))

Посмотрим, какие результаты будут у меня.

Не долго ждать осталось!

 

 

Тоже не работает как надо. На ядре 2.6.33.4 ваша версия нормально работает, а на 2.6.35.8 нет. В итоге откатываюсь на старое ядро, а эксперименты буду продолжать, потому что там работает четко.

 

Значения для тарифа 4000 кбит/с прыгают в диапазоне от 3 до 15 мбит/с, что просто неприемлимо.

 

А вы тестировали на 2.6.35.8?

 

С моим шейпером вот так 1022319538.png

 

И по internet.yandex.ru так

 

скорость скачивания : 3964 Кбит/с

скорость закачки : 3873 Кбит/с

Share this post


Link to post
Share on other sites

Может тогда bugreport накатать в bugzilla.kernel.org по поводу нового ядра? Я уже когда-то делал, ответили довольно быстро.

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