[comp.protocols.time.ntp] ntp applications under SVR3, was Re: xntp for System V

andy@jhunix.HCF.JHU.EDU (Andy S Poling) (03/29/91)

In article <1991Mar25.224705.7657@ms.uky.edu> morgan@ms.uky.edu (Wes Morgan) writes:
>In article <9103251952.AA09413@trantor.umd.edu> smb@ulysses.att.com writes:
>>
>>Does anybody know where I can ftp a System V version of xntp and/or ntp from?
>>
>>You can't -- System V Release 3 lacks the adjtime() system call; without
>>it, most of ntp is useless.

There are always naysayers, aren't there...

>Well, that depends on one's application.  I'd like to write a variation
>of ntpd that hits 3 servers several times, adjusts for delay, and then
>sets the system clock via a pipe to date(1).  This would be a startup
>program executed at boot, rather than a daemon. Would this be inappropriate?
>Server administrators, would this present a problem for you?

Aw, you can do better than a pipe to /bin/date...

I have implimented an SVR3 replacement for settimeofday() which can set the
clock to an accuracy of 1/100 of a second (if you have write permission for
/dev/kmem).  Teamed with a gettimeofday() emulation which provides the same
accuracy (if you have read permission on /dev/kmem), you can do pretty
accurate step adjustments.  The system clock on 3B2's, 3B15's and 3B4000's
only has a granularity of 1/100 second anyway.

With this all bundled into a seperate source file, and a few changes to the
ntpd source to support SYSV (the USG defines weren't good enough...) I have
nearly finished what I believe to be a working ntpd for SVR3 (at least on
3B2's and 3B15's with their 100-HZ clocks - I kept the math simple for this
first whack).

You want difficulties? :-) Try adjusting the clock on a 3B4000 where the
kernel INSISTS on synchronizing the hardware and system clocks.  I have yet
to discover a way to set the hardware clock.  stime() doesn't.  And
sys3b(STIME) doesn't either - even though the manual page explicitly states
that it does.  Every time I try to adjust the clock the kernel "clock
synchronization" reacts and the clock ends up even further away from the
correct time...  Ugh.


-Andy
--
Andy Poling                              Internet: andy@gollum.hcf.jhu.edu
UNIX Systems Programmer                  Bitnet: ANDY@JHUNIX
Homewood Academic Computing              Voice: (301)338-8096    
Johns Hopkins University                 UUCP: uunet!mimsy!aplcen!jhunix!andy