Изпечатай

[byzon]

Ами предната машина беше на x86 и мисля че пак беше интелска карта с #lsmod | grep e100
e1000                 121784  0
2.6.17-2-amd64

Цитат

Бтв имаш ли в dmesg съобщения от сорта на "eth2: too much work at interrupt..." ?!?

Мне нямам , никакви грешки нямам ..
Не знам , то се намен ми се случват странни работи , направо голям карък съм '>

[byzon]

Май проблема ми е че нямам хардуерен рутер някакъв лейър3 суич ако си взема мисля че ще ми реши проблема , понеже машината се води гейт и само рутирва и нищо друго не прави , аз на това и се чудя какво пък толкова се товари в крайна сметка ... авеража по принцип е 0,1 0,3 не повече , но почне ли с дропед пакетите се качва до към 1 1,5 .. ето в момента е най натоварено и няма никакви проблеми а преди 3 ,4 часа трябваше да ребоотна ..

[gat3way]

Силно много вярвам че линукс е една достатъчно добра платформа за такива цели, да не говорим че хардуерът ти е доста силен. Не казвам че цицковските решения нямат много предимства дори от архитектурна гледна точка, но според мен не си заслужава. Да не говорим че ако в крайна сметка проблемът се окаже все пак в суича или пък от тривиална причина от сорта на "две устройства ползват един и същ IRQ" или пък оттам че драйверът за контролера в тази версия на ядрото бил бъглив...купуването на някакъв catalyst с гбитови портове или някакво друго подобно дзверище ще се окаже един грозен разход.

Никога няма да тръгна да адвокатствам на цицко, за мене лично те са доста по-противни от Майкрософт, от друга страна няма да отрека че имат доволни предимства (нямат ядро дето да се занимава с 5000 юзърспейски глупости, зад всеки порт стои един приятен чип дето прави и суичинг и фрагментация и дори филтъринг на фреймове/пакети, и влан сметки, имат бърза шина до процесора - съмнително колко по-бърза от pcix всъшност), но....това са разходи, които в този случай не е много ясно доколко са оправдани.

Да не говорим че тази гадост трябва да се конфигурира, нещо доста досадно за човек дето не им е свикнал на странностите.

[byzon]

Да ма логика в цялата халва '> но в случея направо не знам какво да правя и този факт ме дразни '>

[byzon]

А има ли начин по който да изчистя тези статисттики

Цитат

RX packets:340013797 errors:1 dropped:52253 overruns:0 frame:1

Или да flush по някакъв начин , понеже колкото и да събарям интерфейсите си остава така , флашвам иптаблес ипроуте ип а махам всичко и като го дигна на ново все си стоят ..

[gat3way]

Ахъм, rmmod module;modprobe module

Ако не са на модули, а в ядрото...друг вариант освен reboot няма.

[byzon]

Съвсем случайно попаднах на един пич с друго супермикро
ето линк я погледни , дали в случея може да помогне ?

[gat3way]

Цитат

net.core.rmem_default = 524287 net.core.rmem_max = 1048575 net.core.wmem_default = 524287 net.core.wmem_max = 1048575

Не мисля че това ще помогне, тъй като става въпрос за сокети. Това е рутер, не някакъв сървър и надали се ползват много сокети на него, т.е никой не се връзва на някакъв сървис на него, той единствено форуард-ва пакети.

Цитат

If not already done, it may help to enable the FlowControl: # insmod e1000 FlowControl=3

В документацията на ядрото открих един текстов файл свързан с този драйвер. По-забавните неща там са:

Цитат

InterruptThrottleRate Default Value: 8000     This value represents the maximum number of interrupts per second the     controller generates. InterruptThrottleRate is another setting used in     interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust     InterruptThrottleRate based on the current traffic load. RxDescriptors Default Value: 256     This value is the number of receive descriptors allocated by the driver.     Increasing this value allows the driver to buffer more incoming packets.     Each descriptor is 16 bytes. NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled   or disabled based on the configuration of the kernel.

За FlowControl не мога да кажа нищо. Драйверът подържа NAPI, което е нещо хубаво. Значи има 2 подхода: единият е класическият в който всеки получен фрейм генерира прекъсване, което на свой ред се обработва от ядрото. Ако имаш висок трафик е напълно нормално load avg да ти скача, защото голяма част от процесорното време се хаби за обработване на прекъсвания, вдигани от мрежовите контролери. NAPI е друг подход, в който вдиганите прекъсвания до голяма степен се игнорират, като по някакъв малко странен алгоритъм в определено време се вдига една функция която изчита от receive ring-а на картата това което е получено и буферирано. Това има много добър ефект върху утилизацията на процесора и като цяло, въпреки че доколкото съм чел има вариант това да доведе до rx_missed пакети.

Според документацията, ако си сложил NAPI подръжка в ядрото, то драйверът ще работи по този начин. Ако можеш да провериш, виж. Предполагам това наистина ще помогне. Но ако не си го активирал трябва да прекомпилираш наново ядрото и модула, което може да не е приемлив вариант все пак.

Другият вариант е да пробваш да си поиграеш да tune-ваш параметрите свързани със прекъсванията генерирани от картата (очевидно хардуера позволява такива игрички). Според тия пичове има вариант хардуера динамично да си size-ва лимита на бройката прекъсвания генерирани от картата на секунда, според трафика, така че да не хвърли процесора в брутални мъки да обработва голяма бройка прекъсвания, които не успява навреме. Ако сложиш InterruptThrottleRate=1, включваш този хмм "динамичен режим". А можеш също да си поиграеш със тази стойност, примерно с 2 пъти по-ниска от настоящата ти. Това ще разреши до голяма степен проблемът с изтормозения процесор.

Остава проблема с дропените фреймове, който всъщност в случаят е свързан до голяма степен с горният. Да речем че лимитираш бройката на прекъсванията/секунда така че процесорът вече почне да смогва да ги обработва. Големият входящ трафик обаче ще се наложи да се буферира някъде или ще се губи. За целта чрез ethtool вдигни големината на rx ring size-a, вдигни и големината на RxDescriptors на драйвера.

Апропо, ако имаш няколко физически процесора или ядра (не hyperthreading), можеш да направиш и още нещо, за което преди време се обсъждаше из тия форуми. Ядрото позволява "bind"-ване на прекъсване към определен процесор, така че вдигнатите прекъсвания с определен номер да се изпълняват само на определен процесор (в добрият случай се балансират по всички процесори, в един по-лош и често срещан случай всичко се насипва на първия процесор, който се сдухва лошо). Това става лесно. Първо виж кои устроиства кои прекъсвания ползват (cat /proc/interrupts). После можеш да накараш да се изпълняват на определен процесор по следният начин:

echo X > /proc/irq/<irq_num>/smp_affinity

Стойността X е битова маска, всъщност понеже целта е да го bind-неш само към един процесор, а не към няколко, сметките стават много лесно: X = 2^CPU#. Т.е ако искаш прекъсване номер 233 да се обработва само от 3-тия процесор правиш така:

echo 8 > /proc/irq/233/smp_affinity (понеже 2^3 =

Има много спорове по-добре ли е едно прекъсване да се обработва само от един процесор или да се балансира на няколко. Моето лично мнение е че най-добрият вариант е само един процесор да се занимава с това. В противен случай се губят много от предимствата на процесорния кеш. Вероятно обаче други хора имат друго мнение '>

Иначе документацията за драйвера се намира в /usr/src/linux/Documentation/networking/e1000.txt  ако ти се чете..

[VladSun]

Аз преди писах за един проблем с е1000, но не си спомням дали имаше дропнати пакети:

http://www.linux-bg.org/cgi-bin....ethtool

Ти имаш ли такива ARP пакети?

[gat3way]

Доколкото разбирам не са арп-та, а pause frames. В http://standards.ieee.org/regauth/ethertype/eth.txt ги няма (?!?), следователно това вероятно е някакво странно интелско решение '> Служат за реализиране на някакъв flow control (т.е като се напълнят буферите на картата за RX се изпраща един такъв фрейм който информира останалите да спрат да пращат, блабла). Не мисля че са проблемни.

Абе като чета и други хора се оплакват от подобни проблеми с такава карта по разни мейлинг листове. Там понякога ги съветват да си включили rx/rx pause. Не става ясно дали това решава проблема обаче де...бахти странната работа '>

[VladSun]

Така, де - прав си, имах предвид, че са до този MAC адрес.
Иначе ги има в този списък:

Цитат

8807 - 880A  IEEE 802.3                                                    Protocol unavailable.              Bay Networks              PO Box 58185, M/S SC01-05              4401 Great America Pkwy, Santa Cla CA 95052-8185              UNITED STATES

А за този адрес дават:

Цитат

01-80-C2-00-00-01   -802-   802.1 alternate Spanning multicast

в http://standards.ieee.org/regauth/ethertype/eth.txt

Сега ползвам Broadcom и нямам много проблеми с тях.

Добро обяснение за PAUSE FRAMES намерих в http://www.techfest.com/networking/lan/ethernet3.htm
макар, че на пракитка не ми помогна много.

[gat3way]

В конкретният случай обаче...не виждам как flow control-а ще помогне, а и все пак трябва да се подържа от двете страни. Ако никой от другата страна не се сети да спре да предава когато го получи файдата е никаква.

Абе..и щом процесорната утилизация му скача много, предполагам процесора зацикля в обработването на прекъсвания. Когато на един процесор му дойдат прекалено много, дори да се буферират получените пакети, с тази скорост на получаване се стига до момента в който се дропят пакети, поради невъзможност процесора да ги обработи и поради огромния натиск от нови такива върху интерфейса.

Дали NAPI не е крайното решение? Едно е да обработваш хиляди прекъсвания в секунда, съвсем друго е да обработваш не повече от стотина...

[byzon]

Благодаря ви за отделеното внимание и съжелявам че ви занимавам с глупости общо взето '>
За сега всичко върви нормално добавил съм в sysctl.conf
net.core.rmem_default = 524287
net.core.rmem_max = 1048575
net.core.wmem_default = 524287
net.core.wmem_max = 1048575
net.ipv4.tcp_wmem = "4096 16384 524288"

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Но като цяло мисля че някой по скоро е правил някакви мизерии , не може 3 дена да работи на 6 на най голямо натоварване и 2 дена след това да го прави ден след ден при положение че натоварването на мрежата е по малко от предните дни. Ако разбера какво точно е пак ще пиша
Пак ви благодаря !