NTP for A/UX - Anyone got it ported?

[Mike Cappella]

In article <1991Feb12.012959.6546 at julius...> coolidge at 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 at apple.com
Apple Computer, Inc.		UUCP: {sun,voder,amdahl,decwrl}!apple!cappella
Cupertino, California		408 974-4288
A/UX Department			MS 50UX