Article View: comp.protocols.time.ntp
Article #1018XNTP3/MIPS RISCos 5.01 solved (ish)
From: Alan Judge
Date: Thu, 21 Jan 1993 12:24
Date: Thu, 21 Jan 1993 12:24
43 lines
2508 bytes
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!ajudgeShow 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