Timekeeping in stable/9

[Joe Holden]

Looks like this is down to the dynamic/tickless changes in 9 (that 
aren't even noted in the release notes), the machines have now been 
switched to linux as the lack of responses/care given to my recent 
postings has been noted and it was deemed that using linux would be less 
hassle in the long run.

Unfortunate decision but I am inclined to agree.

Thanks,
J

Ian Lepore wrote:
> On Tue, 2012-01-17 at 20:12 +0000, Joe Holden wrote:
>> Hi guys,
>>
>> Has anyone else noticed the tendency for 9.0-R to be unable to 
>> accurately keep time?  I've got a couple of machines that have been 
>> upgraded from 8.2 that are struggling, in particular a Virtual box guest 
>> that was fine on 8.2, but now that's its been upgraded to 9.0 counts at 
>> anything from 2 to 20 seconds per 5 second sample, the result is similar 
>> with HPET, ACPI-fast and TSC.
>>
>> I also have physical boxes which new seem to drift quite substantially, 
>> ntpd cannot keep up and as these boxes need to be able to report the 
>> time relatively accurately, it is causing problems with log times and 
>> such...
>>
>> Any suggestions most welcome!
>>
>> Thanks,
>> J
> 
> I finally got a 9.0 generic build done today and I've been watching the
> timekeeping on 3 systems and they're all doing just fine.  Two of the
> systems are performing pretty much identically to how they did on 8.2;
> the clock frequency correction calculated by ntpd differs by less than
> 1ppm.  On the other system the kernel timekeeping routines are now
> choosing to use a different clock so I don't get a direct comparison of
> the old vs new drift rate, but the drift is still reasonable  (100ppm
> now, used to be around 88, on an old 300mhz MediaGx-based system).
> 
> I haven't had time yet to learn about the new eventtimer stuff in 9.0,
> but I know you can get some info on the choices it made via sysctl
> kern.eventtimer.  Before 9.0 I'd check sysctl kern.clockrate and vmstat
> -i and make sure the chosen clock is interrupting at the right rate, but
> now with the eventtimer stuff there's not an obvious correlation between
> hz and profhz and stathz and any particular device's interrupt rate, at
> least for some clock choices (on the old MediaGx system without ACPI or
> HPET it seems to work more like it used to).
> 
> -- Ian
> 
>