[comp.unix.aux] NTP for A/UX - Anyone got it ported?

maples@ddtisvr@uunet.uu.net (Greg Maples) (02/12/91)

I'm interested in getting NTP for our environment here.
I've not seen anyone post any info on a custom port to
A/UX, so I thought I'd find out if anyone had...

Greg Maples
Sys Grp Ldr
DuPont Design Technologies
maples%ddtisvr@uunet.uu.net

coolidge@cs.uiuc.edu (John Coolidge) (02/12/91)

maples@ddtisvr@uunet.uu.net (Greg Maples) writes:
>I'm interested in getting NTP for our environment here.
>I've not seen anyone post any info on a custom port to
>A/UX, so I thought I'd find out if anyone had...

I've done a port of XNTP for the Mac; I believe Ron Flax has put a
port out on afsg.apple.com as well. Unfortunately, it doesn't work as
well as it might; from my results it appears that the clock under A/UX
has effectively one-minute granularity and attempts to change it
within that limit (i.e. change the seconds value) are doomed to
failure. Upon much playing with the date command I convinced it to
reset the seconds to zero (and get it within a second of NTP time); it
quickly diverged back to 13 seconds off (where it was before I started
playing with date).

My hypothesis is that A/UX is maintaining a different time for hours
and minutes than that maintained by the clock chip but deferring to
the chip for seconds, and that for some reason date and adjtime don't
actually tweak the clock chip's value for the time. Anyone have any
confirmation or counter-examples?

--John
--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge@cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1991 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.

cappella@Apple.COM (Mike Cappella) (02/15/91)

In article <1991Feb12.012959.6546@julius...> coolidge@cs.uiuc.edu writes:
>well as it might; from my results it appears that the clock under A/UX
>has effectively one-minute granularity and attempts to change it
>within that limit (i.e. change the seconds value) are doomed to
>failure. Upon much playing with the date command I convinced it to
>reset the seconds to zero (and get it within a second of NTP time); it
>quickly diverged back to 13 seconds off (where it was before I started
>playing with date).
>
>My hypothesis is that A/UX is maintaining a different time for hours
>and minutes than that maintained by the clock chip but deferring to
>the chip for seconds, and that for some reason date and adjtime don't
>actually tweak the clock chip's value for the time. Anyone have any
>confirmation or counter-examples?
>

First, a little background:
    In A/UX 2.0, there were some bugs with time.  The basic problem
has to do with the floppy hardware being very dumb and intolerant of
interrupts.  Typical systems have the 60HZ clock at a high priority
interrupt level (i.e. splhi), but we have ours set to spl1.  This keeps
the floppy hardware from being interrupted in time critical portions.
The result: the Unix software time clock can drift.  I measured this at
about 14 seconds lost per minute while doing dd's to the floppy.

    Also in 2.0, the date conversion/time-zone routines were using the
notion of leap-seconds.  Setting the date always had the effect of setting
the clock about 14 seconds behind what you told date(1) the time was.

    In 2.0.1, the time keeping mechanism is much improved.  It is
correct that A/UX maintains its own notion of time (as do all of the
Unix systems I know about), and defers to the hardware clock for
seconds.  This occurs when a delta in the hardware clock is different
from a delta in Unix time.  First, the Mac hardware clock is used to
ensure that Unix time is at least accurate to within 1 second.  I just
checked the code, and the hardware clock *will* be adjusted when
adjtime() has been called, and an adjustment is requested, so NTP
should work (I haven't tested it, and will at some point).  Finally,
leap seconds have been compiled out of the default timezone conversion
dateabases, so setting the date will yield exactly what you want.


Does this help?
Mike
-- 
----
Mike Cappella			Internet: cappella@apple.com
Apple Computer, Inc.		UUCP: {sun,voder,amdahl,decwrl}!apple!cappella
Cupertino, California		408 974-4288
A/UX Department			MS 50UX