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

[NEP 217]

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

 

Да притом, что при переключении контекста первым делом разрывается конвейер, очищается буфер ассоциативной трансляции... Я честно говоря не думал, что прийдется обьяснять такие прописные истины.

[KaYot 3 605]

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

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

А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше.

 

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

 

Да притом, что при переключении контекста первым делом разрывается конвейер, очищается буфер ассоциативной трансляции... Я честно говоря не думал, что прийдется обьяснять такие прописные истины.

Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы?

Про ассоциативную трансляцию поподробнее, что-то новое.

[NEP 217]

А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше.

 

При интенсивной обработке прерываний? 90% - это бред.

 

Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы?

 

Т.е. вы хотите сказать, что тупо одно прерывание (скажем получен сетевой пакет) приводит к потере 11к тактов?

 

А чем "простой" отличается от разрыва конвейера?

 

Про ассоциативную трансляцию поподробнее, что-то новое.

 

Очень старое. Обновлено в i7. TLB.

[KaYot 3 605]

А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше.

При интенсивной обработке прерываний? 90% - это бред.

Я даже не удивлен ответу, он становится классикой. Пруфлинк в студию.

 

Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы?

Т.е. вы хотите сказать, что 1-о прерывание (получен сетевой пакет) приводит к потере 11к тактов?

Пакет после приема будет отправлен в iptables, почему бы и не 10к тактов?

 

Про ассоциативную трансляцию поподробнее, что-то новое.

Очень старое. Возобновлено в i7. TLB.

TLB понятно, он наверное еще с 286ого появился. Непонятно с какого лешего его очищать при каждом 'разрыве конвеера' и как(скорее даже зачем) оно в таком случае вообще работает?

И что там возобновили в i7? В i5 его нет?))

[NEP 217]

А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше.

При интенсивной обработке прерываний? 90% - это бред.

Я даже не удивлен ответу, он становится классикой. Пруфлинк в студию.

 

Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы?

Т.е. вы хотите сказать, что 1-о прерывание (получен сетевой пакет) приводит к потере 11к тактов?

Пакет после приема будет отправлен в iptables, почему бы и не 10к тактов?

 

Про ассоциативную трансляцию поподробнее, что-то новое.

Очень старое. Возобновлено в i7. TLB.

TLB понятно, он наверное еще с 286ого появился. Непонятно с какого лешего его очищать при каждом 'разрыве конвеера' и как(скорее даже зачем) оно в таком случае вообще работает?

И что там возобновили в i7? В i5 его нет?))

 

Вы сначала обьясните чем "простой" отличается от разрыва конвейера. И чем обработка прерывания отличается от обработки пакета в iptables.

[KaYot 3 605]

Вы сначала обьясните чем "простой" отличается от разрыва конвейера.

Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков..

[NEP 217]

Вы сначала обьясните чем "простой" отличается от разрыва конвейера.

Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков..

 

Так страшно тем, что пока переключается контекст - конвейер считается разорваным.

[KaYot 3 605]

Вы сначала обьясните чем "простой" отличается от разрыва конвейера.

Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков..

Так страшно тем, что пока переключается контекст - конвейер считается разорваным.

Кем считается? И чем это грозит?

Сброс конвеера совершенно нормальная операция, практически никаких накладных расходов. Слово вам понравилось, что ли?

[NiTr0 583]

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

То и значит. Код с достаточно высокой вероятностью уже будет в кеше. Зависит от объема кеша, объема обрабатываемого кода/данных и частоты вызова определенных участков кода. Так, если между 2 прерываниями обращение происходило скажем к 3 МБ данных, при этом код обработчика прерывания занимает 500КБ и код юзерспейс софта занимает 200 КБ, а кеш 6 МБ - вероятность того, что код при следующем вызове прерывания будет в кеше, равна 100%. Не?

 

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

И как это вообще соотносится с упоминаемым вами переключением контекста/"разрывом конвейера"?

Кстати, какой объем данных пакета считывается и анализируется при его маршрутизации в классическом случае?

 

Так страшно тем, что пока переключается контекст - конвейер считается разорваным.

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

[NEP 217]

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

То и значит. Код с достаточно высокой вероятностью уже будет в кеше. Зависит от объема кеша, объема обрабатываемого кода/данных и частоты вызова определенных участков кода. Так, если между 2 прерываниями обращение происходило скажем к 3 МБ данных, при этом код обработчика прерывания занимает 500КБ и код юзерспейс софта занимает 200 КБ, а кеш 6 МБ - вероятность того, что код при следующем вызове прерывания будет в кеше, равна 100%. Не?

 

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

И как это вообще соотносится с упоминаемым вами переключением контекста/"разрывом конвейера"?

Кстати, какой объем данных пакета считывается и анализируется при его маршрутизации в классическом случае?

 

Так страшно тем, что пока переключается контекст - конвейер считается разорваным.

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

 

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

[NEP 217]

Кем считается? И чем это грозит?

Сброс конвеера совершенно нормальная операция, практически никаких накладных расходов. Слово вам понравилось, что ли?

 

Где я писал о "сбросе"?!!!

[Abram 98]

Блин, вот зачем вы его трогали?

По теме: стоит Q9550 + E1G44ET, жует около 1.5 гигов, не жужжит. Нагрузка 4-х CPU ~ 40%.

Особого тюнинга нет (все вроде общеизвестное), есть даже кое-какой conntrack и NAT (но анально огорожен на нужные сети NOTRACK-ами).

Важный момент: выбран легковесный дистрибутив, дабы ничего не сделалось "автоматом" и никаких "улучшений" (у меня - Arch Linux, пойдет также правильно приготовленный Gentoo либо готовый дистрибутив NiTr0 - LEAF), драйвера на карту интеловские, man igb тщательно скурен (там есть даже втупую написано: вот это и это ставьте так).

[NiTr0 583]

На какие операции уходит основное время и какие механизмы их обработки? Можете перечислить эти операции?

Писали вам уже: переключение контекста, т.е. сохранение регистров старой задачи и загрузка регистров новой задачи, и попутно - очистка конвейера, сброс TLB (кстати, сбрасывается он далеко не всегда) и прочие мелочи.

[NEP 217]

т.е. сохранение регистров старой задачи и загрузка регистров новой задачи,

 

Что в это время делает конвейер? Он пошел погулять или участвует в проекте folding@home?

[NiTr0 583]

Что в это время делает конвейер? Он пошел погулять или участвует в проекте folding@home?

Неужто все это время он очищается?

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

К слову, почитайте о многозадачности на x86_64 и на реализации многозадачности под линем на x86, весьма интересное чтиво... Поймете, в частности, почему TLB не всегда сбрасывается (или правильнее сказать - вообще не сбрасывается, а инициализируется заранее сохраненными данными)

[NEP 217]

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

 

А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись? Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете. Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"?

 

Я уже даже стараюсь писать вам понятными терминами.

[alk0v 21]

хочешь, чтобы тема жила долго - вступи в спор с NEP-ом

извините, не удержался

[NEP 217]

хочешь, чтобы тема жила долго - вступи в спор с NEP-ом

извините, не удержался

 

Бред.

 

извините, не удержался

[pavlabor 1 914]

Память, таблицы, очереди уже давно никто не чистит, ни на аппаратном, ни на софтовом уровне.

Если инфа не обработана, стоять таймеры и подымают флаги аптайма,

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

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

затратно это и не нужно.

Проверить можете прочитав напрямую память, регистры.

В связи с этим в дровах стоят анализаторы таблиц, например той же таблицы маков которую мы показываем в нашем коммутаторе PES-08,

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

 

По сетевой, в самой сетевой есть аккумулятор, когда пакет пришол, подымается флаг прерывания для проца,

проц останавливает расчеты и обрабатывает прерывание, при этом переносит пакет себе в память.

Карты ЕТ анонсировали что они сразу пишут пакет в кеш проца и подымают флаг прерывания, процу остается только решить что с ним делать.

 

По сетевой, типа E1G44, лично у меня 99% уверености что там спецом реализованы грабли,

потому как по скорости интел и так прилично поднял производительность,

вот и оставили резерв на аппаратные решения и на будущее.

[andreu.mirowni4enko 1]

 

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

 

 

Про какие десктопные процессоры i7 вы говорите?

[NiTr0 583]

А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись?

Не поверите - само ядро линукса, которое собссно и занимается переключением контекста задачи. Аппаратная смена контекста в линуксе на х86 не пользуется, а в х86_64 - вообще отсутствует как таковая.

 

Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете.

Ну если вам лень погуглить - почитайте это и это. Вроде как понятным языком расписано, как именно выполняется программное переключение контекста задачи.

 

Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"?

 

Я уже даже стараюсь писать вам понятными терминами.

Не поверите - кодом, выполняющим переключение контекста задачи

[NEP 217]

А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись?

Не поверите - само ядро линукса, которое собссно и занимается переключением контекста задачи. Аппаратная смена контекста в линуксе на х86 не пользуется, а в х86_64 - вообще отсутствует как таковая.

 

Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете.

Ну если вам лень погуглить - почитайте это и это. Вроде как понятным языком расписано, как именно выполняется программное переключение контекста задачи.

 

Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"?

 

Я уже даже стараюсь писать вам понятными терминами.

 

Не поверите - кодом, выполняющим переключение контекста задачи

 

Спрашиваю в третий раз. Какие операции выполняет этот код? Ну распишите по ступеням, что в этом время происходит с конвейером. Неужели так сложно.

[NEP 217]

 

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

 

 

Про какие десктопные процессоры i7 вы говорите?

 

2-е системы на базе Core i7-970 против одной на базе двух Xeon 5670 в задачах маршрутизации.

[NEP 217]

Ладно.

 

В результате обработки прерывания/переключения контекста практически все блоки процессора оптимизирующие его работу, направленные на ускорение выполнения программы, улетучиваются как с белых яблонь дым (кэш, конвейер инструкций, таблица адресов переходов и TLB наполняются новыми данными, которые вытесняют существующие), а "старый" процесс оказывается заблокированным даже несмотря на то, что в системе есть ресурсы для его исполнения.

 

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

 

Это и есть разрыв ВЫЧИСЛИТЕЛЬНОГО конвейера, а не тупо сброс конвейера инструкций

 

Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер.

[KaYot 3 605]

 

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

 

 

Про какие десктопные процессоры i7 вы говорите?

 

2-е системы на базе Core i7-970 против одной на базе двух Xeon 5670 в задачах маршрутизации.

Конечно, сравнивать надо системы отличающиеся в цене в 20 раз..

Уверен, i7-980x будет быстрее чем ваши 2x5670 во всех задачах. Даже несмотря на 5-7 кратную разницу в цене только камней, а на сколько будет дороже вся система страшно представить.