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

[ipfw77 1]

Приветсвую!

 

Есть тазик Core Quad 9550 (4х-ядерник) 3,4 ГГц, стоит сетевуха Intel E1G42ET, обработка прерываний руками разведена на разные ядра проца (/proc/irq/{NN}/smp_afinity), крутится под Linux Debian.

 

Все хорошо, но с увеличением трафа (расширили внешник до 1гига) - начинает "ложиться" по прерываниям (загрузка за 95%). Понятно что нужно апгрейдиться.

 

Вот вроде "вкусно" так пишут про Core i7-2600, но если сравнить с i7-980 вот что бросается в глаза:

 

1) да, i7-2600 лучше микроархитектура, сам камень на ~20% быстрее на той же частоте

2) на i7-2600 память DDR3 работает только в 2х-канальном режиме, а на i7-980 - полноценно в 3-канальном

3) главный момент: i7-2600K гонится только множителем, BCLK стоит мертво на 100MHz, 
  в то время как i7-980 штатно шина на 133МГц, и гнать можно - ну сколько погонишь

 

Вопрос гуру: а что надо для быстрой обработки прерываний: быстрый камень или быстрая шина? чем i7-2600 будет быстрее того же Quad 9550?

 

Ну ладно, допустим что Quad - старое поколение, i7 все по-другому, но все же остается вопрос: что именно критично для вышепоставленной задачи - соответственно из этого и следует какой камень лучше - более старый i7-980 или "продвигаемый" i7-2600...

 

Буду благодарен всем откликнувшимся.

[KaYot 3 710]

Шины и множители это хорошо, но у 980ого 6 ядер - он в любом случае быстрее. А шина для современных CPU понятие вообще скорее виртуальное, все зависит от частоты камня и памяти.

[dan_aspire 81]

Такие объёмы трафика лучше сразу с тазиков на L3 переводить

[mlevel 52]

A ще краще поставте FreeBSD. Така машина може до 2 Гбіт. жувати.

[NiTr0 584]

Что крутится на тазике-то? Шейпер/нат/файрвол?

Займитесь для начала профайлингом, посмотрите, кто конкретно много кушает. Его и оптимизируйте. Гигабит для короквада ИМХО семечки. У нас 500 мбит жует феном x2 (небольшой файрвол, нат части адресов + приоритезация траффика канала) - загрузка % 10 от силы...

[ipfw77 1]

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

 

 iptables -A FORWARD -j ACCEPT

 

практически ничего не меняется. Пробовал играться с IntMode и InterruptThroleteRate, выставлять буфера:

 

 ethtool -G eth0 rx=4096

 

по барабану. atop говорит что 99% съедают прерывания (cat /proc/interrupts подтверждает это).

 

 

а вот под FreeBSD_8.1 - жует спокойно 1,5 синхронных гига с кучей шейперов "на ура" + pipe-ов где-то под ~4000 штук, и нагружен проц только на 30-40%.

 

Linux "умирает" на 600 Метрах (вход 400 + исход 200) на том же железе - вот и разница с фрюхой...

 

 

p.s. кто знает - сетевуха на чипе 82580 (e1g44HT) чем-то принципиально отличается от 82576/82575 (e1g44ET/ET2) ?

[Magus 22]

Скорее всего ядро старое, в стиле 2.6.22-26-28, если не старше. В пост 2.6.35 кернелах, серьёзно улучшили обработку пакетов.

[Flash82 7]

A ще краще поставте FreeBSD. Така машина може до 2 Гбіт. жувати.

+1

[KaYot 3 710]

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

 

 iptables -A FORWARD -j ACCEPT

 

практически ничего не меняется. Пробовал играться с IntMode и InterruptThroleteRate, выставлять буфера:

 

 ethtool -G eth0 rx=4096

 

по барабану. atop говорит что 99% съедают прерывания (cat /proc/interrupts подтверждает это).

 

 

а вот под FreeBSD_8.1 - жует спокойно 1,5 синхронных гига с кучей шейперов "на ура" + pipe-ов где-то под ~4000 штук, и нагружен проц только на 30-40%.

Linux "умирает" на 600 Метрах (вход 400 + исход 200) на том же железе - вот и разница с фрюхой...

 

p.s. кто знает - сетевуха на чипе 82580 (e1g44HT) чем-то принципиально отличается от 82576/82575 (e1g44ET/ET2) ?

Не должно такого быть, все-таки где-то кривой софт. Если service iptables stop сделать, нагрузка не падает?

Как вариант - время жрет бридж, опишите чуть подробнее железо и задачи.

Да, у нас примерно такие конфиги на серверах доступа(терминация pppoe, фаервол, аккаунтинг, частично НАТ) легко осиливают до гига трафика в обе стороны с загрузкой в 30%, линукс 2.6.31

[NiTr0 584]

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

 

 iptables -A FORWARD -j ACCEPT

 

практически ничего не меняется.

Версия ядра, версия драйвера, что говорит oprofile?

Я уже говорил, что 2-ядерный феном спокойно жует 500 мбит в каждую из сторон практически не напрягаясь. И он же жевал до 600 мбит с forcedeth сетевухами.

 

Пробовал играться с IntMode и InterruptThroleteRate, выставлять буфера:

 

 ethtool -G eth0 rx=4096

 

по барабану.

Неудивительно. Ознакомьтесь прежде, что такое softirq что ли...

 

atop говорит что 99% съедают прерывания (cat /proc/interrupts подтверждает это).

cat /proc/interrupts подтвердить ничего не может. Принципиально. Порядка 2000 прерываний/сек на ядро собссно есть норма, при сравнительно нешироком канале - проц при этом загружен % на 3.

[ipfw77 1]

Версия ядра, версия драйвера, что говорит oprofile?

 

ядро 2.6.31.14

 

драйвер сетевухи igb-2.4.8

 

 

Пробовал играться с IntMode и InterruptThroleteRate, выставлять буфера:

 

 ethtool -G eth0 rx=4096

 

по барабану.

Неудивительно. Ознакомьтесь прежде, что такое softirq что ли...

 

а можно популярно объяснить в чем фишка с softirq?

 

Спасибо.

 

з.ы. пошел читать man oprofile

[KaYot 3 710]

soft interrupt это вовсе не обработка прерываний, правильно вам направление поиска дали. Это обработка пакетов софтом, обычно модули iptables, шейперы, всякие коллекторы трафика и т.п.

[NEP 217]

Приветсвую!

 

Есть тазик Core Quad 9550 (4х-ядерник) 3,4 ГГц, стоит сетевуха Intel E1G42ET, обработка прерываний руками разведена на разные ядра проца (/proc/irq/{NN}/smp_afinity), крутится под Linux Debian.

 

Все хорошо, но с увеличением трафа (расширили внешник до 1гига) - начинает "ложиться" по прерываниям (загрузка за 95%). Понятно что нужно апгрейдиться.

 

Вот вроде "вкусно" так пишут про Core i7-2600, но если сравнить с i7-980 вот что бросается в глаза:

 

1) да, i7-2600 лучше микроархитектура, сам камень на ~20% быстрее на той же частоте

2) на i7-2600 память DDR3 работает только в 2х-канальном режиме, а на i7-980 - полноценно в 3-канальном

3) главный момент: i7-2600K гонится только множителем, BCLK стоит мертво на 100MHz, 
  в то время как i7-980 штатно шина на 133МГц, и гнать можно - ну сколько погонишь

 

Вопрос гуру: а что надо для быстрой обработки прерываний: быстрый камень или быстрая шина? чем i7-2600 будет быстрее того же Quad 9550?

 

Ну ладно, допустим что Quad - старое поколение, i7 все по-другому, но все же остается вопрос: что именно критично для вышепоставленной задачи - соответственно из этого и следует какой камень лучше - более старый i7-980 или "продвигаемый" i7-2600...

 

Буду благодарен всем откликнувшимся.

 

"быстрый камень"

"быстрая шина"

 

Надежность и отказоустойчивость - вот главный критерий. Лучше всего подойдет Xeon E3, у контроллера памяти которого есть поддержка ЕСС памяти. ЗАБУДЬТЕ ПРО ДЕСКТОПНЫЕ ПРОЦЕССОРЫ НА СЕРВЕРАХ.

 

Все хорошо, но с увеличением трафа (расширили внешник до 1гига) - начинает "ложиться" по прерываниям (загрузка за 95%).

 

1) 1Г такая машина, если ее использовать исключительно в качестве бордера пропустит и не заметит! (может таки стоит снять с нее задачи DNS, DB, DHCP, shaper, Billing, WEB, netflow...) Вы понимаете, что такое конвейер и что такое прерывание? У каждого процессора есть конвейер, ну скажем у вашего квада длина конвейера - 25 ступеней. Когда геренрируется прерывание, процессор переключается на его обработку и соотв. сбрасывает конвейер. Дальше выполнение задачи продлолжается, но следующий результат вы получите только после инициализации конвейера, т.е. спустя 25 тактов. Таким образом, каждое прерывание приводит к разрыву конвейера при котором вы в общем случае теряете 25 тактов на каждом прерывании. Т.е использовать сервер в качестве маршрутизатора и вешать на него какие либо другие задачи - нонсенс.

 

2) У вас все очереди используются? Вы обновляли драйвер для E1G42ET с сайта Intel?

[ipfw77 1]

2) У вас все очереди используются? Вы обновляли драйвер для E1G42ET с сайта Intel?

 

да, все 4 очереди и каждое на своем ядре проца крутится, дрова обновлял до 2.4.8...

 

на всякий случай вот еще: крутится на Debian сборка Lenny, ядро 2.6.31.14, под 32 бита.

 

есть ли смысл перелазить на 64-битную платформу и может ли что в Debian 6.0 sqeeze соптимизировали bridge и iptables?

[mt6561 63]

У нас i7 роутит 2 гигабита, загрузка где-то 30% (из которых 10 - это демон, собирающий статистику).

Проблем на самом деле есть. И вот какие:

1. IPTABLES во Linux строится просто списком, не деревом. Поэтому несколько сотен и тем более тысяч правил убивают все в известное место.

2. Шейперы не параллелятся. Как, впрочем, и IPTABLES. Но шейперы более процессороемки. Потому если включить шейперы - то одно ядро убивается, а остальные - пустые. И больше нескольких сот мегабит не пролазит.

3. i7 не совсем 8-ми ядерный. Он на самом деле 4-х ядерный, но ядра с hypertreading'ом (по крайней мере тот, что у нас). Потому если каждый проц нагружен более чем на 50% - начинается резкая деградация производительности с потерями пакетов. За этим надо просто следить и принимать во внимание.

 

Потому если задача просто пророутить - то Linux на i7 с сетевушкой, умеющей параллелить потоки, вполне достаточно для полноценного роутинга 10G с FullView. Но если нужно хоть чуть-чуть большего - то тогда лучше все-таки FreeBSD с патчами Альтера, которые параллелят все, что только можно, и быстро работают с длинными списками правил.

[ipfw77 1]

1. IPTABLES во Linux строится просто списком, не деревом. Поэтому несколько сотен и тем более тысяч правил убивают все в известное место.

 

а в Sqeeze это не пофиксили? (и какие у разработчиков вообще планы не известно)?

 

можно по-подробнее: какая сборка линукса, сетевуха, ядро итд. спасибо.

[RVL 6]

1. IPTABLES во Linux строится просто списком, не деревом. Поэтому несколько сотен и тем более тысяч правил убивают все в известное место.

 

ipset используйте

[KaYot 3 710]

У нас i7 роутит 2 гигабита, загрузка где-то 30% (из которых 10 - это демон, собирающий статистику).

Проблем на самом деле есть. И вот какие:

1. IPTABLES во Linux строится просто списком, не деревом. Поэтому несколько сотен и тем более тысяч правил убивают все в известное место.

2. Шейперы не параллелятся. Как, впрочем, и IPTABLES. Но шейперы более процессороемки. Потому если включить шейперы - то одно ядро убивается, а остальные - пустые. И больше нескольких сот мегабит не пролазит.

Не совсем правда.

С картами на 82576(ET board) iptables и шейперы параллелятся замечательно, загрузка равномерно делится по ядрам. Тем более, если интерфейсов 2(или 4, роутеры редко собирают с 1 карточкой), загружено будет 2/4 ядра, а не одно, даже без ET с его очередями.

Линейность iptables тоже ерунда, ipset позволяет обрабатывать ДЕСЯТКИ ТЫСЯЧ правил с нулевой нагрузкой, BSDшные tables обзавидуются.

Все преимущества BSD сводятся лишь к возможности получить распределение нагрузки на любом железе, не обязательна поддержка очередей самой сетевкой.. Впрочем в linux'ах начиная с 2.6.35 с RPS это тоже работает, так что от системы мало что зависит - всем правит софт и его правильная настройка.

 

Ах да, вспомнил. Есть одна работа, для которой BSD с ее балансировкой подходит лучше - pppoe сервер доступа 'все в одном'. У intel ET распределение нагрузки для pppoe не работает в принципе, RPS линукс работает кое-как, но тоже не фонтан.

Но не для роутеров

[ipfw77 1]

С картами на 82576(ET board) iptables и шейперы параллелятся замечательно, загрузка равномерно делится по ядрам. Тем более, если интерфейсов 2(или 4, роутеры редко собирают с 1 карточкой), загружено будет 2/4 ядра, а не одно, даже без ET с его очередями.

 

а Intel 82580 это тоже касается?

 

 

Все преимущества BSD сводятся лишь к возможности получить распределение нагрузки на любом железе, не обязательна поддержка очередей самой сетевкой.. Впрочем в linux'ах начиная с 2.6.35 с RPS это тоже работает, так что от системы мало что зависит - всем правит софт и его правильная настройка.

 

а что такое RPS? (можно в личку)

[pavlabor 1 949]

Приветсвую!

 

Есть тазик Core Quad 9550 (4х-ядерник) 3,4 ГГц, стоит сетевуха Intel E1G42ET, обработка прерываний руками разведена на разные ядра проца (/proc/irq/{NN}/smp_afinity), крутится под Linux Debian.

 

Все хорошо, но с увеличением трафа (расширили внешник до 1гига) - начинает "ложиться" по прерываниям (загрузка за 95%). Понятно что нужно апгрейдиться.

 

Вот вроде "вкусно" так пишут про Core i7-2600, но если сравнить с i7-980 вот что бросается в глаза:

 

1) да, i7-2600 лучше микроархитектура, сам камень на ~20% быстрее на той же частоте

2) на i7-2600 память DDR3 работает только в 2х-канальном режиме, а на i7-980 - полноценно в 3-канальном

3) главный момент: i7-2600K гонится только множителем, BCLK стоит мертво на 100MHz, 
  в то время как i7-980 штатно шина на 133МГц, и гнать можно - ну сколько погонишь

 

Вопрос гуру: а что надо для быстрой обработки прерываний: быстрый камень или быстрая шина? чем i7-2600 будет быстрее того же Quad 9550?

 

Ну ладно, допустим что Quad - старое поколение, i7 все по-другому, но все же остается вопрос: что именно критично для вышепоставленной задачи - соответственно из этого и следует какой камень лучше - более старый i7-980 или "продвигаемый" i7-2600...

 

Буду благодарен всем откликнувшимся.

 

Чо то мне здается что вся проблема в этой фразе

обработка прерываний руками разведена на разные ядра проца

Потому как на фре 8.2 все подымается автоматом, и нагрузка под гиг для такой тачки и этой карты не есть проблема.

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

 

Второй момент, глючное железо, линух упал, нагрузка 95%...

 

По процам, если чем больше частота проца, тем меньше задержка пакета,

количество процов, это уже тема загрузки машины.

[natiss 16]

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

 

 iptables -A FORWARD -j ACCEPT

 

практически ничего не меняется. Пробовал играться с IntMode и InterruptThroleteRate, выставлять буфера:

 

 ethtool -G eth0 rx=4096

 

по барабану. atop говорит что 99% съедают прерывания (cat /proc/interrupts подтверждает это).

 

 

а вот под FreeBSD_8.1 - жует спокойно 1,5 синхронных гига с кучей шейперов "на ура" + pipe-ов где-то под ~4000 штук, и нагружен проц только на 30-40%.

 

Linux "умирает" на 600 Метрах (вход 400 + исход 200) на том же железе - вот и разница с фрюхой...

 

линукс - на помойку

[natiss 16]

У вас все очереди используются? Вы обновляли драйвер для E1G42ET с сайта Intel?

От Эльдарчика :)

А как в вятте с этим делом? Там можно поставить драйвер от Ашота?

[NiTr0 584]

Надежность и отказоустойчивость - вот главный критерий. Лучше всего подойдет Xeon E3, у контроллера памяти которого есть поддержка ЕСС памяти. ЗАБУДЬТЕ ПРО ДЕСКТОПНЫЕ ПРОЦЕССОРЫ НА СЕРВЕРАХ.

Аптайм год на одном из роутеров, собранных на десктопном железе (еще сокет а; после его апгрейда - оказалось что половина кондеров попухла). Ребуты/висы бордюров - уже и не припомню когда были по причине кернел паники или каких-либо еще проблем с софтом/железом. ЧЯДНТ?

 

Когда геренрируется прерывание, процессор переключается на его обработку и соотв. сбрасывает конвейер. Дальше выполнение задачи продлолжается, но следующий результат вы получите только после инициализации конвейера, т.е. спустя 25 тактов. Таким образом, каждое прерывание приводит к разрыву конвейера при котором вы в общем случае теряете 25 тактов на каждом прерывании. Т.е использовать сервер в качестве маршрутизатора и вешать на него какие либо другие задачи - нонсенс.

Поверьте, сброс конвейера по сравнению с переключением контекста - всего лишь незаметная мелочь.

 

а можно популярно объяснить в чем фишка с softirq?

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

 

1. IPTABLES во Linux строится просто списком, не деревом. Поэтому несколько сотен и тем более тысяч правил убивают все в известное место.

 

а в Sqeeze это не пофиксили? (и какие у разработчиков вообще планы не известно)?

Нет, это фиксится исключительно выпрямлением рук того, кто пишет правила. Потому как ничего не мешает сделать правила с ветвлением, или пользовать ipset где возможно.

Или голову вместо вас кто-то другой напрягать должен?

 

а Intel 82580 это тоже касается?

Спеки не читаете принципиально?

 

а что такое RPS? (можно в личку)

В гугле забанили?

 

линукс - на помойку

А ручки-то уже выпрямили, прежде чем так категорически утверждать?

[natiss 16]

2) У вас все очереди используются? Вы обновляли драйвер для E1G42ET с сайта Intel?

 

да, все 4 очереди и каждое на своем ядре проца крутится, дрова обновлял до 2.4.8...

 

на всякий случай вот еще: крутится на Debian сборка Lenny, ядро 2.6.31.14, под 32 бита.

 

есть ли смысл перелазить на 64-битную платформу и может ли что в Debian 6.0 sqeeze соптимизировали bridge и iptables?

соптимизировали граф

дебиан...

Скорее всего ядро старое, в стиле 2.6.22-26-28, если не старше. В пост 2.6.35 кернелах, серьёзно улучшили обработку пакетов.

Ага, в 10 раз. :)

А ручки-то уже выпрямили, прежде чем так категорически утверждать?

и граф пооптимизировал до полной параллельности горизонту. А собачье говно (линукс) все равно остается говном.

600 мбит нетфлоу, практически незаметные под фрибсд убивают на 100% недолинукс дэбиан

под православной, одоьбренной связщенным ЦОДОм Синодом 82576!

или нужно православную каноническую вятту?

ТС, ставьте фрибсд и забудьте про загрузку от сетевых пакетов.

[NiTr0 584]

и граф пооптимизировал до полной параллельности горизонту. А собачье говно (линукс) все равно остается говном.

600 мбит нетфлоу, практически незаметные под фрибсд убивают на 100% недолинукс дэбиан

Да ну? И это с ядерным ipt_NETFLOW модулем? или таки при сборке юзерлевел софтом через libpcap?

Если 2й вариант - ровняйте руки, прежде чем какашками метаться. А то я тоже могу начать кричать, что бздя говно потому как в ней natd тупой и медленный по сравнению с ядреным натом линукса