чрезмерный системный дрейф часов? (2 + минуты в час)

Я выполняю довольно новую установку 17,10 в новой системе (полностью исправленный, и не виртуализированный), и заметил, что время начальной загрузки перечислило в /proc/stat btime запись продолжала изменяться. Это повредило некоторые сценарии, которые использовали эту информацию для вычислений тактового стеной времени, в которое были запущены определенные процессы.

С некоторой отладкой я нашел это btime вычисляется как now() - uptime, и btime дрейф состоял в том вследствие того, что системные часы увеличивали на другом уровне, чем часы времени работы были!

Я предположил, что это происходило из-за своего рода часов, убил, относился к системным часам systemd-timesyncd.service (т.е. ntpd замена), таким образом, я отключил timesyncd и перезагруженный, как тест. Конечно же, теперь счетчик времени работы и система синхронизируют шаг на том же уровне. (Я также установил adjtimex проверять параметры ядра, чтобы проверить, что никакие часы не убили, остается: существует нет frequency предвзятость применяется и tick значение 10000, как это должно быть.)

Без timesyncd на, однако, ясно, что системные часы очень в неисправном состоянии. Часы потеряли приблизительно 5 минут в течение 135 минут (~-37000 страниц в минуту), который подобен тому, что я получил использование adjtimex -l -w в течение приблизительно 20 минут для ручной оценки системы синхронизируют дрейф (это дает ~-40000 страниц в минуту). (И, действительно, только для проверки, с помощью секундомера, я нашел это /proc/uptime также увеличивает на неправильном уровне; ~-41000 страниц в минуту. Таким образом, это последовательно.)

Часы CMOS немного прочь также (они получили 30 секунд за эти 135 минут), но мое понимание - то, что это не должно влиять на системные часы кроме во время начальной загрузки. Существует нет /etc/adjtime файл, который я могу найти, которым системная тактовая частота была бы изменена при начальной загрузке - и так или иначе, как выше adjtimex отчеты, что не было никакого уклонения такта системных часов. Таким образом, я не могу вообразить, как часы CMOS могли вызывать проблему, я вижу с системными часами.

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

Но есть ли какое-либо другое объяснение того, почему системные часы могли быть так очень неправильно? И есть ли какие-либо решения для того, что системные таймеры выключены такой огромной суммой? Очевидно просто выполнение timesyncd не решает проблему, потому что чрезмерные часы убили это она, продукты проблематичны (как выше).

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

Для записи 17,10 установок, которые я имею на очень похожей машине, не имеют этой проблемы.

Обновление: изменение батареи CMOS ничего не сделало (как подозревается). Посмотрите ниже для заключительного разрешения проблемы.