Помогите выжать гигабит из Intel 82541GI

[s.lobanov]

В целях тестирования коммутаторов, нужно сгенерить и принять трафик ~1гбит.

 

Имеется 2 сервера с сетевой карточкой Intel 82541GI, соединил их патчкордом, запускаю iperf сервер и клиент, получаю 868 мбит/с(tcp), по udp немного меньше. Хочется получить ~1гбит/с

 

ethtool говорит, что flow-control делает своё грязное дело:

 

# ethtool -S eth1 | grep flow

rx_flow_control_xon: 908

rx_flow_control_xoff: 908

tx_flow_control_xon: 8393961

tx_flow_control_xoff: 8394042

 

Отключил flow control на обоих серверах:

# ethtool -a eth1

Pause parameters for eth1:

Autonegotiate: off

RX: off

TX: off

 

счётчики flow-control больше не растут, скорость стала чуть меньше - 848мбит(tcp) и появились дропы:

# ifconfig eth1

eth1 Link encap:Ethernet HWaddr 00:15:C5:5D:79:1B

inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::215:c5ff:fe5d:791b/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:18596995 errors:0 dropped:194 overruns:0 frame:0

TX packets:10089840 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10000

RX bytes:25946366654 (24744.3 Mb) TX bytes:7811726942 (7449.8 Mb)

 

До выключения flow-contol дропов не было.

 

Сервера одинаковые, линуксы на них разные: 2.6.27.19-5-pae и 2.6.32.43-0.4 x86_64

# lspci | grep -i eth

02:04.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

 

# modinfo e1000 | grep version

version: 7.3.21-k5-NAPI

srcversion: 97D091079A6192E2599020D

vermagic: 2.6.32.43-0.4-default SMP mod_unload modversions

 

и

# modinfo e1000 | grep version

version: 7.3.21-k3-NAPI

srcversion: C6E401D1B1A22E86974265F

vermagic: 2.6.27.19-5-pae SMP mod_unload modversions 586

 

Что можно сделать, чтобы всё-таки выжать гигабит?

[0pl0pl]

Изменяя модулей ( http://e1000.sf.net ) и оптимизация Linux Вы можете делать - ~940Mbps.

Если Вы все еще должны быть около 1 Гбит - использовать LACP (802.3ad) с 2 сетевые карты на каждом сервере.

 

Обзор и http://www.maxgigapop.net/twiki/bin/view/MAX/PerformanceTuning

Edited August 5, 2011 by 0pl0pl

[s.lobanov]

Ровно гиг мне не надо. 940 вполне хватит. За ссылку спасибо.

[s.lobanov]

Обновил e1000 до 8.0.30-NAPI на обоих серверах - не помогает, любые другие тюнинги из статьи тоже не помогают :(

 

Выкручивание MTU до 9000 даёт скорость 990Мбит/с, но этот случай мне не интересен, т.к. коммутаторы, которые мне нужно протестить имеют максимальный MTU ~2000

 

На MTU 1500 по-прежнему либо flow-control, либо дропы(при отключенном flow-control)

 

И ещё вопрос, dropped в ifconfig - где собственно происходит сам drop - на сетевой карточке или на уровне ОС?

[vitalyb]

прерывание карточки на одно ядро прибито?

[s.lobanov]

vitalyb, да

[Zaqwr]

что за мать? что за проц? что крутили в sysctl?

[s.lobanov]

Сервер http://support.dell.com/support/edocs/systems/SC1425/en/ug/f3593aa0.htm

Чипсет E7520

# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 4

model name : Intel® Xeon™ CPU 3.20GHz

stepping : 10

cpu MHz : 3200.071

cache size : 2048 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 1

apicid : 0

initial apicid : 0

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 5

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2m

bogomips : 6400.14

clflush size : 64

power management:

 

processor : 1

... тоже самое что и processor 0

 

В sysctl поставил

### CORE settings (mostly for socket and UDP effect)

# maximum receive socket buffer size, default 131071

net.core.rmem_max = 75000000

# maximum send socket buffer size, default 131071

net.core.wmem_max = 75000000

# default receive socket buffer size, default 65535

net.core.rmem_default = 2524287

# default send socket buffer size, default 65535

net.core.wmem_default = 2524287

# maximum amount of option memory buffers, default 10240

net.core.optmem_max = 2524287

# number of unprocessed input packets before kernel starts dropping them, default 300

net.core.netdev_max_backlog = 300000

 

 

### IPV4 specific settings

# turns TCP timestamp support off, default 1, reduces CPU use

net.ipv4.tcp_timestamps = 0

# turn SACK support off, default on -- you probably only want to do this at 10GigE

#net.ipv4.tcp_sack = 0

# on systems with a VERY fast bus -> memory interface this is the big gainer

# sets min/default/max TCP read buffer, default 4096 87380 174760

# setting to 100M - 10M is too small for cross country (chsmall)

net.ipv4.tcp_rmem = 150000000 150000000 150000000

# sets min/pressure/max TCP write buffer, default 4096 16384 131072

net.ipv4.tcp_wmem = 150000000 150000000 150000000

# sets min/pressure/max TCP buffer space, default 31744 32256 32768

net.ipv4.tcp_mem = 150000000 150000000 150000000

 

но эти настройки sysctl ничего не изменили

 

ethtool -G eth1 rx 4096 tx 4096 тоже не помогает

[Ilya Evseev]

Увеличение размера пакетов в iperf помогает?

С какими аргументами он запускается?

[s.lobanov]

Увеличение размера пакетов в iperf помогает?

С какими аргументами он запускается?

 

Да, как я уже написал выше, при увеличении MTU до 9000 скорость поднимается до 990мбит/с, но, повторяюсь, этот случай мне не очень интересен.

 

iperf запускал и с большим размером окна и с большим udp-буфером, не в этом сейчас дело(см. ниже)

 

Обновление ядра до ванильного 2.6.39.4 значительно улучшило ситуацию, удалось добиться скорости 930мбит/с при MTU 1500 и включенном flow-control, но проблема по-прежнему сохраняется - либо возникает rx_missed_errors, либо tx_flow_control_* на "принимающей" стороне.

 

e1000 теперь 7.3.21-k8-NAPI(модулем)

 

Сейчас собираю ядро 3.0.1, но вряд ли там большая разница по сравнению с 2.6.39.

 

Кстати, iperf ведёт себя неадекватно(на сервере и клиенте показывает разные скорости), теперь использую nuttcp, очень удобная вещь оказалось, на порядок лучше iperf.

[x86]

IMHO, тестировать нужно исключительно в UDP.

Я для этих целей использовал netperf.

Получил 964+957, но карточки были не Intel.

 

rx_missed_errors свидетельствует о том, что пакеты не помещаются в буфер, а не помещаются потому, что процессор не успевает их оттуда выгребать - что весьма странно при большом размере пакета.

Edited August 6, 2011 by x86

[s.lobanov]

От ядра 3.0.1 ничего не улучшилось + на нём не собирает e1000 8.0.30(править makefile лень)

 

На ядре 2.6.39 помогло

ethtool -C eth1 rx-usecs 2700

 

C этой опцией на tcp удалось выжать 949мбит, при этом ни одного drop'а или flow-control'я, т.е. как бы максимум

 

На udp пока только 870мбит, вероятно с sysctl перестарался.

[Zaqwr]

HZ в ядре сколько? увеличить надобы скажем тыщ до 3-х 6-ти

[_dx]

Вседа думал, что на сервере такие большие значения не только не нужны, но ещё и вредны...

Чем объясняется необходиомсть такого повышния частоты? Не внесет ли это больше оверхеда, чем пользы??

[Zaqwr]

не утверждаю что будет польза, но можно предположить, что будет быстрее данные выгребать из буферов сетевух, по старому опыту, HZ=1000 поднимало производительность софтроутера под freebsd(ipfw dummynet)

[_dx]

Ну с 1000 я ещё могу согласиться. Но 3 - 6...

Интересно мнение более опытных коллег.

[nuclearcat]

Это в FreeBSD на HZ и пуллинг простите передергивают.

 

В линуксе давно tickless/NOHZ + NAPI. HZ конечно влияет еще на некоторые операции, но уже не так сильно.

[Ivan_83]

HZ это частота переключения потоков планировщиком, соответственно и величина кванта времени отводимого потоку. Поллинг во фряхе сейчас по умолчанию не используется. На многопроцессорных системах которые занимаются ограниченным кругом задачь, ИМХО не разумно увеличивать HZ.

 

Как обычно, критерий истинности - эксперимент.

 

 

[wtyd]

От ядра 3.0.1 ничего не улучшилось + на нём не собирает e1000 8.0.30(править makefile лень)

 

На ядре 2.6.39 помогло

ethtool -C eth1 rx-usecs 2700

 

C этой опцией на tcp удалось выжать 949мбит, при этом ни одного drop'а или flow-control'я, т.е. как бы максимум

 

На udp пока только 870мбит, вероятно с sysctl перестарался.

 

Если тестировать на 100 мегабит, то у меня iperf никогда не показывал 100, точнее всегда показывал 94 мегабита. По аналогии 940 мегабит наверное хороший результат :-). Про UDP не помню, сколько было.

[s.lobanov]

Если тестировать на 100 мегабит, то у меня iperf никогда не показывал 100, точнее всегда показывал 94 мегабита. По аналогии 940 мегабит наверное хороший результат :-). Про UDP не помню, сколько было.

 

mtu загните по-максимуму и будет больше 94мбит. только проблема в том, что не все FE-свитчи поддерживают jumbo frame, не говоря уж про сетевые карты.