2.3. Выбор Ethernet контроллера

Общая информация

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

Примечание

Следует понимать, что Ethernet параметры (IAT, DF и MLR) измеряются на основании механизма захвата и маркировки Ethernet пакетов. Данный процесс происходит на аппаратном и программном уровнях.

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

Сетевой адаптер

Найти название моего адаптера

Linux

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

  • sudo lshw -class network — просмотр всех, подключенных к системе интерфейсов: название, описание и производитель адаптера, скорость, драйвер и прочее;

  • lspci | grep -i 'net' — продукт и имя производителя вашей сетевой карты;

  • sudo ethtool eth0 — информация об адаптере eth0 (указать свой): настройки, статус соединения, скорость и пр.;

  • sudo ethtool -i eth0 — информация о драйвере.

См.также

Подробная информация о проверке контроллера приведена в статье Как узнать сетевую карту в Linux.

Windows

Самым простым путем выяснить название контроллера в Windows 10 и Windows 11 является просмотр окна Сведения о системе:

  1. Нажмите кнопку Пуск и начните вводить команду msinfo32 или «сведения о системе». Выберите Сведения о системе в результатах поиска. Может потребоваться некоторое время для обновления содержимого окна.

  2. Перейдите «Компоненты ➝ Сеть ➝ Адаптер».

  3. Необходимо найти искомый адаптер на панели справа.

См.также

Другие способы поиска имени контроллера вы можете найти в оригинальной статье: How to View Network Adapter Details in Windows.

Сводная информация по некоторым контроллерам

Функциональность/Сетевой адаптер

Intel I350

Intel I340 (82580)

Intel I211

Intel I210

Intel 82574L

Intel 82576

Intel 82575

Broadcom BCM5719

Аппаратная поддержка расстановки меток времени

Per-packet

Per-packet

Per-packet

Per-packet

1

Количество очередей на один порт

До 8

2

До 2

До 4

Windows: 2
Linux 2: 1

До 16

4

4RX + 4TX

Функциональность/Сетевой адаптер

NetXtreme II BCM57810 10GbE

Intel X710 10GbE

Аппаратная поддержка расстановки меток времени

Количество очередей на один порт

30 комб.

64 комб.

1

Драйвер адаптера не имеет поддержки аппаратной расстановки меток.

2

В Linux драйвере e1000e (чипы 82571, 82572, 82573, 82574, 82583) реализована поддержка только одной RSS-очереди.

Метки времени приема Ethernet пакетов (timestamping)

Суть технологии и рекомендации

В данном разделе описываются факторы, влияющие на точность вычисления параметров IAT и DF.

При захвате пакетов каждый из них получает метку времени. Метки времени могут расставляться как программным путем, так и непосредственно сетевым контроллером. Особенности вычисления меток времени операционной системой более подробно описаны на сайте утилиты tcpdump в разделе PCAP-TSTAMP (английский язык). Механизм расстановки меток аппаратным путем (hardware timestamping) снижает общую нагрузку на host ОС и, самое главное, увеличивает точность вычисления и устраняет зависимость точности расстановки меток от нагрузки операционной системы. Программный метод менее точен и имеет зависимость от нагрузки CPU, при высокой нагрузке на центральный процессор погрешность вычисления параметров может многократно увеличиваться.

В свою очередь, аппаратный метод имеет различные реализации, наиболее эффективной является расстановка меток для каждого пакета (в терминологии Intel — Per-packet timestamp). Зонд автоматически пытается использовать аппаратный метод, если он доступен.

Исследования компании Elecard показали, что при умеренной нагрузке на CPU разница в вычислении параметров Maximum и Average IAT программным путем и при использовании аппаратного режима Per-packet timestamp составила около 10–15%. Однако, при вычислении параметра Minimum IAT разница может составить -100%…+10000% от ожидаемого значения при использовании программного или аппаратного (отличного от Per-packet timestamp) режимов. Сказываются особенности проставления меток времени.

Вывод

Джиттер характеризуют по параметру Maximum IAT, который достаточно точно вычисляется даже в программном режиме, при условии умеренной загрузки CPU. Недорогие адаптеры поддерживают только программный режим и могут быть рекомендованы для тестов системы. Для полноценной постоянной работы рекомендуется адаптер с аппаратной поддержкой расстановки меток времени (hardware time stamping). Для максимально точных измерений всех параметров (включая Minimum IAT) необходимо использовать карты с поддержкой маркировки временными метками каждого пакета (Per-packet timestamp).

Примечание

Аппаратная поддержка расстановки меток времени поддерживается только в ОС Linux.

Как проверить что адаптер поддерживает аппаратную расстановку меток?

Существует несколько способов узнать имеет ли сетевой адаптер аппаратную поддержку расстановки меток времени:

Linux — tcpdump

Утилита tcpdump. Позволяет вывести список поддерживаемых режимов проставления меток:

tcpdump -J -i <INTERFACE_NAME>

Пример исполнения команды:

[root@localhost ~]# tcpdump -J -i enp2s0
Time stamp types for enp2s0 (use option -j to set):
host (Host)
adapter (Adapter)
adapter_unsynced (Adapter, not synced with system time)

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

См.также

Полезная информация приведена в статье MAN PAGE OF PCAP-TSTAMP.

Linux — лог зонда

Лог зонда. При запуске зонда в логе есть информация об устройстве захвата пакетов:

../_images/probeLog.png
Sniff interface — имя интерфейса, который захватывает пакеты.
UseHWTimeStamps() — информация о поддержке hardware time stamping адаптером. Одно из двух сообщений ниже означает, что есть поддержка HW time stamps:
  • Sniffer use timestamp type: adapter (3)

  • Sniffer use timestamp type: adapter_unsynced (4)

Linux — ethtool

Утилита ethtool.

ethtool -T <INTERFACE_NAME>

В результате выполнения команды должны присутствовать Capabilities: hardware-receive и Hardware Receive Filter Modes: all. Пример:

[root@localhost ~]# ethtool -T eno1
Time stamping parameters for eno1:
Capabilities:
   hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
   software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
   hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
   software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
   software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
   hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
   off                   (HWTSTAMP_TX_OFF)
   on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
   none                  (HWTSTAMP_FILTER_NONE)
   all                   (HWTSTAMP_FILTER_ALL)

Очереди приема в контроллерах (Receive-Side Scaling)

Суть технологии и рекомендации

В данном разделе описываются факторы, влияющие на вычисление MLR и общую производительность системы.

Следующей важной особенностью сетевого контроллера является поддержка технологии Receive-Side Scaling (RSS) (ссылка 1 , ссылка 2).

Суть технологии RSS достаточно проста — входящий поток данных сетевого уровня разбивается на несколько очередей, обработка каждой из которых (вызов прерываний, копирование информации) производится выделенным виртуальным процессором (т. е. или отдельным физическим, или ядром). Таким образом, в случае наличия нескольких процессоров вы можете распределить интенсивный сетевой трафик по ним, снизив количество вызовов прерываний, переключений контекста, очистки кэша и прочих неприятностей, которые, если происходят много тысяч раз в секунду, могут ощутимо навредить производительности системы в целом.

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

С практической точки зрения недорогой сетевой адаптер, не имеющей технологии RSS, начнет терять данные (регистрировать ложные MLR и CC ошибки) при определенном битрейте. Вся нагрузка по обслуживанию прерываний контроллера ляжет на одно ядро, которое будет загружено на 100%, хотя остальные ядра будут свободны. Величина этого битрейта будет зависеть от производительности CPU и системы в целом.

Наличие поддержки RSS сетевым контроллером еще не означает, что ваша ОС использует разные ядра для обслуживания прерываний. Для автоматического распределения прерываний по ядрам в ОС Linux должен быть установлен и запущен пакет irqbalance, который осуществляет балансировку прерываний на различные ядра. Подробнее о балансировке в параграфе Как проверить балансировку прерываний адаптера?

Следует знать, что в Linux для части контроллеров компании Intel используется драйвер e1000e, который не имеет поддержки RSS (даже если в документации на контроллер заявлена поддержка нескольких очередей).

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

Вывод

Рекомендуется использовать сетевые адаптеры с поддержкой нескольких очередей (Receive-Side Scaling).

Как проверить балансировку прерываний адаптера?

Linux

Как указано в статье о Receive-Side Scaling (RSS), для проверки балансировки необходимо выполнить следующую команду:

egrep 'CPU|<INTERFACE_NAME>' /proc/interrupts

Рассмотрим возможные варианты ответов на команду:

  1. Ответ представлен в виде нескольких строк

             CPU0    CPU1    CPU2    CPU3    CPU4    CPU5
    89:   40187       0       0       0       0       0   MSI-edge   p1p1-0
    90:       0     790       0       0       0       0   MSI-edge   p1p1-1
    91:       0       0     959       0       0       0   MSI-edge   p1p1-2
    92:       0       0       0    3310       0       0   MSI-edge   p1p1-3
    93:       0       0       0       0     622       0   MSI-edge   p1p1-4
    94:       0       0       0       0       0    2475   MSI-edge   p1p1-5
    

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

  2. В ответе содержится только одна строка

             CPU0       CPU1
    27:     108    1595151   PCI-MSI-edge      enp2s0
    

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

Проверить, запущен ли irqbalance (входит в стандартную сборку) на CentOS 7 / Rocky Linux 8, можно командой:

systemctl -l status irqbalance.service

Если в ответе присутствует «Active: active (running)», значит демон запущен и работает. Подробнее о настройке irqbalance можно прочитать в официальной документации RedHat.