Неверные часы реального времени (от часов до лет), необходимо одноразовое немонотонное изменение при загрузке. Может Хрони решить это?

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

Но кажется, что Хрони хочет постепенно настраивать часы, сохраняя монотонность часов и без резких изменений. Это достаточно, когда дрейф составляет порядка нескольких секунд, но просто не является решением для моего случая (в моих тестах потребовались часы, чтобы исправить 10-минутный дрейф). Я инвалид maxupdateskew, Кстати.

Что я на самом деле хочу, так это сделать большие изменения на ранних этапах загрузки (немонотонные, если время установлено в будущем), с точностью до порядка секунд или (даже лучше) миллисекунд, и после их применения клиент ntp может свободно выполнять его постепенные корректировки. Я предположил, что это важный случай использования для клиентов ntp, особенно для машин без RTC, но я не могу найти хорошо поддерживаемые решения для этой проблемы.

Я учел следующее:

1. Бег hwclock --set --date="$(magically-get-correct-time)"; hwclock -s незадолго до того, как Хрони сделает свою работу. Проблема в том что magically-get-correct-time все равно придется собирать по ntp или другому сервису, а затем мне нужно запланировать запуск Chrony после того, как он преуспеет... это сложно сделать (например: что делать, если эта команда не работает из-за плохой сети? Это может быстро усложниться). Как правило, это похоже на клейкую ленту.

2. С помощью ntpdate как раз перед Chrony. Google говорит, что это было предложено на некоторых форумах. Я не знаю, насколько хорошо это будет работать, а также ощущается как клейкая лента. (также сообщается, что ntpdate устарела)

Сейчас то, что я на самом деле ищу, это способ решить эту проблему, используя только Chrony. Что заставило меня подумать, что это может быть решено, так это страница на вики Fedora, в которой Chrony рассматривается как NTP-клиент по умолчанию. Это утверждает:

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

Для меня это говорит о том, что во время так называемой начальной синхронизации Chrony может совершать немонотонный шаг. Или так я надеюсь. Но на моей установке, когда он говорит

Feb 19 17:15:30 black chronyd[696]: System clock wrong by -759.702379 seconds, adjustment started

Это не прыгает, чтобы агрессивно исправить это как можно скорее; вместо этого он распространяет изменения по часам, никогда не внося немонотонных изменений. Так что я не вижу ни одной упомянутой "начальной синхронизации". И я так и не смог выяснить, как настроить его так, чтобы он вообще делал немонотонные настройки.

Кстати, я использую Arch Linux с Chrony 1.27