[nuclearcat]

Чипсет: ServerWorks Grand Champions LE Chipset с поддержкой шины до 533 МГц (Front Side Bus) и технологии Hyper-Threading

Системная шина: PCI, PCI-X

 

Т.е. можно поискать PCI-X карты.

 

Кроме того подозрительно много жрет ripd. Если тазик используется как роутер, то...

iptables неплохо было бы вообще отключить, т.к. если отключен Interleaving на памяти - ее пропускная способность на этом чипсете не очень - 1.3 Gb/sec.

 

Но как говорит народ - надо попробовать нормальную PCI-X сетевуху.

 

Можно еще конечно сделать типа такого (заодно покажи, сколько у тебя сетевуха позволяет поставить ring):

sunfire-1 ~ # ethtool -g eth1

Ring parameters for eth0:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 256

RX Mini: 0

RX Jumbo: 0

TX: 256

 

ethtool -G eth1 rx 4096

ethtool -G eth1 tx 4096

Изменено 22 ноября, 2007 пользователем nuclearcat

[nuclearcat]

Еще можно поиграть с

ip link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100

ip link set eth0 txqueuelen 10000

 

т.е. интерполируй на себя

 

Еще с этим параметром

sysctl -w net.core.netdev_budget=300 (это дефолт)

и

net.core.netdev_max_backlog = 1000

[Ivan Rostovikov]

Большое спасибо за советы. На днях приедет PCI-X сетевуха. Все попробую. Результаты отпишу.

 

Вот еще интересно:

 

http://www.linux.org.ru/view-message.jsp?m...;page=1#1681842

 

В треде упоминаются страшные числа PPS 400000, и даже полтора миллиона. Я в шоке. У меня максимум было 93000 и роутер имел бледный вид.

 

А вот цитата, которая заставила меня сильно задуматься:

 

"Как сказано в документации, при 400000 пакетов, ядро Linux + NAPI генерит всего 7 прерываний в секунду, что _никак_ не сказывается на производительности".

 

У меня самое последнее ядро. драйвер e1000+NAPI Но по моим наблюдениям и данным из /proc/interrupts как ни крути выходит несколько десятков тысяч прерываний в сек.

 

Выходит NAPI у меня не работает ?

Как же это проверить ?

Или чето я непонимаю ?

[nuclearcat]

Кстати а сколько у вас HZ ?

Может закинете куданить свой .config ?

[Ivan Rostovikov]

1000 вроде.

http://www.rapidshare.ru/474879

Изменено 22 ноября, 2007 пользователем Ivan Rostovikov

[nuclearcat]

Странно - много писал и куда-то пропало

Из ключевого - отключить IPSEC, Multicast, ATM, IPV6, TIPC, DCCP, ircomm, wireless, Firewire, если не нужны отключитб

verbose route monitoring - отключить

Профайлинг - в модуль

CONFIG_NO_HZ=y - можно попробовать отключить

CONFIG_CPU_FREQ - отключить

CONFIG_IP_VS - если не нужен отключить

CONFIG_NETPOLL - желательно отключить, вместе с netconsole - если не используете

CONFIG_SECURITY - если не используется - отключить. Некоторые фишки увеличивают сетевые структуры.

[Kirya]

CONFIG_NO_HZ=y - можно попробовать отключить

Ну люди dynticks сидели старались делали, а ты говоришь отключить...

[nuclearcat]

Kirya - во первых "ложный" softlockup в текущем stable еще не полечили благодаря ему, правда автору он не светит, с его нагрузкой. Кроме того много багов вылезло именно из-за dynticks.

 

Во вторых dynticks не для performance, а для energy saving (за исключением KVM). Не думаю что автора трида интересует экономия электричества.

[Ivan Rostovikov]

Во всей этой истории мне более всего непонятно почему именно ksoftirqd создает такую нагрузку на CPU ?

 

Пока никто внятно не смог обьяснить чем обусловленна такая его активность. Да и вообще что именно он делает ?

"Этот демон отвечает за softirq" - самый частый ответ.

И снова вопрос: Как проверить работает NAPI или нет ?

Если работает. Можно ли оценить эффективность его работы ?

Изменено 22 ноября, 2007 пользователем Ivan Rostovikov

[Kirya]

Kirya - во первых "ложный" softlockup в текущем stable еще не полечили благодаря ему, правда автору он не светит, с его нагрузкой. Кроме того много багов вылезло именно из-за dynticks.

 

Во вторых dynticks не для performance, а для energy saving (за исключением KVM). Не думаю что автора трида интересует экономия электричества.

Мы говорим про x86 или x64 ? Это первое.

Второе. Dynticks имеет хороший побочный эффект. Ибо начинает регулировать latency при разных загрузках.

 

Во всей этой истории мне более всего непонятно почему именно ksoftirqd создает такую нагрузку на CPU ?

 

Пока никто внятно не смог обьяснить чем обусловленна такая его активность. Да и вообще что именно он делает ?

"Этот демон отвечает за softirq" - самый частый ответ.

И снова вопрос: Как проверить работает NAPI или нет ?

Если работает. Можно ли оценить эффективность его работы ?

Иван, ну нет тут разработчиков e1000.

Это вопрос уровня LKML.

[DemYaN]

"Этот демон отвечает за softirq" - самый частый ответ.

http://www.geocities.com/asimshankar/notes...rking-napi.html

[nuclearcat]

Во всей этой истории мне более всего непонятно почему именно ksoftirqd создает такую нагрузку на CPU ?

 

Пока никто внятно не смог обьяснить чем обусловленна такая его активность. Да и вообще что именно он делает ?

"Этот демон отвечает за softirq" - самый частый ответ.

И снова вопрос: Как проверить работает NAPI или нет ?

Если работает. Можно ли оценить эффективность его работы ?

Можно. Сопоставьте прерывания (их количество) с pps на карте. Если они не равны - значит NAPI работает.

[Ivan Rostovikov]

В случае с PPPoE Мне кажется это не корректно. Т.к. один и тот же адаптер принимает и передает пакет. NAPI работает на прием. Но на передачу все равно возникает прерывание.

 

В частности сейсач наблюдаю ~~23000 i/s при таком же p/s :(

 

2DemYaN Спасибо. Немного полегчало. Фигово, что английский мне не родной. ;-)

Изменено 23 ноября, 2007 пользователем Ivan Rostovikov

[gritzko]

Вот орлы 2.5Gbit/s намолотили. Рассказывают, как.

Изменено 23 ноября, 2007 пользователем gritzko

[bitbucket]

Во всей этой истории мне более всего непонятно почему именно ksoftirqd создает такую нагрузку на CPU ?

 

Пока никто внятно не смог обьяснить чем обусловленна такая его активность. Да и вообще что именно он делает ?

"Этот демон отвечает за softirq" - самый частый ответ.

В принципе ответ верный, точнее под этим процессом работает часть прерывания, где уже можно разрежить другие прерывания. Дело в том, что в x86 архитектуре во время любого прерывания контроллер прерываний блокирует остальные irq до завершения обработчика текущего прерывания, т.е. до "двадцатки в двадцатый порт". Для того, что бы не было переклинивания системы на момент исполнения прерываний, которые могут долго длиться, например при работе с не DMA карточками, решили разделить прерывание на 2 части: маленький обработчик (top half), который лишь быстро что-то времякритичное ковыряет в железе, если оно надо, а дальше просто ставит в очередь на исполнение ksoftirqd, в котором уже с "открытыми масками" прерывание и обрабатывается (в разных версиях ядра, т.е. 2.0, 2.4., 2.6, реализовывались разные варианты подобной обработки прерываний: back-half, work queue, tasklet, softirq, но идея все та-же).

Так что если softirqd очень активно себя ведет, то видимо поллинг не используется, так как прерывания есе же есть, и их много. Или же карточка почему-то все равно генерирует прерывания, которые по идее должны быть запрещены или происходить в разы реже.

В принципе, идея поллинга в том, что выключить генерацию прерываний вообще (или слизить ее до минимума), так как прерывание в x86 системе дело длительное, особенно в защищенном режиме. А карточку опрашивать переодически по случаю, так как данные то все равно принимаются и отправляются в/из tx/rx "колец".

Я не особо знаком с внутренностями драйвера e1000, но вот это (парамеметры модуля) стоит покрутить в большую сторону:

Transmit Interrupt Delay, Transmit Absolute Interrupt Delay, Receive Interrupt Delay, Receive Absolute Interrupt Delay - это задержка перед выдачей прерывания, дающая накопить данные в буфферах, но возможно увеличение задержки при приеме пакета.

а это в меньшую Interrupt Throttling Rate (interrupts/sec) - что бы пореже сыпало.

Хотя, с napi, прерываний вообще быть не должно.

 

И снова вопрос: Как проверить работает NAPI или нет ?

napi для e1000 включается дефайном CONFIG_E1000_NAPI . Если есть в версии драйвера "-NAPI", значит оно скомпилено.

 

Если работает. Можно ли оценить эффективность его работы ?

По идее, другим приложениям в системе должно стать легче, хотя, в принципе загрузка радикально не упадет: количество обрабатываемых пакетов будет не уменьшится, выйгрыш лишь во времени, которое процессор тратил на запуск выполнения прерывания (заполнения там всяких IDT, переключение задач и т.д.).

В разных других драйверах я вообще выкидывал прерывания "пакет отправлен", которые по идее должны высвобождать уже отправленные блоки, а само освобождение памяти делал в специальной задаче, которая переодически всплывала сама, или "пиналась" на выполнение, если места в "кольцах" на передачу уже практически закончилось. Это выкидывает 50% прерываний карточки, но лишает возможности узнать, в какое точное время отправлен пакет.

[bitbucket]

Вот орлы 2.5Gbit/s намолотили. Рассказывают, как.

Спасибо, очень интересный pdf.

[Ivan Rostovikov]

Все.

У меня руки опускаются.

Поставил Intel Pro 1000 MT PCI-X

 

Пробовал играться параметрами :

InterruptThrottleRate

[TR]xDescriptors

[TR]xIntDelay

[TR]xAbsIntDelay

 

Разницы почти никакой. Видимо проблема в другом месте.

Рано или поздно наступает ситуация когда ksoftirqd просто "бесится" и сьедает весь процессор. Иногда это при 20000 pps иногда при 40000

Вот пример: По данным ethstatus - ~~43000 pps

 

top - 12:47:36 up 13:35, 1 user, load average: 1.50, 1.44, 1.88

Tasks: 473 total, 2 running, 471 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.7%us, 0.7%sy, 0.0%ni, 25.0%id, 0.0%wa, 0.3%hi, 73.4%si, 0.0%st

Mem: 516616k total, 417500k used, 99116k free, 109648k buffers

Swap: 1365504k total, 0k used, 1365504k free, 62672k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

6 root 15 -5 0 0 0 R 100 0.0 45:07.48 ksoftirqd/1

24775 root 20 0 2492 1368 852 R 2 0.3 0:00.59 top

2671 root 20 0 5756 1880 1580 S 1 0.4 0:38.23 utm5_rfw

10169 root 20 0 7852 2372 1912 S 0 0.5 0:00.74 sshd

11490 quagga 20 0 3024 1272 540 S 0 0.2 0:09.64 zebra

 

Уже непойму где искать. :-(

 

 

2 bitbucket

Большое спасибо за разьяснения.

Можно ли связаться с Вами ?

ir(собака)trytek.ru

[bitbucket]

Все.

У меня руки опускаются.

Поставил Intel Pro 1000 MT PCI-X

 

Пробовал играться параметрами :

InterruptThrottleRate

[TR]xDescriptors

[TR]xIntDelay

[TR]xAbsIntDelay

 

Разницы почти никакой. Видимо проблема в другом месте.

Рано или поздно наступает ситуация когда ksoftirqd просто "бесится" и сьедает весь процессор. Иногда это при 20000 pps иногда при 40000

Странно. Если поставить Interrupt Throttle Rate ч 100 оно так же сыпит много прерываний ? Если так, то или не работает эта крутилка, или надо смотреть что за прерывание (интересует тип прерывания) сыпет.

 

Количество прерываний в секунду от карточки (/proc/interrupts) такое же, как и pps в оба конца (т.е. pps*2) ? Если меньше в разы - значит уже железо не справляется. Если такое-же значит поллинг работает не эффективно (мне лично реализация поллинга в линуксе не нравится).

 

Дело в том, что поллинг (и роутинг) так же работает под ksoftirqd, т.е. этот процесс не только обработка самих прерываний, но и проталкивание пакета через весь ip стек. Так как в линуксе нет отдельной задачи, которая бы сетевой трафик разруливала: от приема пакета с карточки в back half-е до вываливания этого пакета куда-то еще все работает под процессом ksoftirqd. Если на машине развесистый фаервол, медленный процессор или память - будет тормозить. Кстати, как и многоядерность (SMP) - она иногда может и тормозов давать, из-за лочек как внутри ядра, так и внутри железа. Если используется один порцессор - ядро должно быть собрано без SMP.

 

Что делать с e1000 я не знаю. Скорее всего надо переписывать драйвер в плане того, что выключить генерацию прерываний tx/rx вообще - это разгрузит процессор. Прием делать по таймеру, поставив HZ побольше, например 1000, так как при наличии какого-либо существенного трафика оно будет так всегда занято, а чистить передачу как я уже предлагал: или из отдельной задачи, или при приближении к полностью занятым буфферам кольца передачи. Ну еще можно сделать, как предлагали в pdf-ке (выше по треду), tx buffers recycling - т.е. для приема использовать те же skb, которые освободились при передаче (если такие есть), а не брать новые.

 

Еще может помочь увеличение netdev_budget, но оно все равно по времени более 1 jiffie работать не будет, там надо ядро править.

[Ivan Rostovikov]

Отключить hyper-phreading и собрать ядро без SMP ?

[bitbucket]

Отключить hyper-phreading и собрать ядро без SMP ?

а зачем его вообще включали ? для роутинга оно никаких плюсов не дает, одни минусы.

[random7]

Отключить hyper-phreading и собрать ядро без SMP ?

а зачем его вообще включали ? для роутинга оно никаких плюсов не дает, одни минусы.

пролетало как-то давно в lkml, что HT дало на тестах около 10% прирост в pps

наверное, там больше 1 сетевого интерфейса было

 

кроме того, smp очень помогает, если на той же тачке идёт подсчёт трафика, или зебра с фуллвью, или юзер-левел pptp какой-нибудь

[bitbucket]

пролетало как-то давно в lkml, что HT дало на тестах около 10% прирост в pps

наверное, там больше 1 сетевого интерфейса было

Как оно прирост может давать, если исполняется все на одном ядре ? Ну не простаивает execution unit на нагруженной машине, а если стоит, то скорее всего и вторая задача будет стоять, ожидая догрузки данных в кеш.

 

кроме того, smp очень помогает, если на той же тачке идёт подсчёт трафика, или зебра с фуллвью, или юзер-левел pptp какой-нибудь

Если 2 карточки - smp может и поможет, если одна - то ядра порцессоров будут за эту карточку биться. А зебра с фуллвью не сильно процессор кушает, по сравнению с роутингом. Да и считалки трафика, работающие в ядре, не всегда исползуют многопоточность - чаще это по затратам как несколько дополнительных правил в фаерволе, не более.

 

Тут вообще то проблему Ivan Rostovikov правильно описал: поллинг на передаче не работает.

[random7]

Как оно прирост может давать, если исполняется все на одном ядре ? Ну не простаивает execution unit на нагруженной машине, а если стоит, то скорее всего и вторая задача будет стоять, ожидая догрузки данных в кеш.

этих юнитов на p4 типа немного больше, чем может заюзать один тред одновременно

вот и получается небольшой прирост

 

Если 2 карточки - smp может и поможет, если одна - то ядра порцессоров будут за эту карточку биться. А зебра с фуллвью не сильно процессор кушает, по сравнению с роутингом. Да и считалки трафика, работающие в ядре, не всегда исползуют многопоточность - чаще это по затратам как несколько дополнительных правил в фаерволе, не более.

биться ядра за карточку не будут, если ничего не путаю - обработка идёт на том ядре, куда прерывание пришло

по опыту - если ядро одно и загружено роутингом по полной - зебре достаётся слишком мало проца

то есть защиту от livelock NAPI делает не очень хорошо

я как-то жаловался в lkml на эту тему, понимания не получил, а сам разобраться не осилил

но у меня другая ситуация была, не как у автора: ksoftirqd почти не работал

 

а какие считалки трафика у нас в ядре

счётчики iptables? новомодный accounting в conntrack?

думаю, не много пользователей здесь этих технологий, ulog и pcap популярнее

 

 

Тут вообще то проблему Ivan Rostovikov правильно описал: поллинг на передаче не работает.

Сомневаюсь, что проблема в этом. 23000int/s - это очень мало, чтоб создать проблему, если если проц куплен не больше 5 лет назад.

 

А oprofile уже предлагал кто-нибудь?

[bitbucket]

этих юнитов на p4 типа немного больше, чем может заюзать один тред одновременно

вот и получается небольшой прирост

А теперь посчитаем время на лочках, там , где без smp их нет. Ну и кеш не резиновый, хотя и большой.

 

биться ядра за карточку не будут, если ничего не путаю - обработка идёт на том ядре, куда прерывание пришло

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

 

а какие считалки трафика у нас в ядре

Самописные.

[Kirya]

Все.

У меня руки опускаются.

Поставил Intel Pro 1000 MT PCI-X

Если у тебя сейчас две PCI-X сетевые карты, и все-равно результата нет, в LKML ты не писал, и что делать, не знаешь, может просто поставить вторую и разбить по ним юзверей, разведя прерывания по процам ?

Конечно это не Unix way, но тогда станет понятно действительно у тебя сетевки затыкаются или pppox.

 

а какие считалки трафика у нас в ядре

Самописные.

Вау.

А по-подробнее ?

В чем интересные фичи, что решили сами написать ?

Изменено 26 ноября, 2007 пользователем Kirya