Re: setting system clock-rate

["David Lord" <netbsd%lordynet.org@localhost>]

On 1 Mar 2009 at 19:10, David Lord wrote:

> On 1 Mar 2009 at 17:54, Kristoff Bonne wrote:
> 
> > 
> > David,
> > 
> > 
> > 
> > David Lord schreef:
> >     
> >     Due to some reason (probably hardware I guess), the system-
> clock runs
> >     about 3 % to fast. The RTC-clock is correct, but the system-
> clock goes 1
> >     to 2 seconds more in advance every minute.
> >     
> >     The time-difference is that large, that ntpd is unable to 
sync.
> >         
> > 
> >     
> >     
> >     On NetBSD-3 I have compiled kernels with "options 
> TIMER_FREQ=nnnnnnn"
> >     with nnnnnnn adjusted from default so that ntpd frequency 
> offset
> >     settles down to < 10ppm. Some of the systems have needed 
500ppm 
> 
> >     frequency adjustment then ntpd doesn't have a problem.
> >       
> > 
> > Do you mean I need to re-compile my kernel, or is this something 
> that 
> > can be set during boot-time (option of grub or something like 
> that?)
> 
> I've recompiled kernels including that option.
> 
> I've just checked my kernel configs for NetBSD-4.0.1 and even one 
> I've found with a large offset on NetBSD-3 (approx +300ppm) has 
> been commented out as no longer needed on NetBSD-4.
> 
> The drifts you mention are orders of magnitude above those I've 
> been correcting for so it's possibly worth trying kernels with 
> TIMER_FREQ values adjusted by a similar amount +/- 30000ppm and 
> see if that makes a difference (I can't remember in which 
> direction the adjustment works). I have a note that default for
> TIMER_FREQ=1193182. Having a fast clock and making step 
> corrections backwards isn't considered a good idea :-(

On a p4-2400 here and NetBSD-5.0_BETA I see offset around -2ms and
frequency +47ppm. I compiled a kernel with TIMER_FREQ=1193110
(approx -72ppm) and now see offset -18ms and frequency +1ppm
although drift hasn't yet stabilised. I'll guess, based on change
in offset over time, it will stabilize around -10ppm (ie I 
overestimated the amount of correction), so it appears TIMER_FREQ 
is having a useful effect.


David