LINUX.ORG.RU

Обработка сетевых пакетов и тактовая частота процессора.

 ,


0

4

Добрый день, пару раз столкнулся тут с требованиями по железу к сетевым утилитам(энтерпрайз) и почти везде указывается что при канале больше 3Гбит/с требуется частота более 3Ггц. Если тут кто разбирается хорошо в железе можете объяснить как частота связана с обработкой пакетов? Или хотя бы статью для изучения киньте. Из дополнительных требований которые я не очень понимаю, это оперативка ддр4 и отсутствие гипертрединга.


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

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

Но могу и ошибаться, может быть, кто-нибудь меня и поправит.

CaveRat ★★ ()
Ответ на: комментарий от CaveRat

толстым буфером

Уж лучше дропать пакеты, чем плодить bufferbloat

devl547 ★★★★★ ()
Последнее исправление: devl547 (всего исправлений: 1)
Ответ на: комментарий от devl547

Некоторые внедрятели DPI возможно будут с тобой несогласны.

Deleted ()
Ответ на: комментарий от Deleted

Эти внедрятели готовы всю сеть развалить ради своих бредовых идей.

Но мы же не о них)

devl547 ★★★★★ ()
Ответ на: комментарий от devl547

Я так понял, толстый буфер увеличивает latency и дает джиттер. Есть какие-нибудь тесты на эту тему?

CaveRat ★★ ()
Ответ на: комментарий от CaveRat

Главное чтобы железо было big-endian чтобы поля IP хедеров не конвертить !!!

alx777 ()

больше частота - быстрее обработка пакетов. хотя требования скорее всего из пальца высосаны (у меня суммарно более 3 гбит роутится на зионе x3450).

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

ддр4 - как по мне маркетоидный бред.

а вот годная сетевуха - таки важна. обычно это интел. остальное - на любителя, можно на ровном месте граблей огрести.

NiTr0 ★★★★★ ()

Рассчитано на кукурузу же, чтоб хоть на таких частотах справлялось.

anonymous ()
Ответ на: комментарий от NiTr0

у меня E5-2630 и говорят что надо менять на новый с ддр4 и более 3Ггц тактовой частоты, а мне кажется что это гон.

vgbnd ()
Ответ на: комментарий от vgbnd

Ну на отдельное ядро по сравнению с новыми процами он не фонтан.

anonymous ()
Ответ на: комментарий от vgbnd

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

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

NiTr0 ★★★★★ ()

Понять что за требовательные утилиты и что требуют из Вашего поста не ясно. Какой сетевой функционал (может быть не сетевой) требует 3Гц? Сколько ядер на такой частоте нужно? хотя если разработчики сетевых утилит пишут такие требования - то им виднее у них и нужно спрашивать. Сетевой функционал можно так криво написать, что и 3ГГЦ будет не особливо.
Как таковой статьи на все случаи жизни нет, у каждого сетевой функции есть своя специфика реализации
В centos 6.9 есть такой модуль bridge называется. Если через него сделать петлю двух интерфейсов интерфейсы соответственно тоже закольцевать физически, то внутри программной петли - внутри модуля bridge трафик более чем 200кpps у меня не поднимался при 100% загрузки одного ядра!!! Мой вывод - модуль с настройками по умолчанию (хз как его настраивать) использует одно ядро процессора - чем больше частота одного ядра - тем выше будет производительность модуля bridge.

Частота процессора связана с тем - что на высокой частоте - память и проц(ы) будут работать на более высокой частоте системной шины - это хорошо - будет быстрее работать алгоритм сетевого функционала.
есть такой проект
https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_introduction

Им можно генерить трафик (очень много на не топовом железе, нужны только поддерживаемые сетевухи) и тестить производительность сетевого функционала железа - NAT, роутинг, шифрование и др.

Vlad-76 ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.