какой проц Core i7-980 или i7-2600K лучше для обработки прерываний от сетевухи E1G44

[NEP 217]

Ну "идиоты" эти ребята из Интел, вот бы кайот с нитро их поучили собирать маршрутизаторы:

http://download.intel.com/embedded/applications/networksecurity/323814.pdf

 

C

onfiguration details for 50 percent lower idle power: Intel internal measurements of 221w at idle with Supermicro 2xe5450 (3.0ghz 80w) processors, 8x2gb 667Mhz FbDIMMs,

1

1x700w PSU, 1x320gb SaTa hard drive vs. 111w at idle with Supermicro software development platform with 2xe5540 (2.53ghz Nehalem 80w) processors, 6x2gb DDr3-1066

rDIMMs, 1x800w PSU, 1x150gb 10k SaTa hard drive. both systems were running windows* 2008 with USb suspend select enabled and maximum power savings mode for

PCIe* link state power management. Measurements as of February 2009.

Теперь точно последний

У вас или очень плохо с английским(так на кой кидать ссылки на англоязыную документацию?), или просто отсутствует мозг. Ну черным по белому написано, типовые конфигурации для сравнения энергопотребления систем с разными поколениями ксеонов.. 8х2 и 6х2 для максимально близкого объема RAM на платформах с разным числом каналов. При чем тут роутеры и ваши фобии??

 

 

Помоему это у вас проблемы с чтением технической литературы на любом языке. Table 1. Data Plane Performance Measurements (∆ is projected)

[NEP 217]

Ну "идиоты":

http://www.cisco.com/en/US/docs/routers/access/2900/hardware/installation/guide/Overview.html

 

DRAM—Stores the running configuration and routing tables and is used for packet buffering by the network interfaces. Cisco IOS software executes from DRAM memory. Supported module types are Unregistered Dual In-Line Memory Module (UDIMM) and very low profile registered DIMM (VLP RDIMM).

 

Cisco 2901 Cisco 2911 Cisco 2921 - UDIMM sizes—512 MB, 1 GB, 2 GB.

Cisco 2951

Expansion Type—VLP RDIMM with ECC.

VLP RDIMM sizes—512 MB, 1 GB, 2 GB.

VLP RDIMM slots—2.

Default VLP RDIMM memory module — One 512 MB module (slot 0)

Maximum memory—2.5 GB.

...

Cisco 3945E

Type—VLP RDIMMwith ECC.

VLP RDIMM sizes—512 MB, 1GB.

VLP RDIMM expansion slots—2, both must be the same density.

Default ECC memory modules—Two 512-MB modules for 1 GB.

Maximum memory—2.0 GB; 1.0 GB in each slot.

[ipfw77 1]

топикстартера жалко, он так и не узнает, какой же проц лучше, зато прослушал универский курс микропроцессорной техники почти бесплатно ))

 

топикастер мало того что уже разобрался в архитектуре обoих процессоров (и для себя выводы сделал), он уже активно изучает исходники conntrack на предмет их переписания...

 

 

p.s. а все началось с того что через роутер стало пролетать 2 млн pps в часы пик...

[NiTr0 583]

он уже активно изучает исходники conntrack на предмет их переписания...

Ну коннтраку надеюсь размер хеша увеличили и ядро обновили, прежде чем что-то переписывать? Ядро рекомендую 2.6.35.13 (у нас крутится, проблем со стабильностью нет; 2.6.37..39 вроде как по отзывам крашились с шейперами и еще чем-то - пофиксили это или нет не смотрел).

А вообще - коннтрак-то для ненужных пакетов можно (и нужно) отключать, -j NOTRACK в помощь. Не думаю, что вам нужны state всех сессий - не нат же ведь...

[ipfw77 1]

он уже активно изучает исходники conntrack на предмет их переписания...

Ну коннтраку надеюсь размер хеша увеличили и ядро обновили, прежде чем что-то переписывать? Ядро рекомендую 2.6.35.13 (у нас крутится, проблем со стабильностью нет; 2.6.37..39 вроде как по отзывам крашились с шейперами и еще чем-то - пофиксили это или нет не смотрел).

 

да, таймауты выкрутил до "почти экстримального" минимума, типа:

 

net.netfilter.nf_conntrack_generic_timeout = 15
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 6
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 6
net.netfilter.nf_conntrack_tcp_timeout_established = 30
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 12
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 6
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 6
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 6
net.netfilter.nf_conntrack_tcp_timeout_close = 3
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 15
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 15
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 1
net.netfilter.nf_conntrack_udp_timeout_stream = 1
net.netfilter.nf_conntrack_icmp_timeout = 6
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_events = 1
net.netfilter.nf_conntrack_events_retry_timeout = 5
net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_count = 9648
net.netfilter.nf_conntrack_max_expected = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0

 

А вообще - коннтрак-то для ненужных пакетов можно (и нужно) отключать, -j NOTRACK в помощь. Не думаю, что вам нужны state всех сессий - не нат же ведь...

 

вот именно он самый - NAT...

 

 

p.s. а можно вопрос - вот что эти параметры делают:

 

net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_events = 1

[KaYot 3 605]

Теперь я чего-то не понимаю. НАТа несколько гигабит что ли? Тогда net.netfilter.nf_conntrack_max = 65536 как-то не в тему.

А если НАТятся только какие-то сетки, никто не мешает основной поток завернуть мимо контрака и снизить нагрузку в разы.

[ipfw77 1]

Теперь я чего-то не понимаю. НАТа несколько гигабит что ли? Тогда net.netfilter.nf_conntrack_max = 65536 как-то не в тему.

 

1 гиг, а что?

 

А если НАТятся только какие-то сетки, никто не мешает основной поток завернуть мимо контрака и снизить нагрузку в разы.

 

net.netfilter.nf_conntrack_max был установлен в 512000 до того момента пока не стало все крушится от трафа и я не уменьшил таймауты в 10 раз (а то и более), после чего РЕЗКО сократилось к-во АКТИВНЫХ

 

net.netfilter.nf_conntrack_сount

 

с порядка ~200 тыс до 8-9 тыс... и переменную net.netfilter.nf_conntrack_max я уменьшил до "разумного" предела 65536

 

 

... и все же - что делают вот эти:

 

net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_events = 1

[NEP 217]

 

net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_events = 1

 

net.netfilter.nf_conntrack_acct = 1 -> If this option is enabled, the connection tracking code will keep per-flow packet and byte counters.

Those counters can be used for flow-based accounting or the `connbytes' match.

 

net.netfilter.nf_conntrack_events = 1 -> If this option is enabled, the connection tracking code will provide a notifier chain that can be used by other kernel code to get notified aboutchanges in the connection tracking state.

[KaYot 3 605]

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

 

Если у вас гиг НАТа - источник проблемы понятен и логичен, это никак не убивание прерываниями. Где-то так и должно быть.

Поможет разве что наращивание числа ядер или отказ от лишнего НАТ / пропуск ненатящегося трафика мимо conntrack'a.

[ipfw77 1]

net.netfilter.nf_conntrack_acct = 1 -> If this option is enabled, the connection tracking code will keep per-flow packet and byte counters.

Those counters can be used for flow-based accounting or the `connbytes' match.

 

net.netfilter.nf_conntrack_events = 1 -> If this option is enabled, the connection tracking code will provide a notifier chain that can be used by other kernel code to get notified aboutchanges in the connection tracking state.

 

абсолютно дурацкий вопрос - а если выключить их - что произойдет при NAT'e?

[ipfw77 1]

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

 

да вот что-то не рвется пока что... сам сижу как клиент весь вечер и даже ssh не отваливается ни разу...

[NEP 217]

абсолютно дурацкий вопрос - а если выключить их - что произойдет при NAT'e?

 

Ничего не выиграете и не проиграете.

[KaYot 3 605]

Вообще Q9550 должен натить гиг, признавайтесь что у вас еще этот 'роутер' делает и как настроена обработка прерываний? 2 интерфейса, для каждого 2 совмещенные очереди, каждая очередь привязана к своему ядру?

[ipfw77 1]

Вообще Q9550 должен натить гиг, признавайтесь что у вас еще этот 'роутер' делает

 

больше ничего. ну разве что DNS(named, но он вроде не грузит), и все. iptables -j ACCEPT

 

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

 

имеено так! (а как Вы догадались?)

[KaYot 3 605]

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

имеено так! (а как Вы догадались?)

Случайно, вы же ничего не говорите..

[NiTr0 583]

да, таймауты выкрутил до "почти экстримального" минимума, типа:

Я спрашивал не о таймаутах, а о размере хеша коннтрака. Указывается параметром при загрузке модуля (options nf_conntrack hashsize=262144 к прмиеру в /etc/modprobe.conf), посмотреть можно по cat /proc/sys/net/netfilter/nf_conntrack_buckets. Если памяти много - увеличивайте хеш, быстрее соединения будут искаться в таблице.

А вообще - загляните-ка в wive-ng-rtnl на предмет fastnat'а и прочих оффлоадов, мож чего и себе прикрутите

[ipfw77 1]

но Вы сказали что "этот тазик должен 1 гиг" спокойно натить - может дело в мелких пакетах юзеров - все-таки прожевывает на вход 1млн и на выход 1 млн pps. или руки кривые?

[KaYot 3 605]

..должен роутить, про НАТ до этого момента никто ничего не говорил.

[ipfw77 1]

Предлагаю вернуться снова к вопросу темы (какой камень лучше), но под другим ракурсом:

 

6-ядерник i7-980 против 2-процессорного 4-ядерного Xeon-5620

 

смотрите какая ситуация:

 

1) 8 ядер лучше чем 6 ядер, с одной стороны

 

2) тактовую частоту в расчет не берем - можно подобрать одинаковую для сравнения платформ

 

3) а вот как будет происходить обмен данными между кэшами процов - другими словами:

 

если в одном кристалле общий L3-cache и есть шанс, что при обработке (той же таблицы conntrack) мы будем работать сугубо с кэшем, то на 2-процессорной системе придется гонять сие еще и между процами по QPI...

 

что-то мне сдается что 1-процессорная система для nf_contrack (NAT под линух) лучше будет...

 

и непонятен вопрос: в 2-процессорном тазике зачем-то под каждый проц свои планки DDR3-памяти - а память-то как делится между камнями?

[NiTr0 583]

на 2-процессорной системе придется гонять сие еще и между процами по QPI...

Угу.

 

что-то мне сдается что 1-процессорная система для nf_contrack (NAT под линух) лучше будет...

А это уже эксперименты покажут. Коннтрак-то таблица не такая уж и большая.

Хотя как по мне, 2 тазика с распараллеливанием на L3 будут всяко быстрее чем 1 2-головый. Как минимум ввиду уменьшения размера таблицы коннтрака.

 

и непонятен вопрос: в 2-процессорном тазике зачем-то под каждый проц свои планки DDR3-памяти - а память-то как делится между камнями?

NUMA если не ошибаюсь.

[KaYot 3 605]

Теоретический общий доступ будет 6-ти канальный, плюс к ПСП. Практически, при необходимости обратиться к чужому банку памяти доступ будет идти через QPI, а это дополнительные задержки. Но в реальности, большая часть данных будет всегда кешированы, случайных обращени йк памяти минимум..

В вопросе 'i7-980 против 2-процессорного 4-ядерного Xeon-5620' 980ый будет быстрее банально за счет частоты, 2х5670 будут однозначно быстрее.