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

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


On 06/04/2011 10:58, Miroslav Lichvar wrote:
> On Tue, Apr 05, 2011 at 05:14:16PM +0100, Ed W wrote:
>> 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?)
> 
> I think it should be fixed for a given piece of hw and sw.
> 
>> 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?
> 
> Yes.
> 
>> 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?
> 
> The range I usually see is few hundreds of ppm. I can't confirm what
> Bill said about some kernel version fixing the problem, I think I've
> always had it. Maybe it's not possible to get better resuls from
> 250ms measurement interval. The hpet and acpi_pm clocksources don't
> seem to have this issue.
> 


I think I have cracked at least what drives the variation and for me
it's NOT the lpj.  See my post in the other thread, but at least for my
limited set of timers it's the detected kernel hz value which drives the
variation (this hz value in turn drives the lpj, hence why it appears to
be lpj driving the change)

I have experimented with making the detection more accurate, but I can't
get it to the Hz without spending an inordinate amount of time on it,
but if we could detect in userspace what the kernel thinks the Hz are
then we can reverse out the error?

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.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/