Spectator Опубликовано 21 января, 2009 (изменено) · Жалоба Кстати, хотел узнать. Можно ли на живом адаптере менять параметры драйвера, без его выгрузки? Если сетевая интеловская 1000Pro PT или подобное, то можно. К примеру так: rmmod e1000e; modprobe e1000e InterruptThrottleRate 1,1,1,1 Некоторые параметры конечно нет, только при загрузке например: IntMode Очень интересный параметр, но почему то на моей системе отказывался работать, только PCI-MSI режим и все. Изменено 21 января, 2009 пользователем Spectator Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Spectator Опубликовано 21 января, 2009 (изменено) · Жалоба 1. Есть ли какие-то методы распределения софт прерываний на несколько процессоров, для их более быстрой обработки? Есть, и только так удалось добиться максимальной производительности. irqbalance не всегда верно распределяем нагрузку. А если ядро в полке - то сетевую он от туда достать не может. Я распределяю так: /etc/init.d/irqbalance stop sleep 3 echo 1 > /proc/irq/82/smp_affinity echo 2 > /proc/irq/98/smp_affinity echo 4 > /proc/irq/104/smp_affinity echo 8 > /proc/irq/106/smp_affinity где 82,98,104,106 - прерывания на которых висят интерфейсы. а значения 1,2,4,8 - десятичное (если не ошибаюсь), представление битовой маски. К примеру на восьмиядерной системе: CPU0 00000001 = 1 CPU1 00000010 = 2 ..... ну и так далее. Но там много граблей с распределением двуголовых сетевых по ядрам. Я лично вычислял опытным путем. 2. Можно ли как-то управлять поллингом для драйвера e1000? Потому как, судя по документации, поллинг начинает работать только, когда количество пакетов превышает количество возможных прерываний в системеДа по умолчанию в режиме 3 он "типа" сам работает. Но этот режим скорее подходит для домашнего ПК. А так этот параметр уже упоминался тут InterruptThrottleRate. Изменено 21 января, 2009 пользователем Spectator Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Spectator Опубликовано 21 января, 2009 · Жалоба Вопрос! Кому то удалось откомпилировать дрова e1000e с мульти MSI-X векторами? (типа make CFLAGS_EXTRA=-DCONFIG_E1000E_SEPARATE_TX_HANDLER) ??? В мануалах пишут, что получается 3 вектора для каждой сетевой: один для TX, один для RX и один для линка. По идее для мультиядерной системы - это подарок с небес. У меня как был 1 так и остался как ни крути. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 21 января, 2009 (изменено) · Жалоба 2Spectator: Объясню в чем фишка жестко установленного InterruptThrottleRate ( ITR ). Конечно в моде 1, фисло прерываний куда выше, чем в режиме 3. Но суть заключается в том, что, если драйвер решил, что трафик подходит по паттерну в Bulk, то в режиме 3 ставит количество прерываний равное 4000. В этом случае, если, драйвер не успевает разгребать очередь за эти 4К прерываний, система уходит в soft irq, откуда её достать достаточно проблематично, особенно, когда пакеты валят вне зависимости от появившегося высокого пинга. А когда выходит, то не на долго, т.к. 4К прерываний - это относительно мало, по крайней мере для моего трафика, моей сетевухи и моего кол-ва пакетов. ITR = 1. Это те же яйца, только для разных паттернов трафика расставлено больше прерываний. Но вот незадача - для Bulk traffic это значение всеравно равно 4К. Основная же проблема, что драйвер спустя какое-то время, начинает считать, при любом трафике, что паттерн Bulk - самый подходящий и в результате держит 4К прерываний и убивает систему soft irq. И еще один момент разбивающий всю идилию: изначально, после рестарта драйвера - создается иллюзия, что все работает нормально. И даже при большом количестве пакетов роутер чувствует себя нормально. Но спустя какое-то время. У меня это от 18 до 25 дней - начинается одинаковая попа с прерываниями. Ну и конечно же она происходит в пик тайм. Чем хорош статическии установленный ITR - тем, что он не "присматривается" к трафику и делает, в моем случае, максимальное количество прерываний, то есть обеспечивает минимальный rtt. На бОльшей нагрузке подключается NAPI и количество прерываний там меньше pps, но всеравно достаточно высокое, чтобы держать нормальный rtt. То есть на данном этапе, после установленного статически ITR проблем с роутером не наблюдалось, но опять таки - проблема может проявиться позже, поэтому я пока тестирую и отпишусь позже Насчет e1000e. Я пробовал его поставить, но моя сетевуха 82566DM не находится этим драйвером. Гугл молчит по этому поводу. Я понимаю, что сетевая не блеск, но для моих целей вполне подходит и почему её не находит драйвер, я не знаю. Новый e1000, кстати, 8.х который, её тоже не видит. Приходится сидеть на последнем 7.х Насчет SMP Affinity. Я пробовал и с ним и без. Вывод таков, что на 2.4 ядре совершенно пофигу есть он или нет. Вся разница в том, что прерывания начинает обрабатывать один процессор и в топе висит ksoftirqd от его имени. Вот и все. Принципиально это ничего не меняет и я с этим даже не парюсь. Тем более, что некоторые источники утверждают, что распределение прерываний по процессорам даже лучше, т.к. прерывание в таком случае выполняет первый освободившийся процессор, что уменьшает общее число переключений контекста. Но, чесно говоря, ни первого, ни второго не заметил, поэтому оставил по умолчанию. У меня правда одна сетевая и, может, на нескольких сетевых это что-то дает. Но для одной сетевой заморачиваться точно не стоит. Насчет смены параметров - rmmod - это и есть выгрузка драйвера. При этом завалиться интерфейс привязанный к устройству и надо будет заново подымать роуты, рулы, если они есть. Мне в таком случае проще перегрузить машину, чем это все вручную подымать. И еще один важный вопрос: У Вас что-то крутиться на машине, кроме тупо роутинга? Нет флов, там, базы, биллинги ... ? 2nuclearcat: Мне кажется, что если подобрать этот параметр правильно, то его можно просто один раз вбить дефолтом и больше к этому вопросу не обращаться. Походу ребята из Интел так и сделали, вот только в режиме 3 машина в качестве роутера чувствует себя не очень, при скоростях выше 100 Mbit, по крайней мере, на моей конфигурации. Изменено 21 января, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 21 января, 2009 · Жалоба У меня прекрасно себя чувствует машина на 400-500 Mbit/s, судя по мониторингу. А softirqd кушает проц - т.к. где-то в сетевом стеке затык. У меня было, когда использовался HPET таймер и hrtimers. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 22 января, 2009 · Жалоба Ну так я думаю, что 400-500 Мбит у Вас не на бюджетной 82566DM? А стоит какая-то внешняя PCI-X сетевая, да еще и с MSI, MSI-X поди. Да и ksoftirqd кушает проц по чуть-чуть, а не на 100%, правда же? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 января, 2009 · Жалоба Есть такое. Это серверные матери. А если 82566DM встроенный в ICH8 - он вообще никуда не годится. У этого "встроенного" урезанный внутренний буфер. Он и 200 Мбит реального траффика с трудом жует. Гигабит может только разве что как юзерская карта, скачать с FTP файлец. Верный признак урезанности - не умеет полноразмерные jumbo frames. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 22 января, 2009 · Жалоба Все верно излагаете. Карта интегрированная и у неё толи 8, то ли 16К буферов. Не понятно. В даташитах по этому вопросу ничего нет. Jumbo frames умеет, но Вы сами понимаете, что не рекомендуется с таким буфером. В данном, конретном лучае жевать надо до 200 Мбит проходящего трафика. Больше от неё и не требуется. По идее, должна справляться. Естественно, конфигурация драйверов и системы требует доработки напильником, т.к. данная сетевая не предназначена вообще для работы в условиях сервера. Но ведь в этом-то и суть, т.к. позволяет разобраться во всех ньюансах работы системы без выполнения аппаратного апгрейда. Кроме того становиться очевидно зачем выполнять апгрейд и для каких условий какие сетевые больше подходят. На самом деле, я недеюсь, что выполненные махинации описанные в этой теме являются хорошим подспорьем при разборке ситуаций с перегрузкой роутеров в виде выхода ksoftirqd. Нормальных тем в инете в этой теме вообще нет. Вся информация обрывками. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 января, 2009 · Жалоба У меня эта карта теряла пакеты на 200-250Mbps, просто при пустом форвардинге, но с таблицей роутинга в 1300 записей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 22 января, 2009 (изменено) · Жалоба Спасибо, ценная информация, но пока, судя по тестам, на скоростях до 200 Мбит, показывает себя нормально. На машине > 3000 роутов. Вообще я считаю, что Вы правы и больше 200 Мбит, на ней крутить не стоит. Рисковое это дело. Тем более сетевая карта для PC - это не плата для кошки, можно 100-200 баксов и потратить один раз. А без MSI разрулить больше 200 Мбит трафика будет как минимум проблематично. Но почему была поднята вся эта тема: есть две одинаковые машины, именно с этими сетевыми и с проходящим одинаковым трафиком. Стоят друг за другом по маршрутизации. На одной все нормально ( Fedora 6, 2.6 ядро, да еще и pptp терминация ), на второй приходиться интенсивно работать напильником ( ASPLinux 9 с собраным последним ядром 2.4 ). Единственное принципиальное отличие - это на проблемной машине есть fprobe. То есть получается, что дело не только в сетевухах. Если бы сетевая начала терять пакеты - вопрос был бы снят вместе с сетевухой. А так, явно же разница в настройках играет роль. Вот, хочу разбораться где именно крутить гайки. Изменено 22 января, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 22 января, 2009 · Жалоба > Кому то удалось откомпилировать дрова e1000e с мульти MSI-X векторами? (типа make CFLAGS_EXTRA=-DCONFIG_E1000E_SEPARATE_TX_HANDLER) ??? Скомпилить - скомпилилось, но по идее не пашет (в /proc/interrupts на одну eth по 1 номеру прерывания), насколько я понимаю оно будет работать только на 82575 и 85276 based карточках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 22 января, 2009 (изменено) · Жалоба На сколько я понимаю прерывания и остается одно. Вот только данные от/к карточке ходят уже по-другому принципу. Проясните, пожалуйста, немного этот момент, у кого получилось настроить несколько векторов. То есть где это можно увидеть в системе, за исключением пометки MSI-X в /proc/interrupts ? ЗЫ Тем кто не в струе - полезная ссылка про MSI http://devresources.linux-foundation.org/d...n/MSI-HOWTO.txt Изменено 22 января, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
muchacho Опубликовано 25 января, 2009 · Жалоба в e1000e можно этим параметром управлять динамически через ethtool -cА можно подробенее? Может кто-нибудь знает нормальную доку про ethtool? rx_missed_errors: 12471649 tx_deferred_ok: 4302243 tx_restart_queue: 1780921 tx_tcp_seg_good: 3654 rx_flow_control_xon: 4372530 rx_flow_control_xoff: 4367738 tx_flow_control_xon: 436942 tx_flow_control_xoff: 447152 rx_long_byte_count: 2801363193093 rx_csum_offload_good: 3014004698 rx_csum_offload_errors: 791 Это хорошо или плохо? Нигде не могу найти нормального описания значений. Стоит ли включать/выключать flow control? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 26 января, 2009 · Жалоба Насчет переменных - я так понимаю, они driver specific, поэтому доки надо смотреть для драйвера, а не для ethtool. Насчет flow control - все говорят о том, что необходимо выключать, потому как целостность отслеживается на других уровнях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
muchacho Опубликовано 26 января, 2009 · Жалоба Сетевуха PRO/1000PT, драйвер e1000e. А как на счёт изменения InterruptThrottleRate через ethtool? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 января, 2009 · Жалоба в e1000e можно этим параметром управлять динамически через ethtool -cА можно подробенее? Может кто-нибудь знает нормальную доку про ethtool? rx_missed_errors: 12471649 tx_deferred_ok: 4302243 tx_restart_queue: 1780921 tx_tcp_seg_good: 3654 rx_flow_control_xon: 4372530 rx_flow_control_xoff: 4367738 tx_flow_control_xon: 436942 tx_flow_control_xoff: 447152 rx_long_byte_count: 2801363193093 rx_csum_offload_good: 3014004698 rx_csum_offload_errors: 791 Это хорошо или плохо? Нигде не могу найти нормального описания значений. Стоит ли включать/выключать flow control? rx_missed_errors: 12471649Очень плохо. Но в зависимости от общего количества пакетов. Но все равно выглядит плохо. Говорит о том, что ваша железка не успевает переваривать пакеты. ethtool -g интерфейс покажите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
muchacho Опубликовано 26 января, 2009 · Жалоба Очень плохо. Но в зависимости от общего количества пакетов. Но все равно выглядит плохо.Говорит о том, что ваша железка не успевает переваривать пакеты. Железка - C2D E8400 3.00GHzсетевухи - двойная pro/1000pt + dlink DGE-530T Оба ядра простаивают как минимум на 65-70% total: 578.89 Mb/s In 464.12 Mb/s Out - 80351.1 p/s In 76345.1 p/s Out eth0: 89.04 Mb/s In 205.86 Mb/s Out - 18797.9 p/s In 22802.6 p/s Out eth1: 185.42 Mb/s In 66.01 Mb/s Out - 21251.1 p/s In 18324.6 p/s Out eth2: 61.38 Mb/s In 63.27 Mb/s Out - 9525.5 p/s In 8446.6 p/s Out Но это сейчас, вечером нагрузка, конечно, больше. По идее должна успевать переварить всё. ethtool -g интерфейс покажите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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 января, 2009 · Жалоба ethtool -G eth0 rx 2048 ethtool -G eth0 tx 2048 делать лучше всего при небольшой нагрузке, карта отвалится на несколько секунд Простой ядра ничего не значит, вся мощность может например теряться в локингах в conntrack, например Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 26 января, 2009 · Жалоба А почему нельзя в данном случае сделать ethtool -G eth0 rx 4096 ethtool -G eth0 tx 4096 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 января, 2009 · Жалоба чрезмерное увеличение буферов может привести к повышенным cache misses... Для начала надо отследить, привело ли увеличение буферов к уменьшению относительного количества потерь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 26 января, 2009 · Жалоба А где можно отследить наличие cache misses? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
muchacho Опубликовано 26 января, 2009 · Жалоба ethtool -G eth0 rx 2048ethtool -G eth0 tx 2048 Сделал, но rx_missed_errors всеравно понемногу увеличивается. Простой ядра ничего не значит, вся мощность может например теряться в локингах в conntrack, напримерКонтрэка нет. Там iptables, ipset - пара десятков правил, пара десятков статических маршрутов, на сетевухи навешены 7 вланов. oprofile показывает 346114257 38.1517 vmlinux 181987020 20.0602 e1000e 135328669 14.9171 ip_tables 112973591 12.4529 ip_set_nethash 38834175 4.2806 ip_set opreport -l /usr/src/linux-2.6.27.11/vmlinux: 72201103 20.7549 mwait_idle 22860827 6.5716 irq_entries_start Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rims Опубликовано 2 февраля, 2009 · Жалоба azazello - если какая-то операция I/O заблокирует "нужную подсистему" локом - встанут все ядра, и буду ждать, пока закончит.conntrack меня таким поведением доводил до белого каления... пока нашел в чем дело. а можно вопрос... в чем было дело? если можно - по подробнее.. какие симптомы были и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 2 февраля, 2009 · Жалоба А где можно отследить наличие cache misses?oprofile, установив соответствующий event azazello - если какая-то операция I/O заблокирует "нужную подсистему" локом - встанут все ядра, и буду ждать, пока закончит.conntrack меня таким поведением доводил до белого каления... пока нашел в чем дело. а можно вопрос... в чем было дело? если можно - по подробнее.. какие симптомы были и т.п. Симптом прост - роутер, хотя процессор и не загружен на 100% - отчаянно теряет пакеты.Вообще похоже это скорее болезнь iptables. Новые коммиты одного из разработчиков в исходники ядра частично эту проблему решат. В 2.6.30 наверное будут уже в релизе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 5 февраля, 2009 (изменено) · Жалоба Как и обещал отписываюсь по тестам: установка ITR = 100K решила проблему перегрузки машины softirq. Прошло 30 дней. Полет нормальный. Изменено 5 февраля, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...