Re: Flaky timekeeping?

[Brian Willoughby <brianw%sounds.wa.com@localhost>]

It's been so long that I cannot remember the details. However, I do  
recall that when comparing the Real Time Clock that runs when the  
NeXT is powered off, to the basic clock that runs while the NeXT is  
on and inside the operating system, that the two are wildly different  
in accuracy. My best guess is that the RTC is reasonably accurate  
when your NeXT is off, but drift is horrible when the OS is running.  
The trick is that you need ntpd, the network time daemon, to  
regularly access a reliable network-based clock, and then the drift  
can be calculated and correctly. Only once the ntpd is set up and had  
learned the drift do you have accurate time.

Another problem with my memory is that I'm not sure I know the  
"normal" way to run ntpd. At the time, I did not have 24/7 internet  
access. Instead, I had either a telephone modem at first, and then an  
ISDN link, both of which were brought down when network access was  
not occurring. Thus, my ntpd could not maintain constant sync.  
Instead, I had some kind of daily sync command that would bump ntpd  
and fix things up reasonably well.

I've never run Net BSD on my NeXT hardware, so I don't even know how  
things might be different compared to NEXTSTEP.

In any case, I do not believe that interrupt priority is the culprit,  
here. Instead, I believe it's just that the crystal-based timer tick  
is not a convenient multiple of time, and thus the accumulated total  
drifts away from real time very quickly.

Sorry I can't remember enough to be of much help. I do know that the  
clock is not terribly accurate. I just can't say what the expected  
behavior should be with ntpd running properly. It may actually be  
normal for the drift to accumulate until some threshold is triggered,  
and then a correction brings things back to the reference time line.  
I cannot read your log well enough to discern whether what you're  
seeing is "normal" or "strange."

Brian Willoughby


On Jan 6, 2014, at 05:16, Mouse wrote:

Okay, I've got a slab running, now.  But the first thing I did, as
always, is to rebuild stuff.

And the clock is drifting, and, worse, drifting irregularly.

I started ntpd as a broadcast client (I have another machine in the
broadcast domain broadcasting time).  Here's what I get querying it
every 64 seconds from another machine:

     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64    3 0.00781  0.509586 1.98584
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64    7 0.00781  1.322884 1.39456
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64   17 0.00781  1.640805 0.97235
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64   37 0.00781  1.955022 0.66771
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64   77 0.00781  1.777081 0.44275
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64  177 0.00781  2.075839 0.26672
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64  377 0.00781  2.888184 0.09338
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64  377 0.00781  3.205274 0.09331
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64  377 0.00781  3.034869 0.09335
     remote           local      st poll reach  delay   offset    disp
=======================================================================
 10.0.1.1        10.0.1.4         4   64  377 0.00781  3.854038 0.09341

This looks bizarre to me.  Does next68k suffer from the same problem as
mac68k wherein clock interrupts are of a low enough hardware priority
that they aren't reliable?  Or is there something stranger going on?

In case it matters, this is with 4.0.1.  I was tempted to run 1.4T, and
may end up having to fall back to that, but I'd _like_ SCSI support,
and 4.0.1 is the earliest of the versions I run elsewhere (and thus am
set up to deal with easily) that supports SCSI on this hardware.
(Given how sluggish compiles are being, and my experiences with 4.0.1
on x86 machines with as little RAM as this slab has (32M), I fear I may
have to fall back to 1.4T just in order to keep it from thrashing
itself to death trying to build the world.  I'm hoping the 68k compiler
isn't as much of a pig as the x86 compiler is.)