> We have a set of 5 SPARC/20 based systems running (basically) Red Hat 4.2
> using either RH 2.0.30 (ie with RH patches + additional security patches)
> or 2.0.33 near vanilla kernels.
>
> Three machines are doing serious amounts of NFS work as clients. The
> other 2 are news boxes (lots of SCSI disk, no NFS).
>
> The 3 NFS clients lose time dramatically, even when running xntpd (5.90).
> The time loss appears uncorrectable - if the tick is adjusted in line with
> the daily time slippage, the system still loses time.
First of all it would be interesting what the systems do if they are
idle. Then there is the question about average network delay.
Remember NTP uses UDP, and thus packets can get lost during high
load.
I would stongly advise you to use xntpd3-5.91, which is working quite
well for several weeks here. All versions prior to 3-5.90.2 have
problems.
>
> The 2 non-NFS boxes keep within 100ms (not good, but SPARCs always did
> have crap time keeping performance).
Recent Linux sparc kernel might have an inconsistent time
implementation for non-i386 architectures. I had proposed a patch in
this list, but it seems it is still pending in qthe queues of the
arch-specific maintainers. Maybe check my PPSkit at FTP
pcphy4.physik.uni-regensburg.de in /pub/wiu09524/PPS
I have no SPARC here to test; only i386.
> Both sets of boxes are slaving to the same set of timeservers.
>
> Is there some nasty interaction between the 2.0.x NFS client?
> Has anyone an idea where this is happening and can it be fixed?
Maybe you should "logconfig =all" and "enable statistics" to gather
some data and facts.Usually that's only 60kB per day, depending on
your servers.
For general questions see the NTP FAQ at
http://www.eecis.udel.edu/~ntp
Ulrich