🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.protocols.time.ntp
2 messages
2 total messages Started by Alan Judge Thu, 21 Jan 1993 12:24
XNTP3/MIPS RISCos 5.01 solved (ish)
#1018
Author: 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
Re: XNTP3/MIPS RISCos 5.01 solved (ish)
#1040
Author: Klaus Steinberger
Date: Wed, 27 Jan 1993 09:40
41 lines
2397 bytes
ajudge@maths.tcd.ie (Alan Judge) writes:

>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

>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

I've run xntp3 on CDC's EPIX 1.4.3 on R3000 and R6000 boxes. EPIX 1.4.3
is based on RISCos 4.52. Under EPIX 1.4.3 its just the same, we always
got the funny "Adjust CLOCK Hz" messages as well as "Previous time adjustment
didn't complete messages". I've now disabled the verify_time 
code in /usr/reconfig/io/todc_r{3030,6000}.c, and gee xntp runs more stable
now. No more didn't complete messages, and very good synchronization
to our stratum 1.

Before I had offset's in the 5-15 msec range, now i get offsets in the
0.1-2 msec range!!!!! (On a CD4320, aka RC3230.)

That's great !

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

Sincerely,
Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads