FANTOO: застрял пока на утилитах подстройки хода времени

SUBJ. То есть вроде как совсем собрался запустить в openvz сайт для FANTOO и как-то выпустить публичную версию, но перед этим захотел решить проблему точности времени компа даже без интернета.
Для этого начал править hwclock из util-linux. Что мне в ней не понравилось сразу -- чтоб установить точное системное время при старте, надо иметь доступ по записи на корневой раздел. И процедура при этом выглядит странно -- сначала корректируем значение времени в RTC, а потом уж устанавливаем системное время. Сделал кучу изменений для hwclock, впереди планы по правке adjtimex. ntpd и chrony.
То есть стал почти профи по работе со временем в linux. В процессе правки hwclock наткнулся на вредную фичу ядер 2.6.xx: при работе ntpd (как только он уберёт флаг, что системное время не синхронизировано), ядро начинает с периодичностью в 11 минут писать систеное время в RTC. Выглядит это так, как будто RTC идёт очень точно и корректировать его не надо. И это нарушает работу hwclock. То есть если у Вас в /etc/conf.d/hwclock записано clock_systohc=YES, то фича ядра как минимум бесполезна. А если стоит NO, то hwlock не может правильно выставить системное время при старте. Ибо требуется, чтоб последней в RTC точное время писала именно она. Вот собираюсь добавить в свой вариант ядра патч, чтоб удалить фичу правки ядром RTC. Ибо хочу пользовать ntpd и при этом иметь полный контроль над записью времени в RTC. Для правленной hwclock чем дольше мы не трогаем содержимое RTC, тем точнее определяется ошибка хода его времени. А на hwclock опирается adjtimex. Он может без ntpd определить ошибку хода уже системного времени и сделать так, чтоб оно практически не уходило. Так что можно будет жить и без ntpd.

Да, про ntpd и chrony. ntpd при старте уж слишком сильно дергает параметры хода системного времени, даже если перед этим мы определили их очень точно. Параметры, вычисленные ntpd и chrony довольно сильно отличаются. В моём случае: ntpd определил frequency в районе 84.590 (стабильно, проверено несколько раз), а chrony - 22.970. Алгоритм определения этой самой frequency в chrony гораздо правильней на мой взляд. Ибо chrony ищет параметры линейной функции (ибо время спешит или отстаёт линейно), а ntpd вычисляет их как-то путанно и всё время ещё и взвешивает. Лишнее это. Лучше бы как chrony сохранял данные по источникам и при старте их использовал.У chrony проблема -- он отбрасывает крайние точки измерений, то есть интервал измерения у него с течением времени работы не увеличивается. Поэтому точность определения характеристик плоха и плавает.

Ну вот пока и всё. С правкой hwclock почти закончил, остальное не к спеху.

Вопрос: кто пользовал опцию HPET timer support? Помогает ли она при проигровании мультимедия?
Support clock division -- стоит ли включать? В ядре от RedHat эти опции выключены. Как и Machine check exception. Советы принимаются :-)

В общем надоело уже заниматься этим самым временем. Есть желание создать очередную версию LiveCD, чтоб можно было часть разработки выполнять на работе :-) А то приходится тратить ещё и ночь дома на программирование Fantoo.