🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.time.ntp
Article #1018

XNTP3/MIPS RISCos 5.01 solved (ish)

#1018
From: Alan Judge
Date: Thu, 21 Jan 1993 12:24
43 lines
2508 bytes
Thanks to several net people, I have now sorted out my problem with
NTP on a MIPS Magnum 4000 with RISC/os 5.01.  (At least, I think so.)

Philip Gladstone provided a patch (SETTIMEOFDAY_DAMAGED) which worked
around the problem where settimeofday ignores the sub-second part.

However, the primary problem turned out to be the MIPS kernel.  All
MIPS workstations have time of day chips, and it seems that the kernel
intermittently checks this clock and adjusts the CPU clock accordingly
(both by using an internal adjtime(), and by changing the basic speed
of the CPU clock causing the "Adjust CLOCK Hz" messages in syslog).
Obviously, this has bad interactions with the correct operation of
NTP, which is doing something similar based on NTP clocks outside.
Each time the kernel does this, NTP has a fit.

It seems from the code that this has always been done, even on R3000
machines and in RISCos 4.51, so NTP has always been a bit funny
(despite us running it for more than a year).  On the R4000, however,
the CPU clock (and maybe the TOD clock) is much further out to start
with and this explains the problems that I had getting NTP to
stabilise.

There is no MIPS-provided way to turn this off (like Sun's
dosynctodr).  However, MIPS do provide source code for all their
drivers with RISCos, so it is a fairly simple patch on most MIPS boxes
to turn this off.  They inadvertently omitted the R4000 TODC source
though, so I had to patch the binary.

I have put in a request for an easier way to disable the clock syncing.


A WARNING: at least on the R4000, the basic CPU clock speed is WAY
out, drifting over a second a minute unless you change the tick rate.
I am have now been running ntp3 for a few days with the tick set to
9808 (is this a record?), and have a freq of around 100ppm, so maybe
9809 would be better.  I'm hoping that the CPU clock is at least
stable even if it is way off, but I won't know for a few weeks and
reboots.

I haven't upgraded the R3000 boxes yet, so I don't know how bad they
are.  So, be careful if you switch off the clock syncing.
--
Alan
Technical Details
Message-ID: <9301211224.aa17791@salmon.maths.tcd.ie>
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!ucbvax!maths.tcd.ie!ajudge

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!ucbvax!maths.tcd.ie!ajudge
From: ajudge@maths.tcd.ie (Alan Judge)
Newsgroups: comp.protocols.time.ntp
Subject: XNTP3/MIPS RISCos 5.01 solved (ish)
Message-ID: <9301211224.aa17791@salmon.maths.tcd.ie>
Date: 21 Jan 93 12:24:06 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 43