дрова Yandex

[pavlabor 1 914]

Уровневая структура пакета, подразумевает инкапсуляцию данных.

В связи с этим, любое передающее устройство должно полностю подготовить пакет к транспорту на езернет уровне.

Никто не знает кто будет принимать пакет на другой стороне.

Поетому все должно быть предсказуемо, то есть согласно протокола.

 

Писюк, это один из приемников, который ОБЯЗАН, разбуть пакет чтобы обработать.

В зависимости от задачи, производится распаковывания пакета.

для тупого роута, а писюк можно настроить и так, разбувается только езернет уровень,

а скажем для прокси, он разбирается еще больше.

 

То есть это не есть вопрос.

 

Вот обратил внимание на такую инфу, карточка вроде деловская

http://torg.od.ua/index.php?productID=146

 

Что тут интересного не считая перечисления того что я ненашол в карточке?

Во!

Support caches up to 64 packets descriptors per queue

 

Двухголовая карточка...

Зачем ей кеш на 64 дескриптора?

Есть идеи?

 

Разработчики пошли довольно стремным путем для разгона.

Лично я ожидал, учитывая выше приведеную опцию, что разгон пойдет по технологии анализа заголовков, построения фабрики коммутации на базе сетевой карты,

и прямого управления регистрами этой фабрики коммутации.

И в таком случае кеш необходим, потому что пакет был скомутирован сетевой картой с порта в порт,

а дескриптор помещен а очередь для дальнейшей обработки процом.

По такой технологии работает цыска, да и все коммутаторы выше второго уровня.

 

Но возможно текущая метода разгона трафика на писюках и принесет свои плюсы, время покажет.

[KaYot 3 605]

Уровневая структура пакета, подразумевает инкапсуляцию данных.

В связи с этим, любое передающее устройство должно полностю подготовить пакет к транспорту на езернет уровне.

Никто не знает кто будет принимать пакет на другой стороне.

Поетому все должно быть предсказуемо, то есть согласно протокола.

 

Писюк, это один из приемников, который ОБЯЗАН, разбуть пакет чтобы обработать.

В зависимости от задачи, производится распаковывания пакета.

для тупого роута, а писюк можно настроить и так, разбувается только езернет уровень,

а скажем для прокси, он разбирается еще больше.

 

То есть это не есть вопрос.

 

Вот обратил внимание на такую инфу, карточка вроде деловская

http://torg.od.ua/index.php?productID=146

 

Что тут интересного не считая перечисления того что я ненашол в карточке?

Во!

Support caches up to 64 packets descriptors per queue

 

Двухголовая карточка...

Зачем ей кеш на 64 дескриптора?

Есть идеи?

 

Разработчики пошли довольно стремным путем для разгона.

Лично я ожидал, учитывая выше приведеную опцию, что разгон пойдет по технологии анализа заголовков, построения фабрики коммутации на базе сетевой карты,

и прямого управления регистрами этой фабрики коммутации.

И в таком случае кеш необходим, потому что пакет был скомутирован сетевой картой с порта в порт,

а дескриптор помещен а очередь для дальнейшей обработки процом.

По такой технологии работает цыска, да и все коммутаторы выше второго уровня.

 

Но возможно текущая метода разгона трафика на писюках и принесет свои плюсы, время покажет.

Какая фабрика коммутации, какие разгоны, зачем все это на сетевке?? Как-то вас из крайности в крайность кидает.. Есть сегодняшние вполне рабочие сетевые чипы, легко пропускающие положенные 1 или 10Г. Под linux и дрова совершенно стабильные и красивые, с bsd попозжее видимо тоже все красиво будет.

[pavlabor 1 914]

Какая фабрика коммутации, какие разгоны, зачем все это на сетевке?? Как-то вас из крайности в крайность кидает.. Есть сегодняшние вполне рабочие сетевые чипы, легко пропускающие положенные 1 или 10Г. Под linux и дрова совершенно стабильные и красивые, с bsd попозжее видимо тоже все красиво будет.

 

Меня интересует не сегодня, а завтра.

 

Сори если чем обидел.

Удачи.

[adeep 212]

Уровневая структура пакета, подразумевает инкапсуляцию данных.

В связи с этим, любое передающее устройство должно полностю подготовить пакет к транспорту на езернет уровне.

Никто не знает кто будет принимать пакет на другой стороне.

Поетому все должно быть предсказуемо, то есть согласно протокола.

свич этим не занимается.

 

для тупого роута, а писюк можно настроить и так, разбувается только езернет уровень,

а скажем для прокси, он разбирается еще больше.

причем тут прокси? вопрос идет о маршрутизации

 

Лично я ожидал, учитывая выше приведеную опцию, что разгон пойдет по технологии анализа заголовков, построения фабрики коммутации на базе сетевой карты,

и прямого управления регистрами этой фабрики коммутации.

И в таком случае кеш необходим, потому что пакет был скомутирован сетевой картой с порта в порт,

а дескриптор помещен а очередь для дальнейшей обработки процом.

По такой технологии работает цыска, да и все коммутаторы выше второго уровня.

есть такие сетевушки. только стоимость их на текущий момент порядка 1k$ за гиговый порт. вы готовы платить такие суммы?

[pavlabor 1 914]

Opteron 6100 and Xeon 5600 series have different memory controller architectures. For best performance, you have to populate DIMMs in groups of 8 on a 2-processsor Opteron 6100 series server, while you have to populate DIMMs in groups of 6 on a 2-processor Xeon 5600 series server.

 

I ran the test in this video with 8x2GB in the AMD server, and 6x4GB in the Intel. I re-ran the test with 8x4GB in the AMD server and got about the same result (33,900 MB/s on the AMD).

 

 

Вот такая сказка...

http://www.amd.com/us/products/server/processors/six-core-opteron/Pages/six-core-processors-with-amd-chipset.aspx

http://market.yandex.ua/model.xml?hid=91020&modelid=6325035

http://cgi.ebay.com/TYAN-S8812WGM3NR-AMD-SP5100-AMD-SR5690-DDR3-DIMM-/300516937042?pt=LH_DefaultDomain_0&hash=item45f8348d52

 

http://www.overclockers.ru/hardnews/36648/AMD_predstavlyaet_processory_Opteron_61xx.html

[adeep 212]

Вот такая сказка...

Эксперимент неадекватен. Как минимум конфигурацией памяти, которую собственно тестируют.

[Laa 0]

У меня freebsd 8.2 amd64 на core i5 4G ram, на этой машине были две сетевушки:

 

Mar  5 07:12:37 billing kernel: em0: <Intel(R) PRO/1000 Network Connection 7.1.9> port 0xdc00-0xdc1f mem 0xeffe0000-0xefffffff,0xeffc0000-0xeffdffff irq 16 at device 0.0 on pci3
Mar  5 07:12:37 billing kernel: em0: Using an MSI interrupt
Mar  5 07:12:37 billing kernel: em0: [FILTER]
...
Mar  5 07:12:37 billing kernel: em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xec00-0xec3f mem 0xf7fe0000-0xf7ffffff,0xf7fc0000-0xf7fdffff irq 16 at device 1.0 on pci5
Mar  5 07:12:37 billing kernel: em1: [FILTER]

 

накрутил net.isr и тд чтобы как-то разрулить нагрузку по ядрам. Разруливалось неплохо в принципе. Но потом появилась одна карточка ET dual port server adapter на два порта.

 

Выглядит так:

Mar 12 06:17:46 billing kernel: igb0: <Intel(R) PRO/1000 Network Connection version - 2.0.7> port 0xd880-0xd89f mem 0xf3da0000-0xf3dbffff,0xf3400000-0xf37fffff,0xf3dd8000-0xf3ddbfff irq 16 at device 0.0 on pci1
Mar 12 06:17:46 billing kernel: igb0: Using MSIX interrupts with 5 vectors
Mar 12 06:17:46 billing kernel: igb0: [iTHREAD]
Mar 12 06:17:46 billing last message repeated 4 times
Mar 12 06:17:46 billing kernel: igb0: Ethernet address: 00:1b:21:4a:4e:1c
Mar 12 06:17:46 billing kernel: igb1: <Intel(R) PRO/1000 Network Connection version - 2.0.7> port 0xdc00-0xdc1f mem 0xf3de0000-0xf3dfffff,0xf3800000-0xf3bfffff,0xf3ddc000-0xf3ddffff irq 17 at device 0.1 on pci1
Mar 12 06:17:46 billing kernel: igb1: Using MSIX interrupts with 5 vectors
Mar 12 06:17:46 billing kernel: igb1: [iTHREAD]
Mar 12 06:17:46 billing last message repeated 4 times

 

Не в пиковое время на igb0:

# netstat -w1 -h -I igb0
           input         (igb0)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
      25K     0     0        21M        24K     0        16M     0
      24K     0     0        19M        24K     0        16M     0
      25K     0     0        21M        24K     0        15M     0
      25K     0     0        20M        24K     0        15M     0
      24K     0     0        20M        24K     0        16M     0
      25K     0     0        20M        24K     0        16M     0
      23K     0     0        19M        22K     0        14M     0
      25K     0     0        21M        23K     0        15M     0

 

top -SHP показывает:

last pid: 92551;  load averages:  0.25,  0.28,  0.21      up 2+15:13:04  22:13:17
153 processes: 5 running, 122 sleeping, 2 zombie, 24 waiting
CPU 0:  4.9% user,  0.0% nice,  0.0% system, 19.5% interrupt, 75.6% idle
CPU 1:  4.9% user,  0.0% nice,  1.2% system,  2.4% interrupt, 91.5% idle
CPU 2:  2.4% user,  0.0% nice,  1.2% system,  1.2% interrupt, 95.1% idle
CPU 3:  2.4% user,  0.0% nice,  3.7% system,  1.2% interrupt, 92.7% idle
Mem: 472M Active, 1108M Inact, 662M Wired, 572K Cache, 418M Buf, 1711M Free
Swap: 2048M Total, 2048M Free

 PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root     171 ki31     0K    64K CPU2    2  58.9H 97.56% {idle: cpu2}
  11 root     171 ki31     0K    64K RUN     3  59.1H 93.26% {idle: cpu3}
  11 root     171 ki31     0K    64K CPU1    1  58.7H 92.87% {idle: cpu1}
  11 root     171 ki31     0K    64K CPU0    0  51.7H 79.39% {idle: cpu0}
  12 root     -68    -     0K   384K WAIT    0 442:43 16.06% {irq261: igb1:que}
  12 root     -68    -     0K   384K WAIT    0 140:42  4.59% {irq256: igb0:que}
  12 root     -68    -     0K   384K WAIT    1 122:21  3.66% {irq257: igb0:que}
  12 root     -68    -     0K   384K WAIT    2 122:30  3.47% {irq258: igb0:que}
  12 root     -68    -     0K   384K WAIT    3 123:02  3.17% {irq259: igb0:que}
   0 root     -68    0     0K   224K -       1  30:16  0.49% {igb1 que}
   0 root     -68    0     0K   224K -       2  16:59  0.10% {igb0 que}
1594 root      76    0 65844K 28744K select  1   9:02  0.00% {mpd5}
   0 root     -68    0     0K   224K -       1   8:06  0.00% {dummynet}
 929 root      60    0 25784K 19888K select  0   5:16  0.00% zebra
  12 root     -32    -     0K   384K WAIT    2   5:05  0.00% {swi4: clock}
1664 root      44    0 26932K  7468K select  3   5:02  0.00% snmpd
1461 bind      44    0   140M   130M ucond   1   4:03  0.00% {named}
1461 bind      44    0   140M   130M ucond   2   4:03  0.00% {named}
1461 bind      44    0   140M   130M ucond   1   4:02  0.00% {named}
1461 bind      44    0   140M   130M ucond   1   4:02  0.00% {named}

 

Статистика по прерываниям:

# vmstat -i
interrupt                          total       rate
irq1: atkbd0                         375          0
irq0:                                  1          0
stray irq0                             1          0
irq21: atapci2+                  1731836          7
cpu0: timer                    455343656       2000
irq256: igb0:que 0            1723037558       7568
irq257: igb0:que 1             817785911       3591
irq258: igb0:que 2             816455836       3586
irq259: igb0:que 3             827039286       3632
irq260: igb0:link                      3          0
irq261: igb1:que 0            1955252087       8588
irq262: igb1:que 1              11240652         49
irq263: igb1:que 2              10827474         47
irq264: igb1:que 3              15654927         68
irq265: igb1:link                      4          0
cpu1: timer                    455343525       2000
cpu3: timer                    455343524       2000
cpu2: timer                    455343525       2000
Total                         8000400181      35140

 

На igb1 у меня локаль с юзерами - dhcp + pppoe.

 

Из отличий igb1 от em1: по графикам мртг при всем том же пропали ошибки, их было немного, но они были. Правда полета всего несколько дней, но на em1 ошибки были в первый же вечер активной нагрузки, в райное нескольких десятков ошибок. Это при ппс порядка 35 кппс. После установки dual port et визуально по графикам появились ппсы под 50кппс в первый же вечер. Раньше еле до 40кппс доходило в пики за многие месяцы. Но это субъективное мнение.

 

Не нравится на et dual port что второй порт, который раздает pppoe и dhcp не параллелится на все четыре ядра, а только на одном преимущественно. В то же время на выхлопе igb0 не идеально, но параллелится на четыре очереди и по сравнению с em0 (intel pt) все четыре очереди потребляют на этом же железе вроде даже больше %WCPU.

 

Вопросы: где почитать о том как подтюнить сетевушку чтобы нагрузка на портах лучше параллелилась?

 

з.ы. может кому-то что-то по et dual port интересно на фре 8.2 -- спрашивайте, стоит, работает -- могу еще чего рассказать.

[KaYot 3 605]

ET не распараллеливает pppoe трафик(это не IP), можете и не пытаться.

[adeep 212]

Не в пиковое время на igb0:

# netstat -w1 -h -I igb0
           input         (igb0)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
      25K     0     0        21M        24K     0        16M     0

это не нагрузка для этой карты

 

Статистика по прерываниям:

прерываний многовато.

добавьте в /boot/loader.conf

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.enable_aim=0

hw.igb.low_latency=2000

hw.igb.ave_latency=4000

hw.igb.bulk_latency=8000

hw.igb.rx_process_limit=1000

hw.igb.fc_setting=0

станет чуть поменьше.

у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к

 

Не нравится на et dual port что второй порт, который раздает pppoe и dhcp не параллелится на все четыре ядра, а только на одном преимущественно.

это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют.

[jack 25]

прерываний многовато.

добавьте в /boot/loader.conf

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.enable_aim=0

hw.igb.low_latency=2000

hw.igb.ave_latency=4000

hw.igb.bulk_latency=8000

hw.igb.rx_process_limit=1000

hw.igb.fc_setting=0

станет чуть поменьше.

у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к

 

что для ET еще посоветуете подкрутить? или можно понаглеть, и увидеть конфиги?

[adeep 212]

что для ET еще посоветуете подкрутить? или можно понаглеть, и увидеть конфиги?

конкретно относящегося к igb больше ничего, собственно там больше крутить нечего. значения 1000-2000-4000-8000 выбраны эмпирическим путем, на наге где-то даже есть обсуждения и споры по поводу них, но работает)

[Laa 0]

Не в пиковое время на igb0:

# netstat -w1 -h -I igb0
           input         (igb0)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
      25K     0     0        21M        24K     0        16M     0

это не нагрузка для этой карты

 

Дык знаю. Пока на том сервере в пики до 50кппс доходит, но лучше пусть серверок с запасом будет работать, чем на пределе.

 

Статистика по прерываниям:

прерываний многовато.

добавьте в /boot/loader.conf

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.enable_aim=0

hw.igb.low_latency=2000

hw.igb.ave_latency=4000

hw.igb.bulk_latency=8000

hw.igb.rx_process_limit=1000

hw.igb.fc_setting=0

станет чуть поменьше.

у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к

ok. сперва почитаю в if_igb.c об этом, потом решу добавлять или нет и сколько.

Спасибо.

А вот такой вопрос, sysctl -a не показывает в своем выводе hw.igb.rxd и кое-что еще, хочу понять, установка таки повлияет на что-то? Обычно то, что в loader.conf все показывает sysctl. Может этих переменных и нет в ядре и установка их ничего не изменит?

 

Не нравится на et dual port что второй порт, который раздает pppoe и dhcp не параллелится на все четыре ядра, а только на одном преимущественно.

это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют.

ну я это и подозревал.

[Laa 0]

...

прерываний многовато.

добавьте в /boot/loader.conf

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.enable_aim=0

hw.igb.low_latency=2000

hw.igb.ave_latency=4000

hw.igb.bulk_latency=8000

hw.igb.rx_process_limit=1000

hw.igb.fc_setting=0

станет чуть поменьше.

у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к

..

А что за переменные:

hw.igb.low_latency=2000
hw.igb.ave_latency=4000
hw.igb.bulk_latency=8000

??? Я их в исходниках драйвера не нашел, в выводе sysctl -a тоже нет. Где о них почитать?

[adeep 212]

А что за переменные:

hw.igb.low_latency=2000
hw.igb.ave_latency=4000
hw.igb.bulk_latency=8000

??? Я их в исходниках драйвера не нашел, в выводе sysctl -a тоже нет. Где о них почитать?

хм. действительно... похоже их убрали в последних драйверах. так что можно их убрать из рассмотрения. у меня они просто кочевали долго из системы в систему, когда-то были актуальны.

 

Однако при указанных строчках имеем 5к прерываний.

включаем

sysctl dev.igb.0.enable_aim=1

 

и имеем 8-9к прерываний.

выключаем

 

sysctl dev.igb.0.enable_aim=0

 

и получаем вообще волшебство:

22092 igb0:que 0

[Laa 0]

Спасибо.

 

Поставил у себя на лету dev.igb.1.enable_aim=0 и dev.igb.0.enable_aim=0 и судя по top -SHP стало постепенно становится меньше нагрузки в WCPU. Ну то есть, {irq261: igb1:que} при значении 1 было больше 8%, а при значении 0 стало около 7%. В это время на igb1 была пппое нагрузка + dhcp в районе 18-22кппс.

 

Решил оставить = 0 и понаблюдать в пиковое время что будет.

[pavlabor 1 914]

прерываний многовато.

добавьте в /boot/loader.conf

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.enable_aim=0

hw.igb.low_latency=2000

hw.igb.ave_latency=4000

hw.igb.bulk_latency=8000

hw.igb.rx_process_limit=1000

hw.igb.fc_setting=0

станет чуть поменьше.

у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к

 

что для ET еще посоветуете подкрутить? или можно понаглеть, и увидеть конфиги?

 

man igb

В зависимости от версии драйвера, расписывает возможные регулировки, помещается в /boot/loader.conf

 

В /etc/sysctl.conf, помещаются общие настройки для системы

немного тут можно почитать

http://dadv.livejournal.com/49013.html

http://nix-sa.blogspot.com/2010/12/sysctl.html

 

Еще подсказку можно получить так

# sysctl -d dev.igb.0.enable_aim

dev.igb.0.enable_aim: Interrupt Moderation

[adeep 212]

http://dadv.livejournal.com/49013.html

http://nix-sa.blogspot.com/2010/12/sysctl.html

надо не забывать только что у сысоева оптимизация больше под сервер приложений (веб), а не под роутер. тут скорее wawa надо пытать

[Laa 0]

На сайте Интела еще в феврале появились драйвера для igb версии 2.0.8, кто знает что в них нового? А-то на сайте и в архиве нету changelog-а. Может кто-то тут юзал уже в тестах их?

[natiss 16]

это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют.

а как жеш IPv6 ?

[KaYot 3 605]

это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют.

а как жеш IPv6 ?

А он у вас в ОГОшном модеме используется?)

[adeep 212]

а как жеш IPv6 ?

это кстати вопрос интересный. можно попробовать задать интеловцам.

[natiss 16]

это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют.

а как жеш IPv6 ?

А он у вас в ОГОшном модеме используется?)

Да, используется! И вам рекомендую

[KaYot 3 605]

а как жеш IPv6 ?

это кстати вопрос интересный. можно попробовать задать интеловцам.

В даташите на боард заявлены все те же оффлоады/чексумы и RSS для IPv4/IPv6 TCP/UDP.

[natiss 16]

В даташите на боард заявлены все те же оффлоады/чексумы и RSS для IPv4/IPv6 TCP/UDP.

А MSI-X ? собственно

[adeep 212]

А MSI-X ? собственно

а вы мне объясните чем rss от msi-x по сути отличается?)

имхо в данном случае rss это как раз то, что распихивает пакеты в очереди msi-x