OK...I appear to have opened a can of worms with my disappointment of time
keeping under NetBSD. Here's the scoop and a new thread:


On Mon, Nov 18, 2002 7:48 AM, Jonathan Newquist <jnewquis@esu10.org>
 wrote:
> have you tried installing ntpd?

Oh yes...not only have I installed it, I've studied it and tested it and
studied it some more. Below you'll find some log files and diagnostics from
ntpd to show what's going on.

Essentially, NTPD appears to force set the clock about every 20 minutes
ONLY. I haven't found any documentation that tells me how to adjust this
frequency. 

At idle, the computer will lose about 1 - 2 seconds every 20 minutes and
NTPD makes the necessary adjustment...no problem.

If I increase the load on the processor (vi a file, ftp something, etc) the
time loss increases dramatically but the frequency of forced clock changes
remains at every 20 minutes.

Under a load, the time loss can be in the neighborhood of several minutes or
more. 


> you can make all your
> internal boxes "peers" to each other, and they should sync well enough for
> your logfile purposes.
> I have heard DEC machines had excellent clocks; dont
> know if that would be true of your Compaq too.

Yes, my Proliant 850R keeps nearly perfect time (+ or - 1 second a day) and
is specified as a "peer" and as "prefer" in the Quadra's ntp.conf along with
3 other stratum 1 servers...but still, the Quadra's NTPD resets the clock
ONLY every 20 minutes no matter how much loss accumulates.


On Mon, Nov 18, 2002 2:19 PM, John Klos <john@sixgirls.org> wrote:
> ntpd sometimes cuases problems if the drift is too large, partly because
> it's always trying to compensate. It's better, at least CPU wise, to just
> set up ntpdate to run once an hour.
> 

That's an option I'm not sure I like. I can cron "ntpdate" to run every hour
but that can still result in a 5-10 minute margin of error in any given
hour...unacceptable. I'd rather stay with NTPD's update every 20 minutes.

If I cron "ntpdate" every minute, I could still see a 15 second error margin
every 60 seconds (under heavy load). I WOULD prefer that my 850R would force
set the clock anytime it's out of sync but ultimately, cron & ntpdate looks
like the closest to best option to achieve it.

On Sun, Nov 17, 2002 9:50 PM, Donald Bruce Stewart <dons@cse.unsw.edu.au>
wrote:
> From the OpenBSD mac68k clock faq entry [ "->" added by me]:
.
>  -> skip the time.  In this case, add the -g option to ntpd in
>  -> /etc/ rc.securelevel to force tracking.

I did slightly overlook that option BUT...
didn't help, still updating every 20 minutes


> If you've already looked at these things, and they don't work,
> then you should tell the list.

Yup, I was waiting until I exhausted all my study avenues before I asked a
stupid question (newbie fear).


> Personally, I just deal with the losses I get on the odd
> occasion I do a make build or some such thing, and hand-sync the
> clock, but obviously you need a rigorous solution.

That's my next decision, once the firewall/IDS is setup, how accurate do I
need to be? I may use the 840av as a firewall (it's so quiet!) anyhow.


> The above link indicates the real solution: a kernel thread that
> reads the PRAM clock in a loop. But noone has been pressured
> enough to do this, though it doesn't appear very difficult.

You would think... 

Any input is most appreciated,
Ron

RAParker
   |\/|\
   |/-|/
   |\ | @ Quadzilla.NET



Here's a crosssection of my ntp.log

---------------------------------------------------
15 Nov 18:36:02 ntpd[152]: time reset 1.875771 s
15 Nov 18:36:02 ntpd[152]: synchronisation lost
15 Nov 18:55:26 ntpd[152]: time reset 1.445807 s
15 Nov 18:55:26 ntpd[152]: synchronisation lost
15 Nov 19:14:41 ntpd[152]: time reset 1.739814 s
15 Nov 19:14:41 ntpd[152]: synchronisation lost
15 Nov 19:35:05 ntpd[152]: synchronisation lost
15 Nov 19:52:30 ntpd[152]: time reset 204.871089 s   <- WOW
15 Nov 19:52:30 ntpd[152]: synchronisation lost
15 Nov 20:08:38 ntpd[152]: synchronisation lost
15 Nov 20:21:06 ntpd[152]: time reset 106.477495 s   <- ouch
15 Nov 20:21:06 ntpd[152]: synchronisation lost
15 Nov 20:41:23 ntpd[152]: time reset 2.669505 s
15 Nov 20:41:23 ntpd[152]: synchronisation lost
15 Nov 21:00:49 ntpd[152]: time reset 1.396822 s
15 Nov 21:00:49 ntpd[152]: synchronisation lost
15 Nov 21:19:19 ntpd[152]: time reset 1.439169 s
15 Nov 21:19:19 ntpd[152]: synchronisation lost
15 Nov 21:38:44 ntpd[152]: time reset 1.525219 s
15 Nov 21:38:44 ntpd[152]: synchronisation lost
15 Nov 21:59:13 ntpd[152]: time reset 1.580504 s
15 Nov 21:59:13 ntpd[152]: synchronisation lost
15 Nov 22:18:38 ntpd[152]: time reset 1.612470 s
15 Nov 22:18:38 ntpd[152]: synchronisation lost
15 Nov 22:38:02 ntpd[152]: time reset 1.510778 s
15 Nov 22:38:02 ntpd[152]: synchronisation lost
15 Nov 22:58:24 ntpd[152]: time reset 1.651847 s
15 Nov 22:58:24 ntpd[152]: synchronisation lost
15 Nov 23:18:35 ntpd[152]: time reset 3.406586 s
15 Nov 23:18:35 ntpd[152]: synchronisation lost
15 Nov 23:21:13 ntpd[152]: ntpd exiting on signal 1
15 Nov 23:27:12 ntpd[3170]: ntpd exiting on signal 15
-----------------------------------------------------------

Some fun diagnostics for you:

-----------------------------------------------------------

ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=clepsydra.dec.c 192.168.0.40     1   64    3 0.03479  1.487468 3.93774
=usno.pa-x.dec.c 192.168.0.40     1   64    3 0.03955  1.685921 3.93776
=navobs1.wustl.e 192.168.0.40     1   64    7 0.15793  1.752778 1.93799
+QuadzillaNET.xx 192.168.0.40     2   64    7 0.00095  1.841440 1.93799

ntpdc> kerninfo
pll offset:           0 s
pll frequency:        512.000 ppm
maximum error:        0.319931 s
estimated error:      0.748043 s
status:               0001  pll
pll time constant:    2
precision:            1e-06 s
frequency tolerance:  512 ppm
ntpdc> timerstats
time since reset:  38681
alarms handled:    0
alarm overruns:    0
calls to transmit: 0

ntpq> peers
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
 navobs1.wustl.e .PSC.            1 u   30   64   17  160.011  2051.61
456.973
 clepsydra.dec.c .GPS.            1 u    9   64   17   39.993  2161.34
435.255
 usno.pa-x.dec.c .USNO.           1 u   58   64    7   42.483  1980.24
389.313
 QuadzillaNET.xx usno.pa-x.dec.c  2 u   49   64   17    0.954  2244.25
255.519

ntpq> associations
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 62292  90f4   yes   yes  none    reject   reachable 15
  2 62293  90f4   yes   yes  none    reject   reachable 15
  3 62294  90f4   yes   yes  none    reject   reachable 15
  4 62295  90f4   yes   yes  none    reject   reachable 15

ntpq> rl 62295
status=94f4 reach, conf, sel_candidat, 15 events, event_reach,
srcadr=QuadzillaNET.xxxxxxxxxxxx.xxx, srcport=123,
dstadr=192.168.0.40, dstport=123, keyid=0, stratum=2, precision=-18,
rootdelay=36.392, rootdispersion=53.421, refid=usno.pa-x.dec.com,
reftime=c183fdbe.49d9e40c  Mon, Nov 18 2002 16:01:02.288, delay=0.967,
offset=3491.712, jitter=201.835, dispersion=0.933, reach=377, valid=7,
hmode=1, pmode=2, hpoll=6, ppoll=6, leap=00, flash=00 ok,
org=c184014b.12a4ebdd  Mon, Nov 18 2002 16:16:11.072,
rec=c1840147.16584f4c  Mon, Nov 18 2002 16:16:07.087,
xmt=c1840147.160e3044  Mon, Nov 18 2002 16:16:07.086,
filtdelay=     0.97    0.96    0.95    0.97    0.95    0.95    0.97    0.96,
filtoffset= 3986.03 3813.41 3491.68 3352.83 2663.53 2291.35 1119.10  797.36,
filtdisp=      0.01    0.96    1.93    2.89    3.84    4.80    5.76    6.73