From: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
Newsgroups: comp.protocols.time.ntp
Subject: Help with synchronising Suns with NTP
Date: 17 Nov 1992 10:05:03 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Distribution: inet
Reply-To: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
NNTP-Posting-Host: hela.ins.cwru.edu


Please find enclosed a request for information on NTP from
a colleague, who does'nt have access to News.  Please reply
to the NET or me direct.

Steve Fitch                            o          ,__o        o   /\/\
Open University                       <\        _-\_<,     []<\  /~~\ \/\
Management Services Division        __/__,     (*)/'(*)      /> /    \ \ \
Milton Keynes, England.       +44 (0908)65 2733  s.c.fitch@open.ac.uk

=======================================================================
From R.J.Gander@open.ac.uk  Tue Nov 17 09:49:55 1992
From: R.J.Gander@open.ac.uk (Roger Gander K186 - 2732)
Subject: NTP QUESTIONS
To: s.c.fitch@open.ac.uk
Date: Tue, 17 Nov 92 9:49:39 GMT
X-Mailer: ELM [version 2.3 PL11]

I am currently experimenting with using ntp to coordinate the clocks on
various Sun machines at our University campus. Being fairly new to ntp, I
find I have several unanswered questions. I wonder if anyone can help me.

We have received some ntp programs as part of the "ISODE 7.0" (ISO Development
Environment) package, which seem to be some modified "standard" ntp programs
(version 3.4 ?) with OSI extensions.

In particular, there are 2 programs I am experimenting with:

(1) ntpd - an ntp "server/client" daemon - I am using this to synchronise
    one machine with a reliable offsite server (using OSI transport). This
    seems to work OK-ish, although its behaviour is erratic (or at least,
    seems to be to my untrained eye).
  - The far site doesn't always respond, although it does so every now and
    again (presumably, there could be many reasons for this - eg. underlying
    comms. failures, although other comms. appears reliable).
  - The frequency at which it tries to connect appears to be all over the
    place, sometimes its minutes, at other times its hours.
    Is there some algorithm it uses that can be explained?
    I would like to use this machine as a reference point for other
    machines (our main requirement is that all our machines show the same
    time - within a second). Using ntpd on another machine seems to show
    similar symptoms as above - the server (our own machine this time, using
    udp rather than OSI) doesn't always respond, and the client tries at
    varying intervals to connect.
    Is there any documentation that explains this behaviour?

(2) ntp - this produces a one-off "client" request, displaying the results
    on the screen, with the option of updating the system clock.
    I'm considering the idea of running this at regular intervals via cron,
    rather than using ntpd as a client, because at least I can predict its
    behaviour. However, the ntpd daemon on our server machine sometimes
    refuses to respond to the packets - again, to my untrained eye, it just
    randomly seems to stop and then start again. Does anybody know why?
    Can I make it always respond?
    Another point here is that the "set time" option uses "settimeofday"
    (which is unacceptable to us, as it potentially causes problems with
    log file timestamps being out of order - with disastrous consequences
    for our Ingres systems) rather than "adjtime" to adjust the clock.
    Is there a version out there that uses "adjtime", or do I need to write
    my own?

Apologies for asking so many questions, but I really need to know more
about this before I can justify using this method (which seems, in theory,
to be ideal) to keep our machines in step.

Many thanks,
Roger Gander

Newsgroups: comp.protocols.time.ntp