Обновился до ядра 2.6.35.8

replicant · November 3, 2010

Обновился до ядра 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 November 4, 2010 by replicant

s.lobanov · November 3, 2010

Не было печали, апдейтов накачали?

replicant · November 3, 2010

Не было печали, апдейтов накачали?

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

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

photon · November 3, 2010

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

Edited November 3, 2010 by photon

replicant · November 4, 2010

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

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

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

Edited November 4, 2010 by replicant

photon · November 4, 2010

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

Edited November 4, 2010 by photon

replicant · November 4, 2010

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

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

Edited November 4, 2010 by replicant

replicant · November 4, 2010

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

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

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

stelsik · November 4, 2010

Полисинг и шейпинг -- разные вещи.

У него и туда и обратно полисер

photon · November 5, 2010

Полисинг и шейпинг -- разные вещи.
У него и туда и обратно полисер

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

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

stelsik · November 5, 2010

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

vitalyb · November 5, 2010

stelsik

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

photon · November 5, 2010

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

Edited November 5, 2010 by photon

replicant · November 5, 2010

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

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

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

Edited November 5, 2010 by replicant

telecom · November 7, 2010

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

Короче на ядре 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 ядра)))))

replicant · November 8, 2010

Вобщем так: система 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 November 8, 2010 by replicant

telecom · November 8, 2010

Есть подозрения что 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

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

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

replicant · November 8, 2010

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

Деградирует в обе стороны. Всплеска никакого вообще нет. Просто ровно и не быстро без рывков. Вот данные из файла интерфейса /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 November 8, 2010 by replicant

telecom · November 8, 2010

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

А скорость закачки файла на 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 не поднимается, как будто что-то лимитирует)

replicant · November 8, 2010

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

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

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

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

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

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

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