Gentoo Linux ping округляет время

Что говорит man?

А как с гентушного LiveCD ?

Какая версия iputils? У меня iputils-20211215, пингует с тысячными долями.

А ещё покажи выхлоп

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Версия ни при чём, на соседнем роутере точно такая же и всё работает.

router1 root # cat /sys/devices/system/clocksource/clocksource0/current_clocksource

jiffies

А на том сервере, где нормальные, тысячные доли

server200 root # cat /sys/devices/system/clocksource/clocksource0/current_clocksource

hpet

То есть да, дело в этом. Как исправить ?

То есть да, дело в этом. Как исправить ?

Сначала посмотри что доступно

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Если на том сервере clocksource hpet в доступных отсутствует - включи его в BIOS. Или используй acpi_pm. Вообще hpet не очень хороший выбор тащемто, с его аппаратной реализацией у многих производителей матплат проблемы, поэтому его часто по дефолту выключают в BIOS. Ядро по идее само при загрузке проводит тесты и выбирает самый стабильный clocksource. И да, если сервер физически многоголовый, в смысле с более чем одним процессорным сокетом, будет выбран hpet скорее всего, так как jiffies и tsc будут нестабильны между сокетами и ядро их отключит.

Jameson,спасибо огромное. Натолкнули в правильном направлении. Оказалось, что при переустановке сервера, было использовано ядро не той версии. Сейчас с прежним ядром, всё работает, пинги до 0.001 мс. Посмотрел clocksource, теперь стоит acpi_pm. Жму руку, благодаря таким, как Вы, на этом форуме всегда можно рассчитывать на поддержку

Да не за что. И в BIOS лучше всё таки hpet включить. Так как acpi_pm это fallback и означает что выбирать больше не из чего. А проблемы с hpet обычно десктопных матерей касаются, на серверах с ним обычно всё в порядке.

Хмммм. А у меня tsc, до сих пор проблем не было. Беглый гуглинг показал, что hpet (который у меня есть в available) сильно медленнее tsc, где-то на два порядка.

tsc лучше, да, так как он в камне, а не в чипсете, обычно он и выбирается ядром автоматически. Но в многосокетных матерях бывает так что tsc несинхронно тикает между камнями в разных сокетах и ядро тогда убирает его из доступных. И тогда лучшим вариантом становится hpet.

Вообще иерархия годности такая, по порядку — tsc, hpet, jiffies(refined_jiffies), acpi_pm. В многосокетных конфигурациях tsc и jiffies могут ядром отбраковаться, из за проблем с синхронизацией, так как оба этих счётчика в процессорном камне реализованы. Тогда остаётся выбор между hpet и acpi_pm, которые предоставляет мать, а не камень\камни. Если hpet отключён в BIOS, или если железка известна глючным hpet и находится в чёрном списке драйвера — остаётся только acpi_pm.

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

Поправляю сам себя. jiffies не показывается в доступных clocksources, так как он самый поганенький и нестабильненький, он используется только на этапе инициализации, перед тем как заведутся «нормальные» таймеры - tsc, hpet или acpi_pm. Так же он служит «последним резервом», если ничего из вышеперечисленного не доступно или не вызывает доверия.

TSC — the best, самое высокая частота, равная максимальной частоте ядра без турбо, есть в каждом физическом ядре, но во многих Рязанях ведёт себя нестабильно, разбегается между ядрами при энергосбережении или выходе из сна (core warp, это аппаратный баг камня), в некоторых Интелах Sandy\Ivy Bridge то же самое происходит в турборежиме. А меж тем этот таймер должен гарантировать стабильные тики на максимальной базовой частоте при любой реальной частоте ядра процессора. Но нет, он не всегда это делает. Многосокетные конфигурации имеют свои приколы, там бывает варп между сокетами, но зависит как от камней, так и от производителя матери.

HPET — not so best, дискретизация ниже, 10-12Mhz, но её обычно достаточно, от трёх до пяти независимых таймеров в чипсете, не привязанных к камням и их частотам. Но в случае шибко многоядерных машин, где ядер так 16-32 и больше, возникает «шторм прерываний» когда все эти ядра начинают одновременно к HPET таймерам обращаться. И производительность системы в целом резко падает в этот момент. Кроме того есть системы с глючными изначально реализациями HPET, где то фиксится обновлением фирмвари, где то нет...

ACPI_PM — дно. Независимый таймер, 3.58 MHz, одна штука, используется системой ACPI для своих нужд, тикает даже во сне, дабы пробудить систему по расписанию например. Но он один, его даже не три и не пять, так что ситуация со «штормом» на него тоже распространяется. Зато есть на всех системах сейчас.

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