replicant Опубликовано 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 из конфига ядра, то могу выложить, но там особенно ничего криминального нет. Изменено 4 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 3 ноября, 2010 · Жалоба Не было печали, апдейтов накачали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 3 ноября, 2010 · Жалоба Не было печали, апдейтов накачали?Была печаль и были веские причины в переходе именно на это ядро именно для этого сервера. В данный момент починка старого или прикручивание другого шейпера выглядят мелочью по сравнению с проблемами, которые были. Я не сторонник самых новых ядер, но так было необходимо сделать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 3 ноября, 2010 (изменено) · Жалоба Странно как-то: upload шейпится, а download полисится. Лучше бы наоборот. Может burst для полисеров надо увеличить? Иначе они нужную скорость держать не будут. Изменено 3 ноября, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 4 ноября, 2010 (изменено) · Жалоба Странно как-то: upload шейпится, а download полисится. Лучше бы наоборот. Может burst для полисеров надо увеличить? Иначе они нужную скорость держать не будут. Как раз все нормально, там возможно просто термины upload и download местами переставлены. Грубо говоря это одна и та же переменная, потому что канал симметричный. burst сделан таким образом, что на работающих системах корректно шейпит до 100 Мбит/с включительно с погрешностью около 1% в ту или иную сторону и размер burst оптимален для любых тарифов и скоростей. Меня волнует почему разница в тесте и в реальной работе и даже не почему шейпер отказал, а почему именно так странно стал работать. Оснований не доверять internet.yandex.ru пока не было. Изменено 4 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 4 ноября, 2010 (изменено) · Жалоба Полисинг и шейпинг -- разные вещи. Для полисинга burst (или buffer) должен быть больше, чем для шейпинга, иначе в начале будет большой всплеск, но потом скорость резко падает и не достигает нужного значения. Посмотрите еще, что там в 2.6.35.x изменилось по поводу параметра HZ и таймеров. Это тоже влияет на подсистему QoS. Изменено 4 ноября, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 4 ноября, 2010 (изменено) · Жалоба Теория про полисинг и шейпинг мне известна. Факт в том что этот код работает на 2.6.27.х ядрах и вы наверное не обратили внимания на пример с тестом, который на мой взгляд намного показательнее кода, потому что код совершенно правильный. Если бы он был неправильный, то шейпинг не работал бы на более старых ядрах. Может быть в коде и есть ошибки, но только применительно к подсистемам нового ядра, а не в принципе вообще ошибки. По поводу того что буфер должен быть больше тоже ясно. Он и так больше в 4 раза + 5500, если внимательно посмотреть код. Почему internet.yandex.ru четко показывает 4000 кбит/с по тесту, а когда скачиваешь файл допустим с mirror.yandex.ru то скорость не поднимается выше 20 кбайт! Изменено 4 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 4 ноября, 2010 · Жалоба Сейчас буду с нуля собирать ОС и все ПО для полноценного теста шейпера на 2.6.35.8 ядре. Я не верю что код шейпера содержит ошибки или какие-то вещи, которые несовместимы с новым ядром. Возможно конфиг ядра был не оптимален. В данном случае upload и download - это просто числа, а не суть направление трафика. $interfaces - это ppp. Пока ядро будет с конфигом по-умолчанию и все остальные параметры системы тоже. Дальше буду записывать в журнал все коррективы, пока не протестирую всю линейку безлимитных тарифных планов от 4 до 40 Мбит/с. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stelsik Опубликовано 4 ноября, 2010 · Жалоба Полисинг и шейпинг -- разные вещи.У него и туда и обратно полисер Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 5 ноября, 2010 · Жалоба Полисинг и шейпинг -- разные вещи.У него и туда и обратно полисер На одном интерфейсе и в обе стороны полисер? А дисциплина TBF тогда что тут делает? tc qdisc add dev $interface root tbf rate ${upload}kbit burst $[1500+$upload*10] latency 50 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stelsik Опубликовано 5 ноября, 2010 · Жалоба Ну так tbf ведь и есть полисер, там при переполнении буфера пакеты дропает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 5 ноября, 2010 · Жалоба stelsik Любой шейпер при переполнении буфера будет дропать, на то оно и переполнение, другой вопрос, что у полисера буфера-то нет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 5 ноября, 2010 (изменено) · Жалоба tbf = token bucket filter -- это шейпинг. У полисера буфер тоже есть. Отличие от шейпинга состоит в том, что он не вносит между пакетами задержки по определенному алгоритму, т.к. отсутствует очередь для отправки, а только отбрасывает пакеты, превышающие допустимый rate. Более подробно о различиях написано здесь: http://www.cisco.com/en/US/tech/tk543/tk54...0800a3a25.shtml Изменено 5 ноября, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 5 ноября, 2010 (изменено) · Жалоба Решил проверить на заново поставленной ОСи. Короче на ядре 2.6.33.4 и 2.6.33.7 работает и не шуршит. Все в обе стороны как надо ограничивает и никаких дропов пакетов. Надо пинать ведро 2.6.35.8, видимо придется подбирать опции конфига ядра по образцу с 2.6.33.4, которое я конфигурил под это дело вдумчиво и долго. Потому что в тот факт, что этот шейпер не будет работать я нифига не верю. Этот код работает всегда на всех ядрах 2.6.х еще со времен динозавров и даже на 2.4.х работает. Он простой как три копейки, но он работает великолепно для тупого ограничения полосы пропускания в обе стороны на скоростях от 1 до 100 Мбит/с включительно. Изменено 5 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 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 ядра))))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 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 , но там источник проблемы понятен сразу и ежу. Изменено 8 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 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 И Вы не ответили, скорость деградирует в обе стороны??? Всплеск скорости в начале и уменьшение потом присутствует? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 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 не поднимается, как будто что-то лимитирует) Изменено 8 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 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 не поднимается, как будто что-то лимитирует) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 ноября, 2010 (изменено) · Жалоба Вообще, очень странно.....А скорость закачки файла на 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 Кбит/с Изменено 8 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 ноября, 2010 · Жалоба Попробуйте другую очередь.У меня это ESFQ Можно чуть больше деталей по этому вопросу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 8 ноября, 2010 · Жалоба Попробуйте другую очередь.У меня это 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 ноября, 2010 (изменено) · Жалоба Тоже не работает как надо. На ядре 2.6.33.4 ваша версия нормально работает, а на 2.6.35.8 нет. В итоге откатываюсь на старое ядро, а эксперименты буду продолжать, потому что там работает четко. Значения для тарифа 4000 кбит/с прыгают в диапазоне от 3 до 15 мбит/с, что просто неприемлимо. А вы тестировали на 2.6.35.8? С моим шейпером вот так И по internet.yandex.ru так скорость скачивания : 3964 Кбит/с скорость закачки : 3873 Кбит/с Изменено 8 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 8 ноября, 2010 · Жалоба У меня траблы с 35-тым ядром впереди... Сервер пришел, а вот ксионы только 10-го будут))))) Посмотрим, какие результаты будут у меня. Не долго ждать осталось! Тоже не работает как надо. На ядре 2.6.33.4 ваша версия нормально работает, а на 2.6.35.8 нет. В итоге откатываюсь на старое ядро, а эксперименты буду продолжать, потому что там работает четко. Значения для тарифа 4000 кбит/с прыгают в диапазоне от 3 до 15 мбит/с, что просто неприемлимо. А вы тестировали на 2.6.35.8? С моим шейпером вот так И по internet.yandex.ru так скорость скачивания : 3964 Кбит/с скорость закачки : 3873 Кбит/с Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 8 ноября, 2010 · Жалоба Может тогда bugreport накатать в bugzilla.kernel.org по поводу нового ядра? Я уже когда-то делал, ответили довольно быстро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
