☰

Должен ли вообще «ping» в Linux быть быстрее, чем «hrping» в Windows?

tag-icon • tag-icon networking
Должен ли вообще «ping» в Linux быть быстрее, чем «hrping» в Windows?

Я использую HP DL360p Gen8. Я установил двойную загрузку Windows Server 2008 R2 и RHEL7. В обеих системах я настроил LACP и VLAN. Так что это тот же сервер, то же оборудование, та же сеть, те же таблицы маршрутизации и т. д.

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

Теперь я ожидал, что если я пингую один и тот же хост из Windows и Linux, то Linux должен быть немного лучше. Удивительно, но он совсем не лучше. На самом деле он даже на ~5-10 микросекунд хуже, чем Windows, когда я пингую один и тот же хост.

  • я использую hrpingв Windows и pingLinux
  • В Windows я использовал утилиту HP для объединения, в RHEL 7 я использовал встроенную функцию «объединения» (не объединения)

Я ожидал, что Linux будет лучше, потому что:

  • Я полагаю, что сетевая реализация RHEL 7 быстрее, чем Windows Server 2008 R2.
  • Я полагаю, что реализация RHEL 7 teaming/LACP/VLANs быстрее, чем в Windows Server 2008 R2/HP.

Мои вопросы:

  1. если такое число существует: насколько микросекунд быстрее ping из RHEL 7, чем из Windows Server 2008 R2?
  2. указывает ли это на потенциальную проблему, что Linux pingна 5-10 микросекунд медленнее, или мне следует просто игнорировать этот факт?
  3. что я могу сделать/диагностировать/устранить неполадки, чтобы сделать ping в Linux быстрее, чем в Windows

Конечно, в реальной жизни меня больше волнует задержка реального трафика, такого как TCP/UDP, но я использую pingв качестве первого шага. Вероятно, pingпоказываются те же цифры, потому что это "просто", но на реальном трафике TCP/UDP Linux будет намного быстрее?

решение1

Есть ряд факторов. Во-первых, это машина, на которой вы работаете. Если windows и linux были на разных аппаратных средствах, измерение бессмысленно.

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

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

  1. что на самом деле хронометрируется: две разные реализации ping могут выполнять более или менее шаблонную работу между запуском таймера и фактической отправкой (и то же самое на пути получения).
  2. наличие фильтров: брандмауэры и т.п. могут вводить дополнительные шаги
  3. гранулярность часов: насколько точно процессы мультиплексируются ядром? Даже среди разных уровней Linux длина тика может сильно различаться, или ядро ​​может быть более или менее безтиковым (работать без прерываний, если запущен только один процесс).
  4. управление процессами: как быстро и каким образом процесс пробуждается при возвращении пакета? Windows и Linux делают это совершенно по-разному.
  5. Что делает остальная часть системы? Происходит ли в то же время тяжелый ввод-вывод, который может перегрузить ядро? Есть ли изменения, если вы установите niceping на более высокий приоритет?
  6. Масштабирование частоты: управление частотой ЦП может сильно различаться: в Linux есть много «управляющих», которые делают вещи по-разному. Поэтому возможно, что Linux работает на более низкой тактовой частоте в режиме ожидания — также момент переключения частоты имеет дополнительную задержку.
  7. Реализация и компиляция pingутилиты также могут иметь некоторые незначительные эффекты (хотя задержка внутри ядра, вероятно, является основным фактором).

Известно, что ядро ​​Linux достигает предела пропускной способности сети при10 гигабитный уровень. Так что... это не должно иметь большого значения на микросекундных скоростях. Скорее всего, это вопрос планирования, задержек ОС и т. д. И задержка пинга не отражает фактическую производительность под нагрузкой. Вы не должны принимать это измерение как фактор, когда принимаете решение. Вам нужно много других тестов, особенно при реалистичных нагрузках.

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

Связанный контент