> There were some changes to various timekeeping routines made at
> some point which made this problem go away (courtesy of Bill Sommerfeld).

> I don't know if those changes made it into 1.4.x or not.

Thanks.  I'll try to track them down.

There is an extra complication with the 600au.  The SRM lies about 
the clock speed. 

From dmesg:
  Digital Personal WorkStation 600au, 598MHz

It's really 600 rather than 588.  I haven't found the appropriate 
NetBSD timekeeping code yet but Linux believed the SRM and the result 
was too far off for the PLL to lock up.  So it would jump by a couple 
of seconds every 15 minutes or so.

----

> Do you have NTP configured in your kernel?

Oops/thanks.  I missed that one.  Any reason it isn't on in most 
configs? (or at least included in the configs but commented out) 

Is there any reason not to turn it on?


> How long has xntpd been running on your system (i.e. has it had 
> enough time to figure out a decent correction to put in 
> /var/db/ntp.drift)?

I thought it generally worked well under light load but maybe I wasn't 
suspicious enough. 


[This is from a new kernel with NTP turned on so that may have changed 
things.  No network bashing yet.] 

foraker% uptime
 1:07AM  up 22 mins, 2 users, load averages: 0.11, 0.11, 0.08
foraker% ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*red-admin.pa-x. clepsydra.dec.c  2 u   12  256  377     1.95   -0.197    1.69
+gw-ns2.pa-x.dec clepsydra.dec.c  2 u   67  256  377     0.96    1.192    1.68
+gw-ns1.pa-x.dec clepsydra.dec.c  2 u   79  256  377     0.00    0.759    0.76
foraker%