Software timestamp что это в сетевом адаптере

Метки времени пакетов

Введение

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

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

api-интерфейсы меток времени предоставляют Windows возможность поддержки аппаратной отметки времени сетевых адаптеров для протокола PTP версии 2. в целом функции включают в себя возможность использовать драйверы сетевых адаптеров для поддержки меток времени, а для приложений пользовательского режима — метки времени, связанные с пакетами, через сокеты Windows (см. раздел » метка времени Winsock»). Кроме того, доступна возможность создания меток времени программного обеспечения, что позволяет сетевому драйверу создавать метки времени в программном обеспечении. Такие метки программного обеспечения создаются драйверами сетевых адаптеров с помощью эквивалента QueryPerformanceCounter (QPC) в режиме ядра. Однако одновременное включение меток времени для оборудования и программного обеспечения не поддерживается.

В частности, API-интерфейсы поддержки отметок времени пакетов (вспомогательный протокол IP), описанные в этом разделе, предоставляют возможность приложениям пользовательского режима определять возможность отметок времени сетевого адаптера и запрашивать метки времени от сетевого адаптера в виде перекрестных меток времени (описанных ниже).

Поддержка протокола времени с точностью версии 2

Как уже упоминалось, основная цель поддержки меток времени в Windows — поддержка протокола версии 2 (PTPv2) с поддержкой точности. В PTPv2 не все сообщения должны иметь метку времени. В частности, в сообщениях о событиях PTP используются метки времени. В настоящее время поддержка ограничена PTPv2 по протоколу UDP. PTP через RAW Ethernet не поддерживается.

Отметка времени поддерживается для PTPv2 работы в 2 пошаговом режиме. 2 шаг относится к режиму, в котором фактические метки времени в пакетах PTP не создаются на лету в оборудовании, а извлекаются с оборудования и передаются в виде отдельных сообщений (например, с помощью сообщения об исполнении).

В сводке для повышения точности синхронизации времени в приложении PTPv2 можно использовать API-интерфейсы отметок времени пакетов поддержки протокола Интернета (вспомогательный протокол IP), а также поддержку меток времени Winsock.

Получение возможностей отметок времени сетевого адаптера

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

Даже если сетевой адаптер поддерживает метки времени, по умолчанию он должен оставаться отключенным. При этом адаптер включает метки времени. Windows предоставляет api-интерфейсы для приложения, чтобы получить возможности оборудования, а также какие возможности включены.

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

Получение перекрестных меток времени из сетевого адаптера

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

Уведомления об изменении возможностей метки времени

Пример кода 1. — Извлечение возможностей отметок времени и перекрестных меток времени

Пример кода 2. — Регистрация для получения уведомлений об изменении возможностей метки времени

В этом примере показано, как приложение может использовать метки времени в конце.

Источник

SO_TIMESTAMPING в картинках. Прием пакета

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

Наивным решением будет запоминать в приложении время сразу после получения пакета от ядра (или перед отправкой ядру):

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

Начиная с версии 2.6.30 Линукс поддерживает опцию сокета SO_TIMESTAMPING. Она позволяет пользовательскому сокету получать временные метки для отправляемых и принимаемых пакетов. Временные метки могут быть сняты самим ядром, драйвером или сетевым устройством (см. список поддерживающих устройств и драйверов). О том, что это вообще такое и как этим пользоваться, стоит почитать в Documentation/networking/timestamping.txt

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

Начальные знания

struct sk_buff

Самые интересные для нас поля struct skb_shared_info :

struct net_device и struct sock

Мы не станем подробно рассматривать эти структуры. Сейчас достаточно понять, что первая позволяет ядру общаться с устройством, а вторая — с пользовательским сокетом. Для принятого пакета: skb->dev указывает на устройство, которым он был получен; skb->sk на сокет, которому будет доставлен. Для отправляемого — наоборот.

SOFTIRQ

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

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

SOFTIRQ — Механизм ядра, позволяющий запланировать отложенный вызов функции. Часто используется для реализации Bottom Half. Всего в ядре v4.1 десять разных SOFTIRQ (см. список), обработчики для которых определяются при компиляции ядра. Во время своего выполнения обработчик может быть прерван только аппаратным прерыванием. Для каждого процессора своя маска запланированных SOFTIRQ, т.е обработчик будет вызван на том же процессоре, с которого был запланирован. (На самом деле, можно ухитриться и указать на каком конкретно процессоре запланировать SOFTIRQ.) Одно и то же SOFTIRQ может быть запланировано и
выполнено независимо на двух разных процессорах. При отправке и получении пакетов используются два из них: NET_RX_SOFTIRQ с обработчиком net_rx_action и NET_TX_SOFTIRQ с обработчиком net_tx_action. (см. net_rx_action и net_tx_action)

Прием пакета

Для общения с сетевыми устройствами Линукс использует смесь прерываний и поллинга (polling). (см. NAPI)

Вот как это выглядит:

Top Half

poll_list * — список, создаваемый ядром для каждого ядра процессора(как одно из полей struct softnet_data ). Он хранит устройства, с которых NET_RX_SOFTIRQ предстоит получить пакеты.

Bottom Half

Эта функция проходит по списку poll_list и для каждого устройства dev, пока на нем есть пакеты, вызывает виртуальную функцию драйвера napi->poll (см. include/linux/netdevice.h.), которая:

Стоит отметить, что net_rx_action() позволяет обрабатывать не более netdev_budget (экспортируется в /proc/sys/net/core/netdev_budget ) пакетов за раз и ограничивает время своего выполнения 2/HZ секундами(на x86 по умолчанию HZ = 1000, т.е ограничение времени = 2мс).

netif_receive_skb()

netif_receive_skb() — это функция, начиная с которой пакет попадает из драйвера в ядро. (На самом деле, она просто служит оберткой для других функций, которые и выполняют всю работу.) Посмотрим, что же делает ядро с полученным skb:

Обычно пакет обрабатывается тем процессором, на котором был запланирован SOFTIRQ, а это тот процессор, на который пришло прерывание. Некоторые сетевые карты шлют только одно прерывание только одному процессору, не позволяя распараллелить обработку пакетов на многопроцессорных системах. Для решения этой проблемы был придуман Receive Packet Steering (RPS).

__netif_receive_skb_core()

Прежде всего эта функция снимает временную метку, если она не была снята в netif_receive_skb_internal() :

Теперь мы имеем skb, который содержит:

Остается доставить его всем желающим получателям.

В зависимости от требуемого L3 протокола и устройства получатели могут регистрироваться в нескольких местах:

Частые пользователи всех 4-х списков — AF_PACKET сокеты, каждый из них при системном вызове bind регистрирует в соответствующем списке обработчик. (Обработчика зовут packet_rcv ) На самом деле есть еще куча получателей, но мы ограничимся только теми, которые доставляют пакет сокетам в пространстве пользователя.

Важное различие: ip_recv зарегистрирована как обработчик всего один раз в ptype_base сколько бы AF_INET сокетов вы не создали, а packet_rcv регистрируется для каждого AF_PACKET сокета по разу в каком-нибудь из списков.

Тестирование Задержек

Мы видели, что для принимаемых пакетов дважды снимаются временные метки: сетевой картой(T_hard), ядром сразу при получении (T_soft). Подводя итог, посмотрим чем вызываются задержки между ними и моментом доставки пакета пользователю(T_user):

Если за один вызов NET_RX_SOFTIRQ не удалось обработать наш пакет(был превышен netdev_budget или ограничение по времени 2/HZ), то ядро позволит выполняться другим процессам, пока аппаратное прерывание или ksoftirqd снова не вызовут `do_softirq()`. Также не стоит забывать о том, что есть и другие SOFTIRQ, на выполнение которых тоже уходит время.

В зависимости от того, что это за сокеты, доставка может занимать разное время.

Чтобы примерно оценить, насколько велики эти задержки и насколько они предсказуемы, воспользуемся программой rxtest. Эта программа:

Проверка проводилась на Core i7 с Linux 4.0 с сетевой картой Intel 82599ES под управлением драйвера ixgbe.

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

Её нужно держать открытой на протяжении всей проверки. Она будет заниматься подстройкой часов сетевой карты под системное время и выводить текущее расхождение часов. В моем случае абсолютное значение расхождения не превышало 10нс.

Это приведет к тому, что сетевая карта будет снимать временные метки для всех пакетов типа Sync протокола PTP. Почему именно Sync PTP? Потому что наша сетевая карта не умеет снимать временные метки для всех пакетов. Ей обязательно нужно указать какой-нибудь тип пакетов протокола PTP. (Это свзязано с тем, что поддержка аппаратных временных меток в Linux была введена для работы протокола PTP, позволяющего синхронизировать время с точностью до наносекунд.)

Тем временем шлем с другого конца кабеля по 10 PTP Sync пакетов в секунду. (Я брал примеры PTP пакетов с https://wiki.wireshark.org/Protocols/ptp и слал их с помощью tcpreplay.)

Результат выполнения rxtest:

При этом тестируемому сетевому интерфейсу не был присвоен ip-адрес и наши пакеты не попадали на обработку протоколом IP. Этим можно объяснить совсем небольшую задержку T_user — T_soft.

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

На этом все. Буду рад любым отзывам и критике.

Источник

Настройка производительности сетевых адаптеров

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версии 21H2 и 20H2

используйте сведения в этом разделе для настройки сетевых адаптеров производительности для компьютеров под управлением Windows Server 2016 и более поздних версий. Если сетевые адаптеры предоставляют параметры настройки, эти параметры можно использовать для оптимизации пропускной способности сети и использования ресурсов.

Правильные параметры настройки для сетевых адаптеров зависят от следующих переменных.

В следующих разделах описывается ряд параметров настройки производительности.

Включение функций разгрузки

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

Не используйте разгрузку задач IPSec функции разгрузки или разгрузку TCP Chimney. эти технологии являются устаревшими в Windows Server 2016 и могут негативно сказаться на производительности сервера и сети. Кроме того, эти технологии могут не поддерживаться корпорацией Майкрософт в будущем.

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

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

Включение масштабирования на стороне приема (RSS) для веб-серверов

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

Избегайте использования сетевых адаптеров, отличных от RSS, и сетевых адаптеров, поддерживающих RSS, на одном сервере. Из-за логики распределения нагрузки в RSS и протоколе HTTP, производительность может быть значительно снижена, если сетевой адаптер, не поддерживающий RSS, принимает веб-трафик на сервере с одним или несколькими сетевыми адаптерами, поддерживающими RSS. В этом случае необходимо использовать сетевые адаптеры, поддерживающие RSS, или отключить RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.

Чтобы определить, поддерживает ли сетевой адаптер RSS, можно просмотреть сведения RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.

Профили RSS и очереди RSS

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

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

Увеличение ресурсов сетевого адаптера

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

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

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

Включение контроля прерываний

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

Следует рассмотреть возможность контроля прерываний для рабочих нагрузок, привязанных к ЦП. При использовании управления прерываниями учитывайте компромисс между экономией ЦП узла и задержкой, а также увеличением экономии ресурсов узла из-за большего количества прерываний и снижения задержки. Если сетевой адаптер не выполняет контроль прерываний, но он предоставляет объединение буферов, можно повысить производительность, увеличив число Объединенных буферов, чтобы освободить больше буферов на отправку или получение.

Настройка производительности для обработки пакетов с низкой задержкой

Многие сетевые адаптеры позволяют настраивать параметры для оптимизации системной задержки. Задержка — это время между обработкой входящего пакета сетевым драйвером и отправкой этого пакета обратно. Обычно это время измеряется в микросекундах. Для сравнения время передачи пакетов на длинные дистанции обычно измеряется в миллисекундах (это на порядок дольше). Эта настройка не сокращает время прохождения пакета.

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

Установите в операционной системе профиль управления электропитанием Высокая производительность.

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

Включить статические разгрузки. Например, включите контрольные суммы UDP, контрольные суммы TCP и отправку параметров большой разгрузки (LSO).

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

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

Обрабатывайте прерывания сетевого адаптера и DPC на основном процессоре, который совместно использует процессорный кэш с ядром, которое используется программой (пользовательским потоком), обрабатывающей пакет. Для передачи процесса конкретным логическим процессорам можно использовать настройку фиксации ЦП вместе с настройкой RSS. Использование одного ядра для прерываний, DPC и пользовательского потока ведет к снижению производительности из-за увеличения нагрузки, поскольку ISR, DPC и поток будут конкурировать за ядро.

Прерывания управления системой

Многие аппаратные системы используют прерывания управления системой (SMI) для различных функций обслуживания, таких как сообщения об ошибках с кодом коррекции ошибок (ECC), поддержка устаревшей совместимости с USB, управление вентилятором и управление параметрами питания, управляемой BIOS.

SMI — это прерывание с наивысшим приоритетом в системе и помещает ЦП в режим управления. Этот режим загружает все остальные действия, в то время как SMI запускает подпрограммы службы прерываний, обычно содержащиеся в BIOS.

К сожалению, такое поведение может привести к скачкам задержки 100 микросекунд или более.

Когда необходимо обеспечить минимальную задержку, следует запросить у поставщика оборудования версию BIOS, в которой прерывания SMI имеют наименьший возможный приоритет. Эти версии BIOS часто называются «BIOS с низкой задержкой» или «SMI Free BIOS». В некоторых случаях аппаратная платформа не может полностью исключить активность SMI, так как она используется для управления важными функциями (например, вентиляторами).

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

Настройка производительности TCP

Для настройки производительности TCP можно использовать следующие элементы.

Автоматическая настройка окна приема TCP

в более ранних версиях Windows сетевой стек Windows использовал окно приема фиксированного размера (65 535 байт), которое ограничивает общую возможную пропускную способность для подключений. Общая пропускная способность подключений TCP может ограничивать сценарии использования сети. Автоматическая настройка окна приема TCP позволяет этим сценариям полностью использовать сеть.

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

Общая пропускная способность в байтах Размер окна приема TCP в байтах * (1/ Задержка подключения в секундах)

Например, для соединения с задержкой 10 мс общая пропускная способность составляет только 51 Мбит/с. Это значение целесообразно для большой корпоративной сетевой инфраструктуры. Однако с помощью автонастройки для настройки окна приема подключение может обеспечить полную скорость линии для подключения 1 Гбит/с.

Некоторые приложения определяют размер окна приема TCP. Если приложение не определяет размер окна приема, скорость связи определяется следующим образом:

Например, на компьютере с установленным сетевым адаптером с 1 Гбит/с размер окна должен быть 64 КБ.

Эта функция также обеспечивает полное использование других функций для повышения производительности сети. Эти функции включают остальные параметры TCP, определенные в RFC 1323. используя эти функции, компьютеры на базе Windows могут согласовать размеры окна приема TCP, которые меньше, но масштабируются по определенному значению в зависимости от конфигурации. Такое поведение упрощает обработку размеров для сетевых устройств.

Может возникнуть проблема, при которой сетевое устройство не соответствует параметру TCP Window Scale, как определено в RFC 1323 и, следовательно, не поддерживает коэффициент масштабирования. в таких случаях обратитесь к этой статье KB 934430, если вы пытаетесь использовать Windows Vista за устройством брандмауэра или обратитесь в службу поддержки для поставщика сетевых устройств.

Проверка и настройка уровня автонастройки окна приема TCP

для просмотра или изменения уровня автонастройки окна приема TCP можно использовать команды netsh или командлеты Windows PowerShell.

в отличие от версий Windows, которые предварительно устарели Windows 10 или Windows Server 2019, вы больше не можете использовать реестр для настройки размера окна приема TCP. Дополнительные сведения об устаревших параметрах TCPсм. здесь.

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

Использование команды Netsh для просмотра или изменения уровня автонастройки

Чтобы проверить текущие параметры, откройте окно командной строки и выполните следующую команду:

Выходные данные этой команды должны выглядеть следующим образом:

Чтобы изменить этот параметр, выполните в командной строке следующую команду:

В предыдущей команде представляет новое значение для уровня автоматической настройки.

Использование PowerShell для просмотра или изменения уровня автонастройки

Чтобы проверить текущие параметры, откройте окно PowerShell и выполните следующий командлет.

Выходные данные этого командлета должны выглядеть следующим образом.

Чтобы изменить этот параметр, выполните следующий командлет в командной строке PowerShell.

В предыдущей команде представляет новое значение для уровня автоматической настройки.

Дополнительные сведения об этих командлетах см. в следующих статьях:

Уровни автонастройки

Можно настроить автоматическую настройку окна приема на любой из пяти уровней. Уровень по умолчанию — Обычная. В следующей таблице описаны уровни.

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

Уровень автонастройки: нормальный (состояние по умолчанию)

Уровень автонастройки: отключен

Уровень автонастройки: ограниченный

Уровень автонастройки: очень ограниченный

Уровень автонастройки: экспериментальный

Устаревшие параметры TCP

следующие параметры реестра из Windows Server 2003 больше не поддерживаются и не учитываются в более поздних версиях.

Все эти параметры были расположены в следующем подразделе реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Платформа фильтрации Windows

Windows в Vista и Windows Server 2008 появилась платформа фильтрации Windows (WFP). WFP предоставляет интерфейсы API независимым поставщикам программного обеспечения (ISV) для создания фильтров обработки пакетов. Например, для брандмауэров и антивирусного ПО.

Плохо написанный фильтр WFP может значительно снизить производительность сети сервера. дополнительные сведения см. в разделе перенос Packet-Processing драйверов и приложений в WFP в Windows Центр разработки.

Ссылки на все разделы данного руководства см. в разделе Настройка производительности сетевой подсистемы.

Источник