On 14 Nov 2006, at 20:44, James K. Lowden wrote:

> Ken Hornstein wrote:
> > >> The soekris's timer is running at a different clock than usual. Make
> > >> sure you have
> > >> # AMD Elan SC520's timer runs at a different frequency
> > >> options         TIMER_FREQ=1189200
> > >
> > >but I don't see such an option in 3.1.  
> > 
> > That option is still available, and still fixes the problem.  Just
> > add that line into your kernel config and rebuild your kernel.  I
> > believe that this option is not properly dependency-tracked, so you
> > should do a "make clean" before rebuilding the kernel.
> 
> Thank you, Ken.  This did in fact fix the problem.  My Soekris box is
> named "cherry" and :
> 
> jklowden@oak$ ssh cherry date; date
> Tue Nov 14 20:38:39 EST 2006
> Tue Nov 14 20:38:15 EST 2006
> 
> Both machines use the same ntp server, which is also very close,
> network-wise, being the default gateway provided by my ISP.  So they
> shouldn't be 24 seconds apart, so the fix isn't perfect.  But it's sure a
> far sight better than it used to be.  

I use ntpd to sync to internet time. A few of my pcs have clocks too 
far out for ntpd to work effectively as the natural clock drift is at 
a greater rate than ntpd can lock to. The fix is to adjust the value 
of TIMER_FREQ in kernel configuration to offset the system clock 
drift. I aim for within -10 ppm to 0 ppm. Of course temperature and 
power supply voltage can cause fairly wide variation so near is good 
enough vs >>500 ppm drifts of some pcs. Other pcs are within 30 ppm 
without any tweaking. 

eg. from K6X400_0.32
! # K6X400 is approx -60 ppm so aim for > +50ppm change
! # default 1193182
! # for +68
! options  TIMER_FREQ=1193250

That took the -60 ppm down to around -7 ppm.

I've found a greater adjustment than from a simple calculation is 
always required.

David