Otto Moerbeek wrote:
So, these are the same boxes and only the OS was changed, that's why I am
asking.
Some archs use timecounter code now for the clock. That code has a lot
of benefits, but the range of clock drifts that can be compensated for
is not very big. I have an experimental diff here that might solve
your case. See below.
I will test and report back.
My understanding of the man page is that drift file will be written only
after the clock is in sync and then adjfreq will kick in to adjust it and
keep the time in sync better. But what about if it can't sync, or stay in
sync to have time to write the drift file, what then?
I would really have to look into the code to see if it's feasible to
start adjusting frequency when not synced. Currently I do not think it
will work without some rewriting. I am also worried the complexity of
the code would increase, or some oscillating effect would be
introduced in some cases.
Keeping it simple is always best. I did however as a test create a drift
file, not sure it very accurate as number, but close and the box sync
pretty quickly and still stay in sync. So, there is definitely a case
where it might be needed to create one to start with I guess. I do not
know if that file is updated after the fact however, but there is a way
around the problem for sure.
Wouldn't it make sense to be able to compensate for that and may be have
ajdfreq start to play in to help address cases like this?
I see some code have changes for this to reset the adjfreq 2 weeks and 4
days ago.
Anyway, can it be force to start using adjfreq somehow before it is in sync
if only for testing reason?
Yes, you can create a drift file yourself and (re)start ntpd. For that
to work you'll need a reasnable estimate of the dirft.
I did that and it sure work.
So to summarize, you can do three things:
1. Test the diff below
2. Hack the ntpd code to start using adjfreq without being synced (not
recommended)
3. Estimate the drift yousrelf and create a ntpd.drift file.
I would start with 1.
Will do.
Daniel
