Jump to content
Калькуляторы

HuperThreading при обработке пакетов на рутере под Debian

Доброго времени суток всем участникам форума!

 

Имеется роутер (Debian 6.0.6, ядро 2.6.32-5-amd64) с двумя процессорами E-2620, 2 х 6 ядер, каждое с HT, итого 24 логических ядра. На сервере стоит 10 Ge сетевая карта, которая передаёт в ОС 16 RxTx очередей. С помощью smp_affinity планируется раскидать по очереди на каждое из ядер. Вопрос - есть ли смысл использовать в данном случае HT, или же его лучше отключить, и оставить только 12 "настоящих" ядер, и, соответственно, уменьшить количество очередей RxTx до 12? Планируемая нагрузка на данную систему - примерно 3 Mpps. Предыдущий опыт использования HT на роутере показал, что его включение даже несколько снижает общую производительность.

 

Спасибо!

Share this post


Link to post
Share on other sites

Отключите лучше.

Чем руководствуетесь?

 

Я думаю что разумно обратить внимание на 16 очередей и на 24 ядра ...

 

Лучше уж нагрузить все ядра равномерно, создав 12 на 12, чем создать нелепый перекос или делить очереди на RX и TX отдельно. На мой взгляд тоже лучше отключить. Разницы особой точно не будет, к тому же это двухголовая машина, которой предстоит лопатить трафик, а там с HT по опыту все несколько более печально.

 

На двухголовых у себя тоже отключаю. На одноголовых 50 на 50 и только голого эксперимента ради. На какой-то мизер одноголовая машина с HT чуть бодрее себя чувствует, но в цифрах превосходство несколько процентов (в пиковый час 3-4%, но за сутки все те же самые доли процента).

 

Справедливо заметить, что в ядрах 3.2.х и старше + последних поколениях CPU HT прилично допилили и теперь перекос не так вылезает. Раньше было хуже.

Share this post


Link to post
Share on other sites

или делить очереди на RX и TX отдельно

Согласен. Мало того, каждой сетевушке - свой физический процессор.

 

в пиковый час 3-4%, но за сутки все те же самые доли процента

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Ну, собственно, HT как раз-таки и решает небольшую проблему с очередью команд в процессор. IMHO, больше 5% получить там можно только на синтетических тестах.

Share this post


Link to post
Share on other sites

HT как раз-таки и решает небольшую проблему с очередью команд в процессор

А толку, если все упирается отнюдь не в ресурсы проца, а в латентность памяти из-за рандомного выгребания мелких кусков (заголовков пакетов) и средних кусков (тела пакетов, таблиц маршрутизации/сессий коннтрака и т.д.) в процессе роутинга? :)

Share this post


Link to post
Share on other sites

Не совсем так. Ширина шины, тактовая частота и размер кеша имеют значение.

+ HT

Фиг.

Выше перечисленные параметры как раз снижают латентность памяти, а лишние ядра(да еще и виртуальные) - нет. IMHO HT может немного помочь только в случае кривого софта на роутере, когда узкое место именно CPU(кривой линейный фаервол, линейный же шейпер, всякие soft-flow), а в других ситуациях бесполезен или вообще вреден.

Share this post


Link to post
Share on other sites

я думаю не стоит путать старый HT (который в П4...) и новый который на ксеонах 26хх+ и корках седьмых.

Share this post


Link to post
Share on other sites

А по мне так HT тот же, просто софт повзрослел и стал эффективнее работать с железом. Врядли кто-то ставит на новенький E5 древние линуксы 2.6.18, или BSD 7.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

но у интела даже какаято демка была что они реально улучшили HT.

В худшем случае вместо -5% "прироста" наблюдается +1-2%? Улучшение, да :)

Share this post


Link to post
Share on other sites

В худшем случае вместо -5% "прироста" наблюдается +1-2%? Улучшение, да :)

+ 1, но у меня минус был больше, вплоть до полного вылета вирт. ядер, а теперь вроде стабильно и даже до +3-4%, но это на Xeon E3 и последних версиях kernel.

Чем больше ядер, тем меньше разница от применения HT в реальных задачах.

Система с E3-1240 + HT дает прирост (мизерный, но дает и сетевые очереди более кошерно распределяются), а вот с двумя E5 по 6 ядер + HT едва ли будет заметно, если не вредно.

К тому же 24 ядра неудобно нагружать имея всего 16 очередей на сетевой.

Edited by replicant

Share this post


Link to post
Share on other sites

В худшем случае вместо -5% "прироста" наблюдается +1-2%? Улучшение, да :)

Это нам опять подводит к тому, что "HT лучше отключть"? А инженеры Интела дебилы?

Share this post


Link to post
Share on other sites

А инженеры Интела дебилы?

Зачем же так категорично заявлять? Инженеры свое дело знают и делают все правильно, но задачи, которые ставятся перед CPU, тоже бывают разные.

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

Подозреваю что в ряде задач в определенных ОС (допустим Windows) HT дает приличный выигрыш.

Edited by replicant

Share this post


Link to post
Share on other sites

Это нам опять подводит к тому, что "HT лучше отключть"? А инженеры Интела дебилы?

HT позволяет задействовать простаивающие ресурсы проца. К примеру, один поток молотит целочисленные вычисления, это не помешает 2-му потоку заюать гуляющий FPU и получить серьезный прирост производительности. Проблема возникает тогда, когда оба потока начинают грузить одни и те же блоки - производительность в лучшем случае по сравнению с одним потоком будет около нуля, в худшем - уйдет в минус из-за вымывания кеша большим кол-вом кода/данных. А еще печальнее все становится, когда оба потока начинают грузить шину памяти, простаивая в ожидании бОльшую часть времени...

Share this post


Link to post
Share on other sites

+ за HT.

 

Софт повзрослел, а вымывание кэша можно предотвратить, тупо привязав прерывания от одной карты к HT'ам одного физического ядра.

 

Интересно, узнать разницу полученную в реальности на современном железе с современным софтом с не синтетической нагрузкой.

Share this post


Link to post
Share on other sites

Интересно, узнать разницу полученную в реальности на современном железе с современным софтом с не синтетической нагрузкой.

Прочитайте на несколько сообщений выше.

Share this post


Link to post
Share on other sites

а вымывание кэша можно предотвратить, тупо привязав прерывания от одной карты к HT'ам одного физического ядра.

Нельзя. 2 потока кода на тот же кеш вместо одного. В 2 раза больше cache misses.

Share this post


Link to post
Share on other sites

IMHO HT может немного помочь только в случае кривого софта на роутере, когда узкое место именно CPU(кривой линейный фаервол, линейный же шейпер, всякие soft-flow), а в других ситуациях бесполезен или вообще вреден.

Нифига.

Получите вымывание кеша и скорость упадёт.

 

Это нам опять подводит к тому, что "HT лучше отключть"? А инженеры Интела дебилы?

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.