[replicant]

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

Я думаю нужна более тщательная проверка. Пока тестировал вышеупомянутые шейперы на двух машинах на slackware 13.1 и 12.2 с разными конфигурациями железа и различными конфигурациями сборки ядра 2.6.35.8. Использовался accel-pptp версий 0.8.3-5 и ppp-2.4.4-5.

 

Посмотрим как будет работать у telecom'a, вдруг у него заработает. Я решил временно забить на проблему сосредоточившись на допиливании ядра 2.6.27.55 и 2.6.33.7. Жаль конечно, потому что в 2.6.35.8 были нужные мне вещи и в принципе машина на нем работает стабильно проглатывая большие объемы трафика и обмолачивая много туннелей не сильно при этом напрягаясь.

 

Очень хотелось сделать сборку pptp сервера на обновленном ядре, чтобы в дальнейшем ввести его в эксплуатацию на всех машинах и плавно переехать на эту ветку ядер. Про 2.6.27.х плохого ничего сказать не могу, достаточно долго на них работаю, но все началось с сервера, который стабильно падал на 2.6.27.55 и уже несколько дней к ряду стоит под реальной нагрузкой на 2.6.35.8, что дает основания думать о некоторой нестыковке конфигурации ядра и железа, которая устанилась только при смене ядра, потому что с конфигами я наплясался достаточно много и протестировал около десятка вариантов сборки.

Изменено 8 ноября, 2010 пользователем replicant

[telecom]

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

Напишите, пожалуйста! А то у меня с английским не очень.....

 

А я как вариант солью исходники 33 и 35 ядра, и сделаю diff -r -N linux-2.6.35/net/sched inux-2.6.35/net/sched > chto_slomalos.log

 

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

Я думаю нужна более тщательная проверка. Пока тестировал вышеупомянутые шейперы на двух машинах на slackware 13.1 и 12.2 с разными конфигурациями железа и различными конфигурациями сборки ядра 2.6.35.8. Использовался accel-pptp версий 0.8.3-5 и ppp-2.4.4-5.

 

Посмотрим как будет работать у telecom'a, вдруг у него заработает.

Да я уже сам запереживал!!!

Купить новый сервак, собрать новый дистр (на основе 13 федоры и 35 ядра), и все ради увеличения производительности...

У меня одних своих патчей вагон...... Уже вторую неделю компилю.....

[NiTr0]

С 2.6.35.7 - никаких проблем, 2.6.35.8 на тестовом тазике крутится вроде тоже все ОК...

Я бы iproute2 попробовал бы обновить...

[Ivantey]

Тоже на днях собрали два тазика на 2.6.35 и accel 0.8.5. Проблем не замечено.

[replicant]

С 2.6.35.7 - никаких проблем, 2.6.35.8 на тестовом тазике крутится вроде тоже все ОК...

Я бы iproute2 попробовал бы обновить...

Последний из исходников уже стоит. Может быть в Slackware только такие глюки? У вас какие ОС?

[DrakoN]

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

У меня это 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

htb всяко лучше, чем tbf, с этим я согласен.

Но странно, что у вас burst/cburst ручками ставится, а не от скорости считается. cburst тоже нужен, на 10-20мегабитных скоростях, по умолчанию он какой-то мелкий.

Ещё я порекомендовал бы взглянуть на mtu на интерфейсах, если speedtest не грузится.

[Ivantey]

slackware 13.1

[replicant]

slackware 13.1

Значит копать буду более глобально, потому что моя 13.1 уверенно работает только с 2.6.33.7. Уже перепробовал кучу вариантов. Даже секции Netfilter и QoS сконфигурированы аналогичным образом как на 2.6.33.7 за исключением некоторых новых параметров, которые к делу отношения не имеют.

 

Видимо придется собирать еще один лабораторный стенд и начинать с нуля. Чисто теоретически мог дистрибутив на диске таким образом побиться, чтобы появился такой глюк, ну или там ошибки чтения влияют? Т.е. при сборке и компиляции не вылезает, а в реальной работе дает о себе знать. Потому что уже не знаю куда начинать думать.

Изменено 11 ноября, 2010 пользователем replicant

[telecom]

slackware 13.1

Значит копать буду более глобально, потому что моя 13.1 уверенно работает только с 2.6.33.7. Уже перепробовал кучу вариантов. Даже секции Netfilter и QoS сконфигурированы аналогичным образом как на 2.6.33.7 за исключением некоторых новых параметров, которые к делу отношения не имеют.

 

Видимо придется собирать еще один лабораторный стенд и начинать с нуля. Чисто теоретически мог дистрибутив на диске таким образом побиться, чтобы появился такой глюк, ну или там ошибки чтения влияют? Т.е. при сборке и компиляции не вылезает, а в реальной работе дает о себе знать. Потому что уже не знаю куда начинать думать.

Чисто по человечески очень сочувствую! Сам не раз попадал в такие "тупики", когда все перепробовал по несколько раз и ничего не получается... У меня эксперемент откладывается, ибо ксеоны застряли на таможне...

Может возьмете мое ядро на пробу? если будет архив с vmlinuz, system.map и папочкой /lib/modules сможете поставить и сделать initrd (initramfs)? правдо оно у меня 64-битное...

 

[NiTr0]

У вас какие ОС?

Роутерный дистр, заметно перепиленный, зовется Bering-uClibc v4 pre-beta1 (в статусе подготовки к бета-релизу, усиленно дорабатываемая до статуса бета уже в основном комьюнити т.к. 99% того, что я бы хотел в ней видеть, в осносном я и реализовал, сейчас - решаются мелочи - как быть с опциями для модулей, подгружаемых автоматически, и оформляется документация).

[replicant]

Выкинул дисковод в топку и взял другой.

 

Записал новый диск с дистром slackware 13.1 и заново поставил на тестовый комп. Перезакачал ядро 2.6.35.8 с mirror.yandex.ru.

 

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

 

Все заработало c первого захода и даже ошибок в инсталляции ПО не возникло, а раньше они были.

 

Или дистрибутив побился на диске или дисковод допускал ошибки при чтении, которые потом вылезали в виде нелепого бага.

[replicant]

А вот теперь совсем не понятно. Стоят два совершенно одинаковых сервера. Абсолютно идентичные. Сетевки e1000e встроенные в сервачные материнки.

 

Все работает и шейпер работает и не шуршит. Ставлю сетевую Intel E1G42ET Gigabit Adapter Dual Port PCI-E x4 и шейпер перестает работать корректно.

 

Драйвера пробовал 2.1.9, 2.2.9, 2.3.4, 2.4.8. Опции запуска карты /sbin/modprobe igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=2,2,2,2

 

Соотвественно один порт на локалку, а другой в инет. Опции запуска пробовал разные и даже по 1 очереди и задействовал только два ядра, но никак не заводится. Аналогичная конфигурация ядра и e1000e + tg3 и все летает.

 

Убираю сетевую igb и вновь запускаю e1000e. Все начинает работать.

 

Грешить на сетевые и на серверное железо никак, потому что работало на других ядрах и работает на этом, но правда без шейпера. Жесть какая-то. Это уже достало. Не работают ни HTB ни TBF ни SFQ. Полная засада. На ядрах 2.6.27.х работает в любых комбинациях с любыми шейперами.

 

Что делать-то? У кого есть такие же сетевые чтобы проверить?

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

 

Симптомы таковы что потерь icmp нет пакетами даже больших размеров. Не бегут tcp пакеты, причем маленькие пакеты судя по всему бегают нормально. Настройки sysctl сброшены на умолчальные т.е. вообще сброшены на время.

Изменено 16 ноября, 2010 пользователем replicant

[replicant]

Экспериментальным путем, проведя множество тестов с ядром 2.6.35.8 была найдена причина отказа шейпера и его непредсказуемого поведения.

 

Наличие сетевой карты с драйвером IGB, смотрящей в интернет (внешний интерфейс). Модель сетевой я указывал выше.

 

Как это устранить не меняя сетевую карту пока не знаю.

 

Возможно влияет опция DCA, которая появилась в новых ядрах в разделе Device Driver (Network). Раньше эта опция была в конфиге, но в другом месте.

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

 

Прибивание или не прибивание сетевой к ядрам никакого влияния на работу шейпера не оказывает. Сетевые с драйвверами e1000, e1000e, tg3 уверенно работают и шейпер не отказывает.

 

Вопрос остается открытым. Что такого появилось в ядре, что заставило некорректно работать Intel с драйвером igb.

 

Завтра буду проверять версию драйвера igb, которая включена в ядро и отключение опции dca, но есть ощущение, что дело не в ней, а где-то глубже.

Изменено 16 ноября, 2010 пользователем replicant