Re: The continuing saga of my 5000/200 [was Re: DECstation 5000/200 timekeeping]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Can you confirm that there are no timecounter sources on either
>> machine, except for the RTC?
> On the 5000/300, yes.  [...]
> On the SS2, [...] I see

> kern.clockrate: tick = 10000, tickadj = 40, hz = 100, profhz = 100, stathz = 100

> kern.timecounter.choice = clockinterrupt(q=0, f=100 Hz) timer-counter(q=100, f=1000000 Hz) dummy(q=-1000000, f=1000000 Hz)
> kern.timecounter.hardware = timer-counter
> kern.timecounter.timestepwarnings = 0

I brought the SS2 back up again and manually set
kern.timecounter=clockinterrupt.  I then repeated the test - start NTP
(same broadcastclient configuration as all my tests), wait some 5-10
minutes for it to stabilize, then hit the disk and network.

It stabilized less stably - a little less stably.  After waiting eight
minutes (well, 8*64 seconds), the offset values from a remote xntpdc (x
because I'm running that on one of my 1.4T SPARCs) jump around, but are
all reasonably small.  In milliseconds (ie, multiplied by 1000 from
what xntpdc prints), consecutive values were -.481, -1.202, -4.756,
-3.786, -10.985, -8.872, -2.558, -6.672.  Not the best timekeeping, but
certainly not as bad as what I saw on the 5000/200.

Then I started hitting the disk and network (tar up a bunch of stuff on
a much faster machine, then ship it over the net and untar it on the
SS2).

The resulting offset values: -11.367, -7.422, -4.247, -7.454, -16.282.
At that point I killed the test, because it wasn't drifting anything
like as severely as the 5000/200.  (Remember, these numbers are
milliseconds.  The 5000/200 was drifting by over 10 seconds, at least
three orders of magnitude worse than what I saw here.)

I have tried various things to be surer the counter-timer isn't being
used.  So far I have failed.  Booting -c simply doesn't work.  userconf
isn't entered at all.  I have no idea why not; config -x says the
kernel is built with USERCONF turned on, and, based on booting with a
flags string containing unrecognized flags, the code in bootpath_build
that handles flags is running.  I tried binary-patching the netbsd in
question to turn the "counter-timer" string used by timermatch_mainbus
into "xounter-timer" instead.  That kernel exploded because it "could
not find xounter-timer in OPENPROM" - apparently string merging is
aggressive enough to share that string with code outside timer.c.  So I
backed that out and instead patched timermatch_mainbus to change the
address it uses, to make it compare against "ounter-timer" instead.
Then it fails to attach ("counter-timer at mainbus0 ioaddr 0xf3000000
ipl 10 not configured"), but the next line is "panic: counter-timer",
because it turns out to be a panic-level error for any of the devices
in (the first section of) openboot_special4c to fail to attach.  (So
using -c probably would have panicked even if userconf had worked.)

This then makes me think every sun4c has - must have - a counter-timer
node, or one of the above errors would trip at boot.  Being certain
it's not being used would be significantly more work.

So I'm not as sure as I'd like that it's using just clock interrupts.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B