(ЧАСТИЧНО решено) Как настроить coalescing с ethtool на 3Com 3C2000T (skge)?
Всем доброго времени суток!
Использую гигабитную сетевую плату 3Com 3C2000T.
Вывод lspci:
05:01.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell](rev 10)
Вывод ethtool -i eth1:
driver: skge
version: 1.13
firmware-version: N/A
bus-info: 0000:05:01.0
Раньше пользовался драйвером sk98lin. По нему есть документация, и можно задавать многие параметры при инициализации модуля. Меня, собственно, интересует InterruptModeration. Со старым драйвером ставил 6000 ints/sec., все работало. После перехода на skge я не могу задействовать указанный выше режим работы. Документации по драйверу нет, исследовать и править код я не вижу смысла - нет возможности в лабораторных условиях все проверить.
Написано, что skge - "more complete ethtool support". В ethtool есть ключи '-s' и '-S' для просмотра-установки coalescing parameters. Но, кроме собственно ключа больше вообще ничего не сказано. И нагуглить по этому вопросу ничего не получилось.
Кто может подсказать, как с помощью ethtool настроить coalescing так, чтобы сетевушка генерировала не более, допустим, 7000 прерываний в секунду? Ибо, с новым драйвером она мне до 35000 ints/sec дает, что в хлам загружает процессор. Рядом стоящий Intel PRO/1000 (e1000+NAPI) работает с аналогичной нагрузкой и кол-во прерываний не превышает 7500 ints/sec. Или где можно поподробнее почитать про настройку coalescing parameters с помощью ethtool?
Спасибо за внимание.
- Для комментирования войдите или зарегистрируйтесь
есть такая
есть такая потрясающая вещ, как man ethtool (неожиданно правда?) в первой странице которого написано
например у меня
P.S. собсно ethtool вам в руки. я потратил 5 минут на поиск этой информации, и мне не понадобилось ковырятся в сырцах и делать прочие малопонятные вещи.
:) (ЧАСТИЧНО решено)
У меня вывод ethtool -c eth1 абсолютно идентичен. И я тоже все вами приведенное читал. Ведь написал же об этом.
Попробуйте по мануалу изменить, например, adaptive-rx, и посмотрите, что получится :)
Толку от этой китайской грамоты? Что КОНКРЕТНО означают перечисленные параметры? Вот об этом-то нигде и ничего вразумительного я не нашел. И в мане по ethtool тоже НИЧЕГО не сказано, кроме, собственно, наименования параметров.
Так что не надо меня, как ламера, тыкать носом в мануал. Я задал конкретный вопрос: как установить максимальное кол-во прерываний в пределах 7000 ints/sec с помощью ethtool, а в ответ получил RTFM. Я тоже так отвечать умею.
Что касается моего вопроса. дал мне более-менее вразумительный ответ:
Нашел машину со старым ядром, такой же точно сетевухой и драйвером sk98lin, настроенным на 6000ints/sec.
Вывод ethtool -c eth
rx-usecs: 166
tx-usecs: 166
Все остальное - 0. Установил такие же параметры у себя - и добился желаемого.
Но - это самый дерьмовый метод добиваться результата, поскольку я не знаю, что КОНКРЕТНО я сделал. Догадаться, в принципе, можно. Но можно и ошибиться, а в моем случае это КРАЙНЕ нежелательно.
К сожалению, в
К сожалению, в линуксе так часто бывает, это вам не FreeBSD
..................................................................
Unix - дружественная система, но своих друзей она хорошо выбирает.
???
Это к чему? Вы читали ВНИМАТЕЛЬНО мое первое сообщение и ответ на него?
ВОПРОС: Как с помощью ethtool сделать то-то и то-то?
ОТВЕТ: ethtool тебе в руки, RTFM и т.д.
Причем тут друзья? Я с Linux работаю уже 12 лет, еще с ядер 2.0.х. И не как простой юзер или админ - мне совсем не понаслышке знаком С С++, и исходники драйверов править приходилось частенько для решения своих задач. Про обычное ПО вообще молчу. Так как? Друг я или не друг?
И тут на тебе: RTFM! Лет 10 такого не слышал в ответ на свой вопрос. Поставлен вопрос был четко и ясно, между прочим. И найденное решение я сразу же опубликовал.
Каюсь - в спешке допустил ошибку в формулировке, но ЗНАЮЩИЙ человек сразу же понял бы, что это банальная опечатка.
Конкретно - я написал '-s -S', а должен был '-c -C'
Я не знаю, как там насчет "друзей", но мне кажется, что человек, который является "другом Unix", но тем не менее не знающий ответ на вопрос, просто не должен пытаться на него отвечать, а тем более - тыкать в нос вопрошающего RTFM не разобравшись.
Во-первых это
Во-первых это подпись))
Во-вторых, я имел в виду, что в линуксе часто можно нарваться на непонятные недокументированные вещи. В линуксе нет порядка, строгости и однотипности, свойственного другим юникс системам.
Маны действительно часто оказываются не более содержательными чем "справка mIcrosoft windows".
Во freebsd больше порядка, но меньше возможностей.
RTFM на линукс форумах действительно применяется слишком часто, даже тогда, когда это не оправдвно. Видимо из-за появления большого количества людей, спрашивающих вопросы, ответ на которые дан в манах или хендбуке, вот люди и озлобились )
..................................................................
Unix - дружественная система, но своих друзей она хорошо выбирает.
Прошу прощения
Ну ёлки-палки, это уже совсем :)
Эта проблема с перегрузкой проца совсем меня заморочила. Это же надо - не суметь распознать подпись в сообщении :D
Насчет недокументированных вещей - это да, с этим я хорошо знаком. FreeBSD я пробовал, не понравилось, поэтому не применяю.
Прошу меня извинить за излишнюю и неуместную резкость.
вообще есть
вообще есть мысль включить
Adaptive RX: off TX: off
пошарил по нэту, рисуется примерно такая картина - прерывания генерятся через некоторое количество пакетов, если сделать количество пакетов большим - на слабой нагрузке будут большие лаги, зато на большой нагрузка снизится и наоборот.
собсно прога как раз и ставит границы "большиго" и "маленького" количества пакетов, интервал измерения и/или количество запросов. видимо обьяснений тут немного от того что нужно разобраться в механизмах работы сетевых интерфейсов.
если заработает автопилот - думается буит лучше.
а чем ты меряеш количество прерываний?
Не включается
Это я попробовал в пернвую очередь. Нифига не работает. Ядро 2.6.24.3, x86_64, vanilla source.
Adaptive RX (TX) остается off, а параметр tx-usecs с 99 сбрасывается в 0. И все.
Кол-во прерываний я меряю утилитой 'itop' собственного производства :)
Я ее написал полностью сам, после того, как увидел и попробовал подобную утилиту с аналогичным названием. Она в принципе работает нормально, но есть недостаток: не поддерживаются SMP системы. Моя умеет считать прерывания на каждом процессоре отдельно. Работает просто, как дверь: раз в секунду читает /proc/interrupts и сравнивает текущие значения со значениями, взятыми в прошлом чтении. Их разность и есть кол-во прерываний в секунду.
Нагрузка у меня стабильно большая - минимум 40-50Мбит, максимум 400-500Мбит, так что лагов не будет :)
Кстати... Intel Pro/1000 генерит прерываний меньше, а грузит процессор больше где-то на 25-30%...
>Кстати... Intel
>Кстати... Intel Pro/1000 генерит прерываний меньше, а грузит процессор больше где-то на 25-30%...
а в ядре включен I-OAT ?
ну, значит нужно играть с с параметрами *-irq, по виду как раз они за прерывания и отвечают. ещё бы понять разницу между usecs и frame... возможно это микросекунды и количнество кадров соответственно... чтоли самому поиграть?