polling для ускорения работы сетевых плат под FreeBSD

      Озадачился протестить - есть ли выигрыш от polling`a - вкратце - это такое хитрое управление сетевухой и прерываниями. В обычных условиях сетевуха генерит прерывание на каждый пришедший пакет - требуя чтоб ЦП выделил ресурсы на его обработку. Как итог, при большой нагрузке, сетевуха генерит несколько тыщ прерываний в секунду - а это не есть гуд, быстродействие машины снижается. Если же включить polling, то прерывания генерятся по таймеру (1000 в секунду, обычно), загрузка проца падает и быстродействие повышается. Естественно всё это не даром - повышается латентность сети, ибо в худшем случае на обработку пакета уходит на 1 миллисекунду (при HZ=1000) больше чем без этой функции. Если некритично - то можно юзать.

    Тестовая машина: 2x450MHz PIII (100x4.5, 512 кеша, Slot1), 2x128 ECC SDRAM (133MHz), 2x17Gb SCSI (Сами харды U160, но контроллер в маме тянет лишь 40Mb/s) сетевуха 3com - 100Mb/c. (фото мамы есть тут - я уже успел потыкаться в неё паяльничком :))) Для начала делаем то, чем будем тестировать - файл немерянного размера:

/usr/home/lissyara/>dd if=/dev/zero of=3gb_file bs=512 count=6291456
6291456+0 records in
6291456+0 records out
3221225472 bytes transferred in 82.756136 secs (38924310 bytes/sec)
/usr/home/lissyara/>ls -alh | grep _file
-rw-r--r--  1 lissyara  wheel   3,0G 30 мар 13:04 3gb_file
/usr/home/lissyara/>

Во, клёво. Трёхгиговый файл. (я его из интересу заархивировал - получилось 3 мегабайта. щас вот сижу, и так и подмывает кому-нить почтой отправить, обозвав типа "Голая Анна Курникова.bmp.gz" - чувак долго будет ждать пока разархивируется :))))

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

    Для включения этого режима, необходимо пересобрать ядро с опцией:

options         DEVICE_POLLING

После сборки, установки и перезагрузки в sysctl появятся такие опции:

/usr/home/lissyara/>sysctl -a | grep polling
    lissyara@test-bsd-6.local:/usr/obj/usr/src/sys/GENERIC-polling
kern.polling.burst: 150
kern.polling.burst_max: 150
kern.polling.each_burst: 5
kern.polling.idle_poll: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 20
kern.polling.short_ticks: 473
kern.polling.lost_polls: 908
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 0
kern.polling.enable: 0
kern.polling.phase: 0
kern.polling.suspect: 604
kern.polling.stalled: 0
kern.polling.idlepoll_sleeping: 1
hw.acpi.thermal.polling_rate: 10
/usr/home/lissyara/>

Из них интересней всего лишь одна - kern.polling.enable - она и отвечает за то, включен или выключен режим поллинга.

/usr/home/lissyara/>sysctl -d kern.polling.enable
kern.polling.enable: Switch polling for all interfaces
/usr/home/lissyara/>

Переменные sysctl можно менять находу, изменения принимаются сразу, без перезагрузки:

/usr/home/lissyara/>sysctl kern.polling.enable=1
kern.polling.enable: 0 -> 1
/usr/home/lissyara/>

Соответственно теперь этот режим включен. После перезагрузки переменная примет дефолтовое значение ("0"), и чтобы не вносить изменения руками, есть файл /etc/sysctl.conf, можно эту строку внести в него, и всё. Итак, можно тестировать.

    На выходе получилась примерно такая табличка:

Тип ядра и опции	speed in	% CPU in	speed out	% CPU out
GENERIC+polling-disable	2.01	87.69	3.72	94.00
GENERIC+polling-enable	7.34	84.65	10.08	20.43
GENERIC+polling-disable+SMP	4.38	87.32	7.91	85.12
GENERIC+polling-enable+SMP	9.74	52.01	9.45	28.25

Скорость в мегабайтах в секунду, загрузка ЦП в процентах.

    Ну и выводы по результатам таблицы:

В однопроцессорном режиме результат разгромный - в режиме приёма втрое, да ещё и загрузка проца снизилась (правда ненамного), в режиме передачи прибавка тоже втрое, но загрузка проца упала больше чем в 4 раза. Я думаю, что на сильно загруженных машинах оно того стоит.

    В SMP режиме всё ожидаемо - загрузка меньше, скорость выше - голов всё же две. Для однопроцессорных машин можно смело рекомендовать, а для многопроцессорных надо более развёрнутое тестирование.



P.S. Гонял этот режим на первом пне (ну не совсем первом, и совсем не пне - AMD K6-II 550MHz) - выигрыш копеечный - порядка 500кб/с - проц всё равно загружен под сотню. Но - и это неплохо, нахаляву-то :))) Но - есть одно но. При простое, когда копеечный траффик, всё равно `interrupt` жрут 10% проца, и это чувствуется... Так что режим выгоден тока в случае нагрузки. Будет время - нарисую скрипт, чтоб отслеживал появление нагрузки и врубал этот режим.

P.S.2 По просьбам трудящихся: Пакеты не теряются :)))

northern, 2006-04-04 в 21:43:49

Для какой версии фри, неплохо указать.

lissyara, 2006-04-04 в 22:44:26

Сорри, забыл указать - каталось на 6.0 - самый первый релиз (который р0). Надо сразу отметить что появился режим давно - ещё на ветке 4.х но штатно его включить можно было лишь на однопроцессорном ядре. Нештатно (удалив пару строк в исходниках) включался и работал и на SMP-ядрах. Видимо поэтому его толи на 5-ке толи с 6-ки (точно не знаю) включили и в SMP вполне штатно.

levsha, 2006-04-29 в 18:14:11

1. polling это не "прерывания генерятся по таймеру" а просто опрос сетевухи по таймеру. Никаких прерываний не генерируется. 2. С какой стати ожидалось что polling будет влиять на исходящий траффик? А вообще polling очень помогает на роутерах c транзитным траффиком и большим pps (именно pps прежде всего влияет на нагрузку а не bytes per second): у меня есть машинка, которая без polling в рабочее время загружается на >50% cpu а с polling + fastforwarding только на пару процентов

lissyara, 2006-04-29 в 19:30:39

1. А как Вы представляете себе механизм опроса? :) 2. Не ожидалось. Но результаты интересные, верно?

SergDN, 2006-05-28 в 0:40:47

Карточки были какие? Напишите, пожалуйста.

NuN, 2006-06-05 в 10:08:57

В 5.4 polling + SMP не работает, только по отдельности и в доках это написано.

Кузьмич, 2006-10-18 в 19:16:16

Дык, понятно, что выигрыш получился копеечный в случае с тем K6. Кроме polling.enable есть еще интересные переменные. Например, polling.user_frac - процент времени, оставляемый приложениям. В вашем случае было 90. Поставили бы 80 - разница сразу стала бы ощутимее. polling.idle_poll - выполнять поллинг вместо idle-процесса. Дает нагрузку на CPU - 100%, но можно оставить user_frac=90 без последствий для производительности: если процессору есть что делать помимо поллинга - idle-процеесс будет вызываться реже, и, соотвественно, частоста поллинга упадет до приемлемых величин. Если же процессор справляется с потоком данных - будет черпать их на максимальной скорости. И не забывает добавить в ядро опцию HZ=1000 или HZ=2000 (на мощных процессорах) - частота срабатывания планировщика и, как следствие, поллинга. P.S. На SMP поллинг работает. P.P.S. На двух PIV-3 после настройки протокола TCP (увеличение буферов) с поллингом достугнута скорость 105 мегабайт в секунду (сетевухи - em, мерилка - /usr/ports/benchmarks/iperf )

None, 2006-11-23 в 1:27:36

Thanks bro!

kisa, 2006-11-25 в 1:00:23

Для сильно нагруженных гигабитных линках хорошо бы увеличить burst_max. Иначе даже при значении HZ=4000 система может не успеть обработать все пакеты из буфера сетевухи, прежде чем произойдет их перезапись новыми. Вот, что на этот счет говорит Luigi: i would probably increase HZ to 2000 and burst_max to 300-400, not much more though otherwise you are going to spend too much time in the timer handler. In any case, i don't think the card is able to go above 6-700kpps. If you are having a lot of load, it is natural that you are going to get losses, the 2sec period is probably how often the nic updates the stats. cheers luigi

Fmod, 2007-06-24 в 12:31:34

Попровал polling на своем роутере: P2-300Mhz, сетевухи rtl8139d, FreeBSD 6.1 Скорость с pooling на входящий и исходящий траффик падает примерно на 10% (мерял форточным диспечером задач:), загрузка процессора тож падает но незначительно, на 5% примерно. Скорости и загрузка процессора примерно как в таблице выше у GENERIC+polling-disable. Вывод: для таких старых компов как мой, pooling лучше не включать.

Я просто проверил скрипт :), 2007-07-20 в 17:31:54

Т о в а р и щ щ и ! Э т о п о л я д л я в в о д а к о м м е н т а р и е в к с т а т ь е , а н е д л я в о п р о с о в . С ю д а п и ш и т е н а й д е н н ы е б а г и , и л и к а к и е - т о ф и ч и : ) Д л я в о п р о с о в е с т ь ф о р у м !

Я просто проверил скрипт :), 2007-07-20 в 17:32:44

Прошу прощения, стыдно... :)

Аноним, 2007-10-29 в 7:15:04

Надеюсь никто не забыл, что polling(4) существует не только для сетевых драйверов? sound(4): dev.pcm.%d.polling Experimental polling mode support where the driver operates by querying the device state on each tick using a callout(9) mechanism. Disabled by default and currently only available for a few device drivers.

Maximka, 2007-10-29 в 11:45:45

Хотелось бы всё-таки разобраться со всеми kern.polling.бла-бла-бла. Как говорят, там тоже надо кой-чё подкручивать для достижения макс. эффекта. Выйдет семёрка, в ней локов нету в сетевом коде — надо будет всё перемерять и проверить. Слыхал, должно быть всё намного мощнее.

void, 2008-01-01 в 22:49:40

Пробовал у себя, машина пень3 500мгц еще старый, слотовый, катмаи ядро вроде. Скорость мерял виндовым диспетчером задач при сливе и заливе фильмов на фтп :) Использовал proftpd и vsftpd по очереди. dmesg | grep fxp0 fxp0: <Intel 82558 Pro/100 Ethernet> port 0x7c60-0x7c7f mem 0xf3eff000-0xf3efffff,0xf3f00000-0xf3ffffff irq 11 at device 3.0 on pci0 Что интересно: при использовании vsftpd что с полингом, что без него - скорость 11.5МБ/с на выход и 7МБ/с на вход, а вот при использовании proftpd с полингом примерно тоже, а без полинга - в обе стороны по 6МБ/с... Загрузка камня в любом случае почти 100%. Странно...

maksgraf, 2008-08-17 в 17:15:22

в 7-ке уже все несколько проще. Да, ядро надо пересобрать. Но включается polling через ifconfig. т е например хочу включить на интерфейс em0. В rc.conf пишем ifconfig_em0=" бла бла бла polling"

Sash, 2009-05-17 в 16:48:04

SUPPORTED DEVICES Device polling requires explicit modifications to the device drivers. As of this writing, the bge(4), dc(4), em(4), fwe(4), fwip(4), fxp(4), ixgb(4), nfe(4), nge(4), re(4), rl(4), sf(4), sis(4), ste(4), stge(4), vge(4), vr(4), and xl(4) devices are supported, with others in the works. The modifications are rather straightforward, consisting in the extrac- tion of the inner part of the interrupt service routine and writing a callback function, *_poll(), which is invoked to probe the device for events and process them. (See the conditionally compiled sections of the devices mentioned above for more details.)

Sash, 2009-05-17 в 16:49:30

это на 7.0-RELEASE

Folder, 2009-05-21 в 3:58:10

Интересует вопрос, SMP режим на однопроцессорной машине включается, если да, то каким образом?

Dog, 2009-05-21 в 11:04:55

В прошлом году на OpenKyiv2008 я был свидетелем беседы разработчиков FreeBSD Константина Белоусова (присутствовал как слушатель) и OpenBSD Михаила Белопухова (присутствовал как докладчик). Поскольку Михаил делал доклад по сетевой подисистеме, в личной беседе они обсуждали именно эту тему. Константин в какой-то момент сказал что разработчики FreeBSD сейчас уходят от механизма polling'а. В личном письме я спросил у него, почему? Привожу часть нашей переписки (в ответном письме есть ссылка на доклад Михаила Белопухова, презентацию можно посмотреть на uaoug.org.ua, полного доклада я, к сожалению, в интернете не нашел): Мое письмо: Здравствуйте! Прошу прощения что отнимаю время, но, будучи на OpenKyiv2008, слышал Вашу беседу с Михаилом Белопуховым: в частности Вы упомянули о том, что сейчас разработчики FreeBSD уходят от polling'а сетевых карт. К сожалению часть беседы пропустил, поэтому не понял, почему именно. Меня заинтересовало - почему? Пытался погуглить по этому поводу - но уяснить этот вопрос для себя так и не смог. На моей нынешней работе (***** в Харькове) на паре достаточно загруженных серверов включенная опция polling давала неплохой прирост производительности. Не могли бы Вы прояснить ситуацию? Или хотя-бы задать направление, где об этом можно прочесть. Заранее благодарен за ответ, еще раз извиняюсь за беспокойство. Ответ Константина Белоусова: Текущая архитектура FreeBSD обрабатывает прерывания от устройств, и, в частности, сетевых карт, в специально запущенных для этого нитках. Нить блокирована, единственное действие кода обработки прерывания - разблокировка нити. Вот кусочек вывода ps auxww на машине, с которой я это пишу: root 218 0.0 0.0 0 8 ?? WL 9:46PM 0:00.79 [irq20: rl0 fwohci0] root 220 0.0 0.0 0 8 ?? WL 9:46PM 0:05.69 [irq22: skc0 ath0] Почти все современные сетевые адаптеры для 1000baseTx имеет feature называемую "interrupt coalescing", задерживающую вызов прерывания до заполнения Rx кольца адаптера. Третье обстоятельство - это так называемый direct dispatch. Если вы помните, докладчик упоминал об отдельном процессе netisr, предназначенном для обработки Rx фреймов. Причина существования netisr - тот факт, что прерывание от Rx может прийти в момент, когда процессор уже выполняет сетевой код, и полная обработка пакета из interrupt handler привела бы к рекурсивному входу в сетевой стек. Альтернативой было бы поднять приоритет процессора до splnet (в терминах OpenBSD), но это бы означало, что прерывания блокированы на длительное время. Но, поскольку FreeBSD выполняет настоящий обработчик прерывания в отдельной нитке, то netisr не нужен. Все обработка входящего пакета можеть произойти без дорогостоящего переключения контекста. Это и есть direct dispatch. Direct dispatch включен по умолчанию на FreeBSD >= 7: net.isr.direct: 1 Нетрудно видеть, что комбинация всех трех упомянутых архитектурных элементов эквивалентна pollingу и даже эффективнее его. Конечно, есть сетевые карты, для которых polling выигрывает, но тенденция состоит в том, что direct dispatch не хуже и более естественен.

grumble, 2010-04-01 в 5:13:17

Уже вышла 8ка Так всё таки стоит пуллинг включать или нет?

Sash, 2010-04-03 в 5:18:35

на 8 эффекта не наблюдается

ОЛОЛО, 2010-05-27 в 0:46:25

На восьмёрке с этой хренью только хуже всё. Нагрузка проца на 40% больше, скорость таже.

`Оставьте свой комментарий:`
`Ваше имя: *`
`e-mail:`
`жирный` `наклонный` `подчёркнутый` `ссылка` `цвет`	Товарищщи! Это поля для ввода комментариев к статье, а не для вопросов. Сюда пишите найденные баги, или какие-то фичи :) Для вопросов есть форум!
`Нынешний год: *`

options DEVICE_POLLING в ядре

`options DEVICE_POLLING в ядре`