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

[ipfw77 1]

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

 

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

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

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

 

Ну зачем же так категорично считать всех полными дибилами? правила мало того что разветвлены, они еще и ГРАМОТНО написаны (и что такое "сложность алгоритма" представление имеется).

 

Просто возникло сомнение, что все эти "ветвления" коту под хвост если тот кто писал iptables'ы - все равно перебирают все строчки как бы ты не разветвлял.

 

Вот в чем был вопрос насчет "будут исправлять КРИВЫЕ iptables" а не "кривые руки того кто пишет правила"...

 

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

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

 

Потыкался - не нашел, поэтому спросил.

 

 

...вобще, господа, вопрос-то изначально был "какой камень лучше" а не "у кого нет университетского образования в области написания алгоритмов сложностью N*log(N)"...

 

ну да Бог с ним, с этими "камнями"...

[NiTr0 583]

Просто возникло сомнение, что все эти "ветвления" коту под хвост если тот кто писал iptables'ы - все равно перебирают все строчки как бы ты не разветвлял.

 

Вот в чем был вопрос насчет "будут исправлять КРИВЫЕ iptables" а не "кривые руки того кто пишет правила"...

Я к примеру никаких проблем с ветвлением нигде не наблюдал. Если сделано все по человечески ессно в самих правилах. Пакет обработался правилом цепочки FORWARD к примеру, передался на обработку в цепочку TABLE1, там обработался с результатом ACCEPT/REJECT/DROP - на этом дальнейшая обработка его прекращается. Можете сами проверить.

 

Потыкался - не нашел, поэтому спросил.

Да ну?

[laffytaffy 84]

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

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

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

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

 

а на хрена natd использовать, если есть ядерный ipfw?

[NiTr0 583]

а на хрена natd использовать, если есть ядерный ipfw?

А нахрена softflowd/fprobe/что там еще есть в юзерлевеле пользовать, если есть ядреный ipt_NETFLOW модуль?

[KaYot 3 605]

/на правах шутки: а нахрена использовать бсд если есть линукс?

[NEP 217]

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

 

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

[NEP 217]

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

 

Бред. Переключение контекста неразрывно связано с очисткой конвейера.

 

Вступительная компания в ВУЗы еще продолжается.

[NiTr0 583]

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

Работаем с десктопным железом с 2004г. Серьезных проблем со стабильностью нет, проблемы с питанием/пассивными элементами/аплинком возникают намного чаще, чем проблемы с серверами. Соответственно, повышать стабильность еще больше я не вижу смысла - суммарная надежность не возрастет ибо ограничена в большей мере прочими факторами. А если нужно будет увеличивать надежность - уж проще будет сделать решение на VRRP с 2 десктопными тазиками. Надежность результирующая будет выше, чем при использовании одного сервера, стоимость - меньше, время на восстановление из-за отказа - меньше (ибо комплектуха покупается за полчаса или на крайняк выдирается из домашнего/служебного компа, а новый сервер в случае чего придется ждать не день и не два).

 

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

 

Бред. Переключение контекста неразрывно связано с очисткой конвейера.

Связано. Только потери времени из-за очистки конвейера на несколько порядков меньше, чем собссно полные потери времени на переключение контекста. И при даже 5000 прерываний в секунду потери времени на очистку конвеера будет всего лишь 25*2*5000 = 250000 тактов, или (при тактовой частоте 3 ГГц) 67 мкс - т.е. накладные расходы на очистку конвеера менее 0.01%.

[NEP 217]

Работаем с десктопным железом с 2004г. Серьезных проблем со стабильностью нет, проблемы с питанием/пассивными элементами/аплинком возникают намного чаще, чем проблемы с серверами. Соответственно, повышать стабильность еще больше я не вижу смысла - суммарная надежность не возрастет ибо ограничена в большей мере прочими факторами. А если нужно будет увеличивать надежность - уж проще будет сделать решение на VRRP с 2 десктопными тазиками. Надежность результирующая будет выше, чем при использовании одного сервера, стоимость - меньше, время на восстановление из-за отказа - меньше (ибо комплектуха покупается за полчаса или на крайняк выдирается из домашнего/служебного компа, а новый сервер в случае чего придется ждать не день и не два).

 

Бред.

 

Связано. Только потери времени из-за очистки конвейера на несколько порядков меньше, чем собссно полные потери времени на переключение контекста. И при даже 5000 прерываний в секунду потери времени на очистку конвеера будет всего лишь 25*2*5000 = 250000 тактов, или (при тактовой частоте 3 ГГц) 67 мкс - т.е. накладные расходы на очистку конвеера менее 0.01%.

 

Бред в квадрате.

 

А данные тоже за 1 такт из ОЗУ вы извлечете? Да? Ах, да, у вас же на "десктопных серверах" исключительно SRAM память работающая на частоте процессора, а не DRAM с латентностью 50 нс. Этож только "идиоты" ставят ECC RDIMM, "умные пацанчики" ставят non-ECC UDIMM и фсе работает годами

 

Я бы вам советовал гумантитарный ВУЗ, технический не потяните.

[KaYot 3 605]

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

 

Бред. Переключение контекста неразрывно связано с очисткой конвейера.

 

Вступительная компания в ВУЗы еще продолжается.

Бред. Дерганья конвеера неизбежны и постоянны, никуда от них не денешься. И потери скорости от этого минимальны и стабильны, для любого CPU можно найти средний процент угадывания переходов. Никаких потерь тактов при сбросе не происходит, всего лишь отмечаются недостоверными операции которые CPU посчитал 'наперед' угадывая дальнейшее ветвление кода..

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

[KaYot 3 605]

Связано. Только потери времени из-за очистки конвейера на несколько порядков меньше, чем собссно полные потери времени на переключение контекста. И при даже 5000 прерываний в секунду потери времени на очистку конвеера будет всего лишь 25*2*5000 = 250000 тактов, или (при тактовой частоте 3 ГГц) 67 мкс - т.е. накладные расходы на очистку конвеера менее 0.01%.

Бред в квадрате.

 

А данные тоже за 1 такт из ОЗУ вы извлечете? Да? Ах, да, у вас же на "десктопных серверах" исключительно SRAM память работающая на частоте процессора, а не DRAM с латентностью 50 нс. Этож только "идиоты" ставят ECC RDIMM, "умные пацанчики" ставят non-ECC UDIMM и фсе работает годами

Хотел бы я знать, зачем бедный CPU при сбросе конвеера лезет в память. И как в этой тупой ситуации ему помогут рамбусы и прочая ахинея

[NEP 217]

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

 

Бред. Переключение контекста неразрывно связано с очисткой конвейера.

 

Вступительная компания в ВУЗы еще продолжается.

Бред. Дерганья конвеера неизбежны и постоянны, никуда от них не денешься. И потери скорости от этого минимальны и стабильны, для любого CPU можно найти средний процент угадывания переходов. Никаких потерь тактов при сбросе не происходит, всего лишь отмечаются недостоверными операции которые CPU посчитал 'наперед' угадывая дальнейшее ветвление кода..

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

 

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

[NEP 217]

Хотел бы я знать, зачем бедный CPU при сбросе конвеера лезет в память. И как в этой тупой ситуации ему помогут рамбусы и прочая ахинея

 

Ну вот работает себе процессор. Прерывание. Пришла группа пакетов. Процессор сбросил конвейер, ничего не выполнил, состояние кешей не изменил и пошел дальше работать. Вы так себе это представляете?

[NiTr0 583]

Бред.

Обосновать потрудитесь? Или одного вашего "авторитетного мнения" как обоснования хватит?

 

Бред в квадрате.

 

А данные тоже за 1 такт из ОЗУ вы извлечете? Да? Ах, да, у вас же на "десктопных серверах" исключительно SRAM память работающая на частоте процессора, а не DRAM с латентностью 50 нс. Этож только "идиоты" ставят ECC RDIMM, "умные пацанчики" ставят non-ECC UDIMM и фсе работает годами

 

Я бы вам советовал гумантитарный ВУЗ, технический не потяните.

Сброс конвейера вообще никоим образом не завязан с cache miss. И cache miss происходят с тем же успехом и во время штатной работы задачи без переключения контекста. Кстати, как и сброс конвейера (да-да, блок предсказания переходов не всегда отрабатывает как надо).

[NEP 217]

Обосновать потрудитесь? Или одного вашего "авторитетного мнения" как обоснования хватит?

 

- Контроллеры десктопных процессоров не имеют поддержки ECC, RDIMM

- Системы на базе двух десктопных процессоров скажем i7 проигрывают двухпроцессорным системам на базе серверных процессоров Xeon 55/56xx

- Серверные системы имеют более широкие возможности по использованию слотов PCI-E

- Наличие топовых интегрированных контроллеров в том числе Ethernet в серверных платы

...

 

Сброс конвейера вообще никоим образом не завязан с cache miss. И cache miss происходят с тем же успехом и во время штатной работы задачи без переключения контекста. Кстати, как и сброс конвейера (да-да, блок предсказания переходов не всегда отрабатывает как надо).

 

Ну конечно, ведь процессор просто сбрасывает конвейер, ничего не делает и не изменяется состояние кешей. Да. Именно так все и происходит.

[NiTr0 583]

- Контроллеры десктопных процессоров не имеют поддержки ECC, RDIMM

И? Какова вероятность сбоя в памяти при штатной работе десктопного железа? Толку от ЕСС мне, если и без него аптайм серверов ограничивается в первую очередь стабильностью их энергоснабжения и остановками на профилактику (чистка от пыли)?

Не говоря уже о RDIMM (буфферизация актуальна только для большого кол-ва модулей) - мне от нее как-то ни жарко, ни холодно на роутерах/бордюрах/брасах, ибо потребление памяти там редко переваливает за 500 МБ (на брасах, учитывая 200-300МБ логов).

Кстати, десктопные AMD ECC память прекрасно поддерживают... Регистровую - официально нет, неофициально - у кое-кого заводилась (s939 venice не помню какого степпинга).

 

- Системы на базе двух десктопных процессоров проигрывают двухпроцессорным системам на базе серверных

По соотношению "цена/производительность"?

 

- Серверные системы имеют более широкие возможности по использованию слотов PCI-E

А оно сильно надо в типичном сервере? Не, конечно, если это мегахранилище с 5-6 SAS контроллерами, или мегароутер с десятком 4-портовых карточек (или 10GE карт), то да. В остальном - 2-4 слотов x4 хватает с головой.

 

Ну конечно, ведь процессор просто сбрасывает конвейер, ничего не делает и не изменяется состояние кешей. Да. Именно так все и происходит.

Ну конечно, вы как экстрасенс всегда можете предсказать, что данных в кеше процессора не будет Опять же, обработка cache miss занимает далеко не основное время при переключении контекста.

[KaYot 3 605]

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

 

Бред. Переключение контекста неразрывно связано с очисткой конвейера.

 

Вступительная компания в ВУЗы еще продолжается.

Бред. Дерганья конвеера неизбежны и постоянны, никуда от них не денешься. И потери скорости от этого минимальны и стабильны, для любого CPU можно найти средний процент угадывания переходов. Никаких потерь тактов при сбросе не происходит, всего лишь отмечаются недостоверными операции которые CPU посчитал 'наперед' угадывая дальнейшее ветвление кода..

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

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

Не, я отличник, и в близкой отрасли. Скан диплома прислать?)

Ну а про конвееры уважаемый, тебя опять не в ту степь понесло. Удивлю, но да, фразы 'сброс конвеера', 'инициализация конвеера' которыми ты так лихо оперируешь, есть не более чем стандартная работа блока предсказания ветвлений CPU. Ничего никуда не загружается, очередная ошибка ветвления, вызванная сменой контента ОС, накладных расходов не несет. А может он вообще угадает этот переход))

 

Ну конечно, ведь процессор просто сбрасывает конвейер, ничего не делает и не изменяется состояние кешей. Да. Именно так все и происходит.

Ага, так все и есть. Считывается новый line из кеша и вперед.

[NEP 217]

Не, я отличник, и в близкой отрасли. Скан диплома прислать?)

Ну а про конвееры уважаемый, тебя опять не в ту степь понесло. Удивлю, но да, фразы 'сброс конвеера', 'инициализация конвеера' которыми ты так лихо оперируешь, есть не более чем стандартная работа блока предсказания ветвлений CPU. Ничего никуда не загружается, очередная ошибка ветвления, вызванная сменой контента ОС, накладных расходов не несет. А может он вообще угадает этот переход))

 

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

 

Ага, так все и есть. Считывается новый line из кеша и вперед.

 

А в кеш из DRAM данные заносит зубная фея? за 1 такт?

[NEP 217]

Ну конечно, вы как экстрасенс всегда можете предсказать, что данных в кеше процессора не будет Опять же, обработка cache miss занимает далеко не основное время при переключении контекста.

 

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

 

У меня простой вопрос. Куда сетевой контроллер разместит полученные пакеты? И каков порядок их дальнейшей обработки?

[NiTr0 583]

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

Если действительно большую часть процессорного времени занимает обработка прерываний - соответстывенно, код с достаточной вероятностью уже будет в кеше. Опять же, зависит от объема кеша; 6-8 МБ - вполне достаточный объем к слову, о 24+ МБ на ксеонах вообще не говорю - у меня роутерный дистрибутив занимает в минимальной развертке 13МБ оперативки, с рамдиском и т.п., следовательно, cache miss для него будут весьма редким явлением.

 

У меня простой вопрос. Куда сетевой контроллер разместит полученные пакеты? И каков порядок их дальнейшей обработки?

Содержимое пакета уже исполняет конвейер?

[KaYot 3 605]

2 NEP: вы все дальше погружаетесь в пучины ереси.. NiTr0 еще на прошлой странице объянил, что переключение контента планировщиком в тысячи раз затратнее чем мифические проблемы 'сброса' и 'разрыва' конвеера CPU. Что такое эти 25 тактов по сравнению с необходимостью сохранить по крайней мере все регистры и стек в памяти и восстановить другой набор?

И вообще, откуда взялась эта чудесная цифра? У core конвеер длиной 14 стадий, скорость выполнения всех целочисленных инструкций - 1 такт. Т.е. теоретически может быть задержка аж в 14 тактов. Но т.к. есть еще блок предсказания ветвлений, который в современных CPU очень умный и имеет шансы угадывания под 90% - про проблемы конвеера проще просто забыть.

То же касается и

А в кеш из DRAM данные заносит зубная фея? за 1 такт?

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

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

[NEP 217]

Если действительно большую часть процессорного времени занимает обработка прерываний - соответстывенно, код с достаточной вероятностью уже будет в кеше. Опять же, зависит от объема кеша; 6-8 МБ - вполне достаточный объем к слову, о 24+ МБ на ксеонах вообще не говорю - у меня роутерный дистрибутив занимает в минимальной развертке 13МБ оперативки, с рамдиском и т.п., следовательно, cache miss для него будут весьма редким явлением.

 

Бред. Что значит достаточно редки? В чем измеряется "достаточная редкость"?

 

Содержимое пакета уже исполняет конвейер?

 

The Intel Ethernet Controller write packet data... куда?

[NEP 217]

Что такое эти 25 тактов по сравнению с необходимостью сохранить по крайней мере все регистры и стек в памяти и восстановить другой набор?

 

Так собственно это происходит и при получении прерывания! Вот и все, что следоало понять еще не прошлой странице при упоминании словосочетания - разрыв конвейера.

[KaYot 3 605]

Что такое эти 25 тактов по сравнению с необходимостью сохранить по крайней мере все регистры и стек в памяти и восстановить другой набор?

Так собственно это происходит и при получении прерывания! Вот и все, что следоало понять еще не прошлой странице при упоминании словосочетания - разрыв конвейера.

Ну слава БГ. При получении прерывания происходит переключение контента, при чем тут конвееры и их мифические проблемы?

[NEP 217]

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

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

 

Так процессор же не только прерывания обрабатывает! Или джедаи научились заставлять x86 процессор заниматься исключительно обработкой прерываний от Ethernet контроллеров?