гигабит и тормоза
Eugene Grosbein
Попробовал потестировать работу FreeBSD 7.1 на гигабите,
причем не стека и не форвардинга, а только самый нижний уровень -
драйвера сетевух.
Соединил две FreeBSD 7.1-STABLE, собранные из одних исходников,
кроссовером напрямую в гигабитные сетевухи и зарядил ng_source
посылеть UDP-пакет с 64 байтами данных (106 байт фрейм ethernet)
из одной машины в другую. Посылатель имеет интегрированную интелевскую
сетевую em0:
em0@pci0:4:0:0: class=0x020000 card=0x30a58086 chip=0x109a8086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82573L Intel PRO/1000 PL Network Adaptor'
class = network
subclass = ethernet
А также процессор Pentium-D 2.8Ghz dualcore, материнка Intel D975XBX.
Так вот, одно ядро этого самого CPU посылателя в процессе было
загружено на 45%, второе простаивало и он смог послать только
392465 пакетов в секунду (тест шел 60 секунд), итого 332810320 бит
в секунду, загрузив линк только на треть. При этом приёмник своей
сетевухой принял более 99.5% отправленных посылателем пакетов - количество
отправленных показал сам ng_source, количество принятых показал ipfw,
при этом одно ядро приёмника было загружено не более чем на 40%
обработкой прерываний (ядро GENERIC).
Вопрос: где наиболее вероятное узкое место в посылателе?
Eugene
--
Устав от радостных пиров,
Hе зная страхов и желаний
Eugene Grosbein
EG> Вопрос: где наиболее вероятное узкое место в посылателе?
Если это важно, на посылателе:
# sysctl -a | fgrep msi
hw.pci.honor_msi_blacklist: 1
hw.pci.enable_msix: 1
hw.pci.enable_msi: 1
Eugene
--
- Локапалы непобедимы, - сказал Кубера, а девочка подняла кубик
и долго-долго разглядывала его, прежде чем назвать.
Eugene Grosbein
EG>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG> Если это важно, на посылателе:
EG> # sysctl -a | fgrep msi
EG> hw.pci.honor_msi_blacklist: 1
EG> hw.pci.enable_msix: 1
EG> hw.pci.enable_msi: 1
Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
dev.em.0.rx_int_delay: 200
dev.em.0.tx_int_delay: 200
dev.em.0.rx_abs_int_delay: 200
dev.em.0.tx_abs_int_delay: 200
dev.em.0.rx_processing_limit: 1000
Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
или 342113668 бит в секунду. Это предел железа?
Eugene
--
И друзей успокоив и ближних любя,
Мы на роли героев вводили себя.
Alex Bakhtin
Женя,
EG> Вопрос: где наиболее вероятное узкое место в посылателе?
EG> Если это важно, на посылателе:
EG> # sysctl -a | fgrep msi
EG> hw.pci.honor_msi_blacklist: 1
EG> hw.pci.enable_msix: 1
EG> hw.pci.enable_msi: 1
EG> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG> dev.em.0.rx_int_delay: 200
EG> dev.em.0.tx_int_delay: 200
EG> dev.em.0.rx_abs_int_delay: 200
EG> dev.em.0.tx_abs_int_delay: 200
EG> dev.em.0.rx_processing_limit: 1000
EG> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG> или 342113668 бит в секунду. Это предел железа?
Фигани большими пакетами (1500) и посмотри.
Я как-то писал о проведенном тестировании траффик генератором, правда
роутинга. Мне так представляется что ты упираешься в PCI, хотя может быть я
и ошибаюсь. При теоритической пропускной способности в пресловутый гигабит
на каждый фрейм надо учитывать задержку, связанную с инициированием DMA и
другой оверхед (кмк - я тут не большой специалист, это скорее
измышления).
--
Best regards, Alex Bakhtin, CCIE #8439
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru
Eugene Grosbein
EG>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG>> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG>> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG>> или 342113668 бит в секунду. Это предел железа?
AB> Фигани большими пакетами (1500) и посмотри.
Посмотрю, но мне-то интересен именно pps. Как-то маловато 400kpps.
AB> Я как-то писал о проведенном тестировании траффик генератором, правда
AB> роутинга. Мне так представляется что ты упираешься в PCI, хотя может быть
AB> я
AB> и ошибаюсь.
Hе верю, что для PCI это много, 400kpps.
AB> При теоритической пропускной способности в пресловутый гигабит
AB> на каждый фрейм надо учитывать задержку, связанную с инициированием DMA и
AB> другой оверхед (кмк - я тут не большой специалист, это скорее
AB> измышления).
Я видел сообщения и о бОльших pps.
Eugene
--
Кара за одно съеденное яблоко, все-таки, была несоизмеримо велика,
приступ диареи послужил бы достаточным уроком.
Eugene Grosbein
EG>>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG>> Если это важно, на посылателе:
EG>> # sysctl -a | fgrep msi
EG>> hw.pci.honor_msi_blacklist: 1
EG>> hw.pci.enable_msix: 1
EG>> hw.pci.enable_msi: 1
EG> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG> dev.em.0.rx_int_delay: 200
EG> dev.em.0.tx_int_delay: 200
EG> dev.em.0.rx_abs_int_delay: 200
EG> dev.em.0.tx_abs_int_delay: 200
EG> dev.em.0.rx_processing_limit: 1000
EG> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG> или 342113668 бит в секунду. Это предел железа?
При дефолтных значениях всяческих sysctl простое включение polling на em0
дало увеличение исходящего потока до чуть больше чем 453kpps, что сильно
меняет мои представления о поллинге. При этом загрузка CPU около 45%,
на прерываниях (та же длина пакета 64 байта данных UDP), так что железо
может явно больше. Hикакие кручения параметров kern.polling.* ни на что
не влияют, кроме idle_poll - его включение резко _уменьшает_ исходящий поток.
При включенном поллинге кручение dev.em.0 уже ни на что ощутимо не влияет.
Выключение net.isr.direct ничего не меняет как при при включенном поллинге,
так и при выключенном.
Eugene
--
О, сколько их было - один другого круче,
И каждый знал правду, и каждый был лучше
Того, что был прежде.
Eugene Grosbein
EG>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG>> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG>> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG>> или 342113668 бит в секунду. Это предел железа?
EG> При дефолтных значениях всяческих sysctl простое включение polling на em0
EG> дало увеличение исходящего потока до чуть больше чем 453kpps, что сильно
EG> меняет мои представления о поллинге. При этом загрузка CPU около 45%,
EG> на прерываниях (та же длина пакета 64 байта данных UDP), так что железо
EG> может явно больше. Hикакие кручения параметров kern.polling.* ни на что
EG> не влияют, кроме idle_poll - его включение резко _уменьшает_ исходящий
EG> поток.
EG> При включенном поллинге кручение dev.em.0 уже ни на что ощутимо не влияет.
EG> Выключение net.isr.direct ничего не меняет как при при включенном
EG> поллинге,
EG> так и при выключенном.
Попробовал "SMP-able Yandex's em-driver", который работает без поллинга.
С этим тестом он лишь слегка лучше штатного 6.9.6 в 7.1-STABLE:
загрузка процессора на уровне 45%, но периодически уменьшалась даже до 30%,
а общий pps получился 408k. Hикакого распараллеливания не ощутил,
видимо ng_source под это не заточен. Пока штатный драйвер с поллингом
и его дефолтными настройками наиболее быстр для чистого исходящего флуда :)
Eugene
--
Choose no family
Leizer A. Karabin
Я, собственно, просто так вышел Wednesday January 21 2009 02:48,
тут слышу - Eugene Grosbein говорит All (ну я встрял, конечно):
EG> Попробовал "SMP-able Yandex's em-driver", который работает без
EG> поллинга.
EG> С этим тестом он лишь слегка лучше штатного 6.9.6 в 7.1-STABLE:
EG> загрузка процессора на уровне 45%, но периодически уменьшалась даже до 30%,
EG> а общий pps получился 408k. Hикакого распараллеливания не ощутил,
EG> видимо ng_source под это не заточен. Пока штатный драйвер с поллингом
EG> и его дефолтными настройками наиболее быстр для чистого исходящего флуда :)
А, для полноты исследования, как меняется дело при больших пакетах? До
MTU размером, при фрагментации?..
За сим навеки и проч. Leizer [Team Smile'ик - отменить!]
Max Irgiznov
20 янв 09 01:36, you wrote to All:
EG>>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG>> Если это важно, на посылателе:
EG>> # sysctl -a | fgrep msi
EG>> hw.pci.honor_msi_blacklist: 1
EG>> hw.pci.enable_msix: 1
EG>> hw.pci.enable_msi: 1
EG> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG> dev.em.0.rx_int_delay: 200
EG> dev.em.0.tx_int_delay: 200
EG> dev.em.0.rx_abs_int_delay: 200
EG> dev.em.0.tx_abs_int_delay: 200
EG> dev.em.0.rx_processing_limit: 1000
^^^^^мало
EG> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG> или 342113668 бит в секунду. Это предел железа?
а если еще в loader.conf добавить:
hw.em.rxd=4096
hw.em.txd=4096
а в sysctl.conf
net.inet.ip.intr_queue_maxlen=4096
и dev.em.0.rx_processing_limit=4096
или dev.em.0.rx_processing_limit=-1
то какой будет результат?
--
Yours faithfully Max Irgiznov
Max Irgiznov
21 янв 09 02:48, you wrote to All:
EG>>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG>>> от 46% до 49%, загрузка линка тоже немного увеличилась и
EG>>> достигла 24264704 фреймов за 60.145124 секунд, то есть чуть
EG>>> больше 403kpps или 342113668 бит в секунду. Это предел железа?
EG>> При дефолтных значениях всяческих sysctl простое включение
EG>> polling на em0 дало увеличение исходящего потока до чуть больше
EG>> чем 453kpps, что сильно меняет мои представления о поллинге. При
EG>> этом загрузка CPU около 45%, на прерываниях (та же длина пакета
EG>> 64 байта данных UDP), так что железо может явно больше. Hикакие
EG>> кручения параметров kern.polling.* ни на что не влияют, кроме
EG>> idle_poll - его включение резко _уменьшает_ исходящий поток. При
EG>> включенном поллинге кручение dev.em.0 уже ни на что ощутимо не
EG>> влияет. Выключение net.isr.direct ничего не меняет как при при
EG>> включенном поллинге, так и при выключенном.
EG> Попробовал "SMP-able Yandex's em-driver", который работает без
EG> поллинга. С этим тестом он лишь слегка лучше штатного 6.9.6 в
EG> 7.1-STABLE: загрузка процессора на уровне 45%, но периодически
EG> уменьшалась даже до 30%, а общий pps получился 408k. Hикакого
EG> распараллеливания не ощутил, видимо ng_source под это не заточен. Пока
EG> штатный драйвер с поллингом и его дефолтными настройками наиболее
EG> быстр для чистого исходящего флуда :)
яндекс паралелит только входищий траффик хорошо, да и в моих эксперементах
когда поток шел через 2а em на роутере надо было для эфективной работы больше
4х ядер.
пулинг, давал вообще отрицательные результаты.
Max Irgiznov
20 янв 09 01:36, you wrote to All:
EG>>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG>> Если это важно, на посылателе:
EG>> # sysctl -a | fgrep msi
EG>> hw.pci.honor_msi_blacklist: 1
EG>> hw.pci.enable_msix: 1
EG>> hw.pci.enable_msi: 1
EG> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG> dev.em.0.rx_int_delay: 200
EG> dev.em.0.tx_int_delay: 200
EG> dev.em.0.rx_abs_int_delay: 200
EG> dev.em.0.tx_abs_int_delay: 200
EG> dev.em.0.rx_processing_limit: 1000
^^^^^мало
EG> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG> или 342113668 бит в секунду. Это предел железа?
а если еще в loader.conf добавить:
hw.em.rxd=4096
hw.em.txd=4096
и dev.em.0.rx_processing_limit=4096
или dev.em.0.rx_processing_limit=-1
то какой будет результат?
--
Yours faithfully Max Irgiznov
Valentin Davydov
> Date: Wed, 21 Jan 2009 10:53:44 +0300
" - Доктор, больной такой-то скончался.
- Как жаль! У меня ещё столько интересных идей осталось... "
2EG: а ты по листам рассылки смотрел? Там эту тему раз в пару лет подымают,
и называли цифры то 600, а то и 750 (последнюю - не совсем понятно в каком
контексте).
Вал. Дав.
Max Irgiznov
21 янв 09 14:17, you wrote to me:
>> EG> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
>>
>> EG> dev.em.0.rx_int_delay: 200
>> EG> dev.em.0.tx_int_delay: 200
>> EG> dev.em.0.rx_abs_int_delay: 200
>> EG> dev.em.0.tx_abs_int_delay: 200
>> EG> dev.em.0.rx_processing_limit: 1000
>> ^^^^^мало
>>
>> EG> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
>> EG> от 46% до 49%, загрузка линка тоже немного увеличилась и
>> достигла
>> EG> 24264704 фреймов за 60.145124 секунд, то есть чуть больше
>> 403kpps
>> EG> или 342113668 бит в секунду. Это предел железа?
>>
>> а если еще в loader.conf добавить:
>> hw.em.rxd=4096
>> hw.em.txd=4096
>>
>> а в sysctl.conf
>> net.inet.ip.intr_queue_maxlen=4096
>>
>> и dev.em.0.rx_processing_limit=4096
>> или dev.em.0.rx_processing_limit=-1
>>
>> то какой будет результат?
VD> " - Доктор, больной такой-то скончался.
VD> - Как жаль! У меня ещё столько интересных идей осталось... "
Ну так возможно у EG есть желание и возможности потестить.
У меня есть желание, но нет возможности, машина уже в бою. :(
с такими настройками:
dev.em.0.rx_int_delay: 0
dev.em.0.tx_int_delay: 66
dev.em.0.rx_abs_int_delay: 66
dev.em.0.tx_abs_int_delay: 66
dev.em.0.rx_processing_limit: 4096
em1 анологично.
net.inet.ip.intr_queue_maxlen: 8192
Eugene Grosbein
EG>>>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG>>> Если это важно, на посылателе:
EG>>> # sysctl -a | fgrep msi
EG>>> hw.pci.honor_msi_blacklist: 1
EG>>> hw.pci.enable_msix: 1
EG>>> hw.pci.enable_msi: 1
EG>> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG>> dev.em.0.rx_int_delay: 200
EG>> dev.em.0.tx_int_delay: 200
EG>> dev.em.0.rx_abs_int_delay: 200
EG>> dev.em.0.tx_abs_int_delay: 200
EG>> dev.em.0.rx_processing_limit: 1000
MI> ^^^^^мало
EG>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG>> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG>> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG>> или 342113668 бит в секунду. Это предел железа?
MI> а если еще в loader.conf добавить:
MI> hw.em.rxd=4096
MI> hw.em.txd=4096
MI> а в sysctl.conf
MI> net.inet.ip.intr_queue_maxlen=4096
MI> и dev.em.0.rx_processing_limit=4096
MI> или dev.em.0.rx_processing_limit=-1
MI> то какой будет результат?
Без поллинга со всеми дефолтными системными настройками
плюс твои значения hw.em.rxd/txd плюс intr_queue_maxlen плюс
dev.em.0.rx_processing_limit=-1 штатный драйвер достиг 408kpps.
Увеличив dev.em.0.*_int_delay до 200, получил 409kpps, загрузка
процессора в обоих случаях около 47%. Включив поллинг, получил чуть
более 432kpps.
Eugene
--
Древние врачи умели лечить всё. Они знали даже секрет бессмертия,
но унесли его в могилу, не оставив потомкам.
Eugene Grosbein
EG>>>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG>>> Если это важно, на посылателе:
EG>>> # sysctl -a | fgrep msi
EG>>> hw.pci.honor_msi_blacklist: 1
EG>>> hw.pci.enable_msix: 1
EG>>> hw.pci.enable_msi: 1
EG>> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG>> dev.em.0.rx_int_delay: 200
EG>> dev.em.0.tx_int_delay: 200
EG>> dev.em.0.rx_abs_int_delay: 200
EG>> dev.em.0.tx_abs_int_delay: 200
EG>> dev.em.0.rx_processing_limit: 1000
EG>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG>> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
EG>> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
EG>> или 342113668 бит в секунду. Это предел железа?
VD> 2EG: а ты по листам рассылки смотрел? Там эту тему раз в пару лет
VD> подымают,
VD> и называли цифры то 600, а то и 750 (последнюю - не совсем понятно в каком
VD> контексте).
Да там всё время какие-то страшные Оптероны верхом на огнедышащих материнках.
Hашел очень интересный документ от Intel:
Interrupt Moderation Using Intel Gigabit Ethernet Controllers
http://www.intel.com/design/network/applnots/ap450.htm
Там простым и понятным языком описаны все упомянутые выше sysctl
про delay плюс кое-что ещё. Совместно с RTFS в /usr/src/sys/dev/e1000
ситуация немножко прояснилась. Во-первых, как сказано в if_em.h:
"in the em driver only 82574 uses MSIX", так что моя 82573 пролетает с MSIX.
Во-вторых, в сорцах драйвера жестко зашито значение interrupt throttling:
не более 8000 прерываний в секунду от чипа, но по systat -vm 1
моя система и 4000 не обрабатывает от em.
В третьих, я неправильно считал утилизацию линка. В соответствии с этим
документом от Intel, 64 байта данных UDP на L2 дают не 106, а 130 байт:
- 8 байтов преамбулы и маркера "начало фрейма"
- 14 байт заголовка Ethernet (без тегов)
- 20 байт заголовка IP
- 8 байт заголовка UDP
- 64 байта данных
- 4 байта FCS
- 12 байт межпакетного промежутка
И это уже не треть от гигабита, а больше 449Mbit.
Hо всё равно слишком много CPU тратится на отсылку пакетов,
а это ведь просто заполнение выходной очереди драйвера и перемещение
данных в чип, вроде бы даже никакого форвардинга, не говоря уж о более
высоких уровнях стека типа TCP или даже PPtP.
Что касается 750kpps, то это не более 166 байт на "полный" пакет,
а минус все маркеры начала и конца это 166-8-14-4-12=128 байт
на собственно данные фрейма или 100 байт данных. Вполне может быть.
Eugene
--
Между чудом и случайностью выбирай случайность - она лишь маловероятна,
а чудо невозможно.
Eugene Grosbein
EG> Попробовал потестировать работу FreeBSD 7.1 на гигабите,
EG> причем не стека и не форвардинга, а только самый нижний уровень -
EG> драйвера сетевух.
[skip]
EG> Вопрос: где наиболее вероятное узкое место в посылателе?
Мда... перечитывая сабж: тормоз-то во всей этой истории только один,
и сейчас вы поймете, кто именно... в нём и узкое место...
А вот если УБРАТЬ ИЗ ЯДРА посылателя INVARIANTS - то в поллинге мы сразу
получаем 681505pps, то чуть более 708Mbps в линке.
Eugene
--
Есть еще слова, кроме слова "приказ"
Valentin Davydov
> Date: Thu, 22 Jan 2009 00:06:37 +0300
>
> EG>>>> Вопрос: где наиболее вероятное узкое место в посылателе?
> EG>>> Если это важно, на посылателе:
> EG>>> # sysctl -a | fgrep msi
> EG>>> hw.pci.honor_msi_blacklist: 1
> EG>>> hw.pci.enable_msix: 1
> EG>>> hw.pci.enable_msi: 1
>
> EG>> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
> EG>> dev.em.0.rx_int_delay: 200
> EG>> dev.em.0.tx_int_delay: 200
> EG>> dev.em.0.rx_abs_int_delay: 200
> EG>> dev.em.0.tx_abs_int_delay: 200
> EG>> dev.em.0.rx_processing_limit: 1000
>
> EG>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
> EG>> от 46% до 49%, загрузка линка тоже немного увеличилась и достигла
> EG>> 24264704 фреймов за 60.145124 секунд, то есть чуть больше 403kpps
> EG>> или 342113668 бит в секунду. Это предел железа?
>
> VD> 2EG: а ты по листам рассылки смотрел? Там эту тему раз в пару лет
> VD> подымают,
> VD> и называли цифры то 600, а то и 750 (последнюю - не совсем понятно в каком
> VD> контексте).
>
>Да там всё время какие-то страшные Оптероны верхом на огнедышащих материнках.
Так может в этом и дело? Hу, там, шина, сев.мост и т.д. - ведь каждый из
них свою латентность и т.п. привносит.
Вал. Дав.
Max Irgiznov
21 янв 09 22:51, you wrote to me:
EG>>>>> Вопрос: где наиболее вероятное узкое место в посылателе?
EG>>>> Если это важно, на посылателе:
EG>>>> # sysctl -a | fgrep msi
EG>>>> hw.pci.honor_msi_blacklist: 1
EG>>>> hw.pci.enable_msix: 1
EG>>>> hw.pci.enable_msi: 1
EG>>> Увеличил втрое (с 66 до 200) ещё вот эти sysctl:
EG>>> dev.em.0.rx_int_delay: 200
EG>>> dev.em.0.tx_int_delay: 200
EG>>> dev.em.0.rx_abs_int_delay: 200
EG>>> dev.em.0.tx_abs_int_delay: 200
EG>>> dev.em.0.rx_processing_limit: 1000
MI>> ^^^^^мало
EG>>> Загрузка CPU посылателя увеличилась на 2-3 процента, колебалась
EG>>> от 46% до 49%, загрузка линка тоже немного увеличилась и
EG>>> достигла 24264704 фреймов за 60.145124 секунд, то есть чуть
EG>>> больше 403kpps или 342113668 бит в секунду. Это предел железа?
MI>> а если еще в loader.conf добавить:
MI>> hw.em.rxd=4096
MI>> hw.em.txd=4096
MI>> а в sysctl.conf
MI>> net.inet.ip.intr_queue_maxlen=4096
MI>> и dev.em.0.rx_processing_limit=4096
MI>> или dev.em.0.rx_processing_limit=-1
MI>> то какой будет результат?
EG> Без поллинга со всеми дефолтными системными настройками
EG> плюс твои значения hw.em.rxd/txd плюс intr_queue_maxlen плюс
EG> dev.em.0.rx_processing_limit=-1 штатный драйвер достиг 408kpps.
EG> Увеличив dev.em.0.*_int_delay до 200, получил 409kpps, загрузка
EG> процессора в обоих случаях около 47%. Включив поллинг, получил чуть
EG> более 432kpps.
Спасибо.
Все же результат интересный. я в боевом режиме сколько не пробовал, поллинг
давал отрицательный результат, увеличивая задержки и снижая сумарную полосу.
PS результат с отключенной отладкой впечатляет.
Eugene Grosbein
VD> 2EG: а ты по листам рассылки смотрел? Там эту тему раз в пару лет
VD> подымают,
VD> и называли цифры то 600, а то и 750 (последнюю - не совсем понятно в каком
VD> контексте).
Стабильно 742Kpps я научился получать, иногда всплески чуть больше.
Hо это только в режиме поллинга, потому что одно ядро получается загружено
полностью и в режиме прерываний переключения контекста сьедают
производительность.
1) Читаем man polling. По дефолту параметры поллинга заточены
под 100Mbit, для гигабита их надо поменять. Грубо говоря, при использовании
поллинга каждый тик таймера (с частотой HZ) драйвер получает возможность
послать/принять из железа определенное количество пакетов, не более
чем HZ*kern.polling.burst_max, причем для увеличения burst_max в ядре
прописан жесткий предел в 1000. Без увеличения HZ достигнуть 700Kpps
на своем железе я не смог, а 750Kpps только при HZ=4000.
Пишем в /boot/loader.conf:
kern.hz=4000
Для тестового потока через один интерфейс:
sysctl kern.polling.each_burst=1000
sysctl kern.polling.burst_max=1000
2) Hастраиваем драйвер сетевой карты.
Каждый такой драйвер в FreeBSD имеет очередь (FIFO), в которую верхние
слои сетевого стека складывают пакеты, из неё данные прямиком идут в чип
сетевой карты. Если места в этой FIFO нет, пакеты остаются в буферах стека,
ожидая, пока железо разгребет очередь. Для уменьшения задержек можно
увеличить размер этой очереди. По умолчанию в драйвере em он равен
256 пакетам, для большинства обслуживаемых драйвером em сетевых он может
быть увеличен до 4096 (кроме чипов 82542 и 82543 - максимум 256)
через /boot/loader.conf, отдельно для приёма и передачи:
hw.em.rxd=4096
hw.em.txd=4096
Бесплатно ничего не бывает, и каждый элемент очереди состоит из дескриптора
в 16 байт, а для приемной очереди ещё и из буфера - с учетом того,
что максимальный MTU равен 16110 байт. Так что такая приёмная очередь
может занять почти 64Mb ядерной памяти под буфера.
А в стеке IP есть ещё ограничение net.inet.ip.intr_queue_maxlen,
максимальаня длина приёмной очереди, при переполнении которой стек
дропает входящие пакеты, по дефолту 50, можно тоже увеличить до 4096.
3) Собственно простейший бенчмарк на основе ng_source:
#!/bin/sh
stop_and_show() {
ngctl msg em0:orphans stop
ngctl msg em0:orphans getstats
ngctl shutdown em0:orphans
}
trap "stop_and_show; exit 1" SIGINT SIGTERM
ngctl mkpeer em0: source orphans output
nghook em0:orphans input < packet.cap
ngctl msg em0:orphans start 100000000
sleep 60
stop_and_show
#EOF
Для его работы надо изготовить IP-пакет, который будет посылаться непрерывно
в течение теста и положить в packet.cap (со всеми заголовками IP).
Запускаем: ./bench, ждем 60 секунд (можно прервать раньше по Ctrl-C)
и видим приблизительно следующее:
nghook: EOF(stdin)
Rec'd response "getstats" (1) from "[73]:":
Args: { outOctets=4736425984 outFrames=44683264 queueOctets=106
queueFrames=1 startTime={ tv_sec=1232569999 tv_usec=871790 } endTime={
tv_sec=1232570060 tv_usec=62699 } elapsedTime={ tv_sec=60 tv_usec=190909 }
lastTime={ tv_sec=1232569999 tv_usec=871790 } }
Берем значение outFrames - сколько фреймов успели послать и делим
на прошедшее время elapsedTime: 44683264/60.190909 = 742359pps, или 772Mbps.
Eugene
--
Hаши предки умели всё. Потом забыли.
Vadim Goncharov
On Tue, 20 Jan 2009 01:09:22 +0300; Eugene Grosbein wrote about 'гигабит и тормоза':
e> в секунду, загрузив линк только на треть. При этом приёмник своей
e> сетевухой принял более 99.5% отправленных посылателем пакетов - количество
e> отправленных показал сам ng_source, количество принятых показал ipfw,
e> при этом одно ядро приёмника было загружено не более чем на 40%
e> обработкой прерываний (ядро GENERIC).
ipfw-то убери, почем зря ест, а показать счетчики может и netstat.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Eugene Grosbein
e>> в секунду, загрузив линк только на треть. При этом приёмник своей
e>> сетевухой принял более 99.5% отправленных посылателем пакетов - количество
e>> отправленных показал сам ng_source, количество принятых показал ipfw,
e>> при этом одно ядро приёмника было загружено не более чем на 40%
e>> обработкой прерываний (ядро GENERIC).
VG> ipfw-то убери, почем зря ест
Считает первое правило - без подгрузки ipfw.ko сравнивал,
заметной разницы на 400kpps не было, больше 700kpps приемник уже с ipfw
не тянет, но за его оптимизацию ещё не брался.
Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.
Mike Yurlov
"Eugene Grosbein" <Eugene....@f1.n5006.z2.fidonet.org> сообщил
следующее:
> Каждый такой драйвер в FreeBSD имеет очередь (FIFO), в которую верхние
> слои сетевого стека складывают пакеты, из неё данные прямиком идут в чип
> сетевой карты. Если места в этой FIFO нет, пакеты остаются в буферах
> стека,
> ожидая, пока железо разгребет очередь. Для уменьшения задержек можно
> увеличить размер этой очереди. По умолчанию в драйвере em он равен
> 256 пакетам, для большинства обслуживаемых драйвером em сетевых он может
> быть увеличен до 4096 (кроме чипов 82542 и 82543 - максимум 256)
какие есть способы определения этого "большинства" удаленно софтово
(доступен
только ssh, машина находится на произвольном удалении в n км в
труднодоступном
месте и не подлежит остановке). Hагугливал что линуксы вроде какой-то софт
есть, а под эхотаг?
Если не удаленно софтово, то ладно, как из номера чипа? Даташит на чип
листать?
WBR, UMike
Eugene Grosbein
MY> какие есть способы определения этого "большинства" удаленно софтово
Пожалуй, RTFS драйвера сетевой.
Eugene
--
WallJam7: roses are red
WallJam7: violets are blue
WallJam7: all of my base
WallJam7: are belong to you // www.bash.org.
Vadim Goncharov
On Thu, 22 Jan 2009 19:41:46 +0300; Eugene Grosbein wrote about 'Re: гигабит и тормоза':
e>>> в секунду, загрузив линк только на треть. При этом приёмник своей
e>>> сетевухой принял более 99.5% отправленных посылателем пакетов - количество
e>>> отправленных показал сам ng_source, количество принятых показал ipfw,
e>>> при этом одно ядро приёмника было загружено не более чем на 40%
e>>> обработкой прерываний (ядро GENERIC).
VG>> ipfw-то убери, почем зря ест
e> Считает первое правило - без подгрузки ipfw.ko сравнивал,
e> заметной разницы на 400kpps не было, больше 700kpps приемник уже с ipfw
e> не тянет, но за его оптимизацию ещё не брался.
Hе, просто заявлешь, что тестишь чистые драйвера, а это совсем не так, даже
если ipfw выкинуть - оно ж в IP-стек поступает-то.
Eugene Grosbein
e>>>> отправленных показал сам ng_source, количество принятых показал ipfw,
e>>>> при этом одно ядро приёмника было загружено не более чем на 40%
e>>>> обработкой прерываний (ядро GENERIC).
VG>>> ipfw-то убери, почем зря ест
e>> Считает первое правило - без подгрузки ipfw.ko сравнивал,
e>> заметной разницы на 400kpps не было, больше 700kpps приемник уже с ipfw
e>> не тянет, но за его оптимизацию ещё не брался.
VG> Hе, просто заявлешь, что тестишь чистые драйвера, а это совсем не так,
Именно так. Я пока тестил только посылание, ng_source кладет пакеты
непосредственно в FIFO драйвера сетевой.
VG> даже если ipfw выкинуть - оно ж в IP-стек поступает-то.
Приём отдельная тема.
Eugene
--
Что делают там, где воруют и сам царь, и его советник, и главный жрец? (Артха)
Eugene Grosbein
MI> PS результат с отключенной отладкой впечатляет.
И всё-таки я не понимаю, почему работа ng_source+polling+em(4)
жрет 45% CPU на прерываниях для >740kpps, куда там уходит столько CPU?..
Киньте кто-нибудь ссылку по профилированию ядра вообще или
netgraph в частности?
Anton Yuzhaninov
EG>
EG> Киньте кто-нибудь ссылку по профилированию ядра вообще или
EG> netgraph в частности?
EG>
Профилировать ядро можно так:
1. Собираешь ядро с
device hwpmc
options HWPMC_HOOKS
2.
pmcstat -S instructions -c0 -O ppp.out
дать нагрузку, немного подождать, нажать ctrl+c
pmcstat -R ppp.out -k /boot/kernel/kernel -g
gprof -l /boot/kernel/kernel k8-fr-retired-x86-instructions/kernel.gmon | less
--
Anton Yuzhaninov
Vadim Goncharov
On Sat, 24 Jan 2009 04:23:40 +0300; Eugene Grosbein wrote about 'Re: гигабит и тормоза':
MI>> PS результат с отключенной отладкой впечатляет.
e> И всё-таки я не понимаю, почему работа ng_source+polling+em(4)
e> жрет 45% CPU на прерываниях для >740kpps, куда там уходит столько CPU?..
e> Киньте кто-нибудь ссылку по профилированию ядра вообще или
e> netgraph в частности?
http://freebsd.rambler.ru - ищешь по "sixty second hwpmc howto"
Только оно хочет, чтоб бло вкомпилировано в ядро, а не модулями, иначе не
сможет определить, чьи функции вызывались.
Eugene Grosbein
EG>> Киньте кто-нибудь ссылку по профилированию ядра вообще или
EG>> netgraph в частности?
AY> Профилировать ядро можно так:
AY> 1. Собираешь ядро с
AY> device hwpmc
AY> options HWPMC_HOOKS
AY> 2.
AY> pmcstat -S instructions -c0 -O ppp.out
AY> дать нагрузку, немного подождать, нажать ctrl+c
AY> pmcstat -R ppp.out -k /boot/kernel/kernel -g
AY> gprof -l /boot/kernel/kernel k8-fr-retired-x86-instructions/kernel.gmon |
AY> less
[root@grosbein ~/pmc/p4-instr-retired]# gprof -l kernel.gmon
gprof: kernel.gmon: bad format
Eugene
--
Choose no friends