NEP 217 Опубліковано: 2011-07-23 14:49:09 Share Опубліковано: 2011-07-23 14:49:09 Ну "идиоты" эти ребята из Интел, вот бы кайот с нитро их поучили собирать маршрутизаторы: 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 Опубліковано: 2011-07-23 15:20:51 Share Опубліковано: 2011-07-23 15:20:51 Ну "идиоты": 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 Опубліковано: 2011-07-23 17:53:32 Автор Share Опубліковано: 2011-07-23 17:53:32 топикстартера жалко, он так и не узнает, какой же проц лучше, зато прослушал универский курс микропроцессорной техники почти бесплатно )) топикастер мало того что уже разобрался в архитектуре обoих процессоров (и для себя выводы сделал), он уже активно изучает исходники conntrack на предмет их переписания... p.s. а все началось с того что через роутер стало пролетать 2 млн pps в часы пик... Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-23 18:10:28 Share Опубліковано: 2011-07-23 18:10:28 он уже активно изучает исходники conntrack на предмет их переписания... Ну коннтраку надеюсь размер хеша увеличили и ядро обновили, прежде чем что-то переписывать? Ядро рекомендую 2.6.35.13 (у нас крутится, проблем со стабильностью нет; 2.6.37..39 вроде как по отзывам крашились с шейперами и еще чем-то - пофиксили это или нет не смотрел). А вообще - коннтрак-то для ненужных пакетов можно (и нужно) отключать, -j NOTRACK в помощь. Не думаю, что вам нужны state всех сессий - не нат же ведь... Ссылка на сообщение Поделиться на других сайтах
ipfw77 1 Опубліковано: 2011-07-23 18:34:17 Автор Share Опубліковано: 2011-07-23 18:34:17 он уже активно изучает исходники 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 710 Опубліковано: 2011-07-23 18:58:36 Share Опубліковано: 2011-07-23 18:58:36 Теперь я чего-то не понимаю. НАТа несколько гигабит что ли? Тогда net.netfilter.nf_conntrack_max = 65536 как-то не в тему. А если НАТятся только какие-то сетки, никто не мешает основной поток завернуть мимо контрака и снизить нагрузку в разы. Ссылка на сообщение Поделиться на других сайтах
ipfw77 1 Опубліковано: 2011-07-23 19:12:09 Автор Share Опубліковано: 2011-07-23 19:12:09 Теперь я чего-то не понимаю. НАТа несколько гигабит что ли? Тогда 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 Опубліковано: 2011-07-23 19:22:56 Share Опубліковано: 2011-07-23 19:22:56 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 710 Опубліковано: 2011-07-23 19:44:29 Share Опубліковано: 2011-07-23 19:44:29 Тайм-ауты неразумно низкие, должны быть постоянные обрывы сессий у клиентов. Это не выход.. Если у вас гиг НАТа - источник проблемы понятен и логичен, это никак не убивание прерываниями. Где-то так и должно быть. Поможет разве что наращивание числа ядер или отказ от лишнего НАТ / пропуск ненатящегося трафика мимо conntrack'a. Ссылка на сообщение Поделиться на других сайтах
ipfw77 1 Опубліковано: 2011-07-23 19:48:11 Автор Share Опубліковано: 2011-07-23 19:48:11 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 Опубліковано: 2011-07-23 19:50:01 Автор Share Опубліковано: 2011-07-23 19:50:01 Тайм-ауты неразумно низкие, должны быть постоянные обрывы сессий у клиентов. Это не выход.. да вот что-то не рвется пока что... сам сижу как клиент весь вечер и даже ssh не отваливается ни разу... Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-23 20:02:52 Share Опубліковано: 2011-07-23 20:02:52 абсолютно дурацкий вопрос - а если выключить их - что произойдет при NAT'e? Ничего не выиграете и не проиграете. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2011-07-23 20:03:16 Share Опубліковано: 2011-07-23 20:03:16 Вообще Q9550 должен натить гиг, признавайтесь что у вас еще этот 'роутер' делает и как настроена обработка прерываний? 2 интерфейса, для каждого 2 совмещенные очереди, каждая очередь привязана к своему ядру? Ссылка на сообщение Поделиться на других сайтах
ipfw77 1 Опубліковано: 2011-07-23 20:10:07 Автор Share Опубліковано: 2011-07-23 20:10:07 Вообще Q9550 должен натить гиг, признавайтесь что у вас еще этот 'роутер' делает больше ничего. ну разве что DNS(named, но он вроде не грузит), и все. iptables -j ACCEPT и как настроена обработка прерываний? 2 интерфейса, для каждого 2 совмещенные очереди, каждая очередь привязана к своему ядру? имеено так! (а как Вы догадались?) Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2011-07-23 20:13:06 Share Опубліковано: 2011-07-23 20:13:06 и как настроена обработка прерываний? 2 интерфейса, для каждого 2 совмещенные очереди, каждая очередь привязана к своему ядру? имеено так! (а как Вы догадались?) Случайно, вы же ничего не говорите.. Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-23 20:24:48 Share Опубліковано: 2011-07-23 20:24:48 да, таймауты выкрутил до "почти экстримального" минимума, типа: Я спрашивал не о таймаутах, а о размере хеша коннтрака. Указывается параметром при загрузке модуля (options nf_conntrack hashsize=262144 к прмиеру в /etc/modprobe.conf), посмотреть можно по cat /proc/sys/net/netfilter/nf_conntrack_buckets. Если памяти много - увеличивайте хеш, быстрее соединения будут искаться в таблице. А вообще - загляните-ка в wive-ng-rtnl на предмет fastnat'а и прочих оффлоадов, мож чего и себе прикрутите Ссылка на сообщение Поделиться на других сайтах
ipfw77 1 Опубліковано: 2011-07-23 20:38:52 Автор Share Опубліковано: 2011-07-23 20:38:52 но Вы сказали что "этот тазик должен 1 гиг" спокойно натить - может дело в мелких пакетах юзеров - все-таки прожевывает на вход 1млн и на выход 1 млн pps. или руки кривые? Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2011-07-23 20:46:56 Share Опубліковано: 2011-07-23 20:46:56 ..должен роутить, про НАТ до этого момента никто ничего не говорил. Ссылка на сообщение Поделиться на других сайтах
ipfw77 1 Опубліковано: 2011-07-24 13:55:50 Автор Share Опубліковано: 2011-07-24 13:55:50 Предлагаю вернуться снова к вопросу темы (какой камень лучше), но под другим ракурсом: 6-ядерник i7-980 против 2-процессорного 4-ядерного Xeon-5620 смотрите какая ситуация: 1) 8 ядер лучше чем 6 ядер, с одной стороны 2) тактовую частоту в расчет не берем - можно подобрать одинаковую для сравнения платформ 3) а вот как будет происходить обмен данными между кэшами процов - другими словами: если в одном кристалле общий L3-cache и есть шанс, что при обработке (той же таблицы conntrack) мы будем работать сугубо с кэшем, то на 2-процессорной системе придется гонять сие еще и между процами по QPI... что-то мне сдается что 1-процессорная система для nf_contrack (NAT под линух) лучше будет... и непонятен вопрос: в 2-процессорном тазике зачем-то под каждый проц свои планки DDR3-памяти - а память-то как делится между камнями? Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-24 15:03:48 Share Опубліковано: 2011-07-24 15:03:48 на 2-процессорной системе придется гонять сие еще и между процами по QPI... Угу. что-то мне сдается что 1-процессорная система для nf_contrack (NAT под линух) лучше будет... А это уже эксперименты покажут. Коннтрак-то таблица не такая уж и большая. Хотя как по мне, 2 тазика с распараллеливанием на L3 будут всяко быстрее чем 1 2-головый. Как минимум ввиду уменьшения размера таблицы коннтрака. и непонятен вопрос: в 2-процессорном тазике зачем-то под каждый проц свои планки DDR3-памяти - а память-то как делится между камнями? NUMA если не ошибаюсь. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2011-07-24 15:30:37 Share Опубліковано: 2011-07-24 15:30:37 Теоретический общий доступ будет 6-ти канальный, плюс к ПСП. Практически, при необходимости обратиться к чужому банку памяти доступ будет идти через QPI, а это дополнительные задержки. Но в реальности, большая часть данных будет всегда кешированы, случайных обращени йк памяти минимум.. В вопросе 'i7-980 против 2-процессорного 4-ядерного Xeon-5620' 980ый будет быстрее банально за счет частоты, 2х5670 будут однозначно быстрее. Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас