Re: [chrony-users] Inaccurate jiffy calculation at boot (x86 & 2.6.37)

[Ed W <lists@xxxxxxxxxxxxxx>]

On 05/04/2011 09:33, Miroslav Lichvar wrote:
> On Mon, Apr 04, 2011 at 11:57:49PM +0100, Ed W wrote:
>> I think the issue here is getting the processor TSC even vaguely
>> consistent from boot to boot.  I can set it through boot params, but
>> this isn't desirable..
> 
> Why not? I think setting lpj on command line is the easiest solution.

My requirements are for a distribution which will work across lots of
devices.  Most will be identical hardware, but a) I don't know if there
is an expectation that lpj should be identical across hundreds of
nominally identical motherboards, and b) it complicates distribution
when we have to support a variety of devices


> If you don't want that, you can recalculate the frequency offset in
> the drift file before chronyd is started, according to the current and
> previous lpj.

OK, so this is interesting.  Couple of questions first:

1) Is there an expectation that the lpj should be fixed for a given
piece of hardware? ie once it's been determined then it should really
remain the same for the rest of it's life? (my limited testing suggests
yes?)

2) Is there a direct correlation between altering lpj and adjusting
drift file parameters? (Assume everything else stays the same)

*Iff* 1) and 2) hold then it would seem that the drift params are not
actually useful without correcting for the clock mismeasurement which
occurs at boot?  Further it would seem that we can correct for it if we
also track the lpj used to measure a given set of drift params?


I have done a few tests and on my board it does seem that the lpj value
must be restored in order that chrony subsequently converges to the same
frequency value.  Obviously unsure if this is true for other types of clock?

I have also fiddled with arch/x86/kernel/tsc.c and disabled the
quick_pic_calibrate() call in native_calibrate_tsc().  This gets a MUCH
better estimate of lpj, but still varies by around +/- 5.  I think I can
improve things, but it will slow boot times

Out of curiousity, what do other people see as their range of initial
lpj values and correspondingly how much does chrony vary in terms of
tracking estimates between reboots on your hardware?  Does this whole
problem go away on faster hardware and/or HPET/PM timers?

Thanks

Ed W

---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.