From: "Greg" <schueman@ix.netcom.com> [-/+]
Date: 22 Jul 1997 19:40:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Windows NT [-/+]
X-Keywords: implementation [-/+] Windows [-/+]
XNTP 3-5.90.3 binaries for Windows NT can be found at:
ftp.drcoffsite.com
Send email to <access@drcoffsite.com> for instructions on how to login.
-Greg Schueman
Francesco S. Di Ridolfo <diridolfof.aica@iol.it> wrote in article
<33D3A4E2.64F9@iol.it>...
> I am searching for a NTP implementation for Windows NT 4.
> Some idea?
>
> Bye
>
> Francesco S. Di Ridolfo
>
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 21 Jul 1997 18:06:13 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Recommendations? [-/+]
X-Keywords: configuration [-/+] dispersion [-/+] peer [-/+] TrueTime [-/+]
This is the way I'd do it...
Each of the three campuses should appoint one machine to act as its
local time server. The three servers talk to each other as "peer"s
but they are at different strata (for technical reasons, the strata
should differ by 2, not by 1) for example, as strata 8, 10, and 12.
All the other machines should list all three as "server"s.
The reason for putting them at relatively high strata (rather than
strata 1, 3, 5, for example) is to prevent polluting the internet with
bogusly low stratum cronons if you ever get connected to the intenet
at large.
The reason for putting the three servers at deferent strata is to
prevent the clients from getting confused by having three supposedly
authoritative servers, each giving different times. Two machines,
both at the same stratum, that have each other configured as "peers",
will each say "My stratum is at least as good as his, so I'll believe
myself rather than him. Since I'm closer to myself than I am to him,
I'm of lower dispersion than he is. Consequently, they will ignore
each other and drift apart over time, unless they are both synched to
the same lower stratum source of cronons.
The reason for having three servers is simple redundancy. If one of
them goes down, the other two will take up the slack. If either the
stratum 10 or 12 machine goes down, the stratum 8 will still provide
an "ultimate" time source for the network. If the stratum 8 goes
down, the stratum 10 will take over in a smooth transition because it
was synced to the stratum 8 before it went down.
However, what I'd actually do is make a _strong_ recommendation to my
management to buy a GPS/NTP network clock-server machine - something
like the TrueTime NTS-100. Anybody who can afford 60 UNIX machines,
and the high-speed networking to connect 12 campuses together, can
afford US$4000 to keep their clocks ticking to UTC.
If you're only talking about a couple of hundred machines in the
ultimate configuration, don't worry about overloading your network or
your sratum 8 server. Any reasonably modern machine running the
latest xntp3 daemon can handle several hundred clients without raising
a sweat. If you're talking about thousands of machines eventually
being connected, you will want to look into a more heirarchical
configuration.
Rick Thomas, Associate Director, Computing Facility
Laboratory for Computer Science Research; CoRE Building;
Busch Campus; POBox 879; Piscataway, NJ 08855-0879
Phone:732-445-4301 Fax:732-445-0538 E-mail:rbthomas@rutgers.edu
WWW: <http://www.cs.rutgers.edu/~rbthomas> (PGP key info is here)
PGP Fingerprint: 9F CE FC 0E 2F AF 2D 38 80 DA C1 0D 4C DE F1 79
From: ljs@Delmarsol.COM
Date: Mon, 21 Jul 1997 02:24:12 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Recommendations? [-/+]
X-Keywords: synchronized [-/+]
Any recommendations on a good NTP architecture for the below
network?
The objective is to have all systems roughly time-synchronized
(within a second is fine), via NTP.
The time source will be one machine, which is defined as the
reference clock, using the LOCAL_CLOCK, rather than radio
clock or Internet.
There are 3 separate campuses (Campus A, Campus B, and Campus C), with
each campus being in a different city.
All campuses are connected to each other via a 64kb or higher speed
WAN.
Each Campus has 3 SUB-campuses EACH. Each of these Sub-campuses are in
different cities.
The campuses and sub-campuses are connected via high speed
leased lines.
Each site has 4 machines.
+-------------------------------------+
| |
+----+------+ +----------+ +----------+
| Campus A |-------| Campus B |-----| Campus C |
|LOCAL_CLOCK| | | | |
+-----------+ +----------+ +----------+
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
Sub- | | | | | | | | |
Campuses: 1 2 3 4 5 6 7 8 9
It'll start off to be a small network, with a total of 60 machines:
5 UNIX machines in each campus
(5 machines * 3 campuses = 15 machines)
5 UNIX campus in each Sub-campus
(5 machines * 9 sub-campuses = 45 machines)
Total machines: 15 + 45 = 60
Thanks for any advice you have.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 23 Jul 1997 16:39:58 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Recommendations? [-/+]
X-Keywords: configuration [-/+] fudge [-/+] peer [-/+] prefer [-/+]
John Gregson raises the extended question of how to fit a GPS/NTP
machine into the scheme I suggested.
The answer is to use exactly the same configuration as I described,
with one simple addition.
To summarize, the described config is three Unix servers, each with
its own localclock (at high, staggered strata) configured as a
potential server, and the other two servers listed as peers.
The addition is to configure the GPS/NTP machine as stratum 0, and
have all three of the Unix servers list it as a server. This way,
when the GPS/NTP machine is up, all the Unix servers will sync to it,
and ignore their own localclocks. When the GPS/NTP machine goes down
(or insane) the Unix servers will fall back to the localclock of the
surviving one of them at the lowest stratum.
It's easier to give an example than it is to explain.
GPS-NTP-box is configured to be stratum 1 and accept connections
from each of UnixServerA, UnixServerB, and UnixServerC.
UnixServerA:ntp.conf
server GPS-NTP-box prefer
peer UnixServerB
peer UnixServerC
server 127.127.1.0
fudge 127.127.1.0 stratum 8
UnixServerB:ntp.conf
server GPS-NTP-box prefer
peer UnixServerA
peer UnixServerC
server 127.127.1.0
fudge 127.127.1.0 stratum 10
UnixServerC:ntp.conf
server GPS-NTP-box prefer
peer UnixServerA
peer UnixServerB
server 127.127.1.0
fudge 127.127.1.0 stratum 12
EverybodyElse:ntp.conf
UnixServerA:ntp.conf
server UnixServerA
server UnixServerC
server UnixServerB
Enjoy!
Rick
> Date: Wed, 23 Jul 1997 10:39:34 +0100
> From: John Gregson <John.Gregson@nomura.co.uk>
> Organization: Nomura Research Institute
> To: rbthomas@rutgers.edu
> Subject: xntp
>
> Hi,
>
> I saw your knowledgeable reply to the "recommendations" posting on the
> ntp newsgroup and am hazarding a direct question.
>
> I am planning an ntp setup with an internal GPS/NTP machine in a network
> which will have no ntp connectivity to the internet. I want to create a
> second level of machines that serve the rest of the clients and act as
> redundant servers should the GPS machine fail. So
>
> * gps - stratum 1
> * 3 Unix boxes (running xntp3) syncing to the gps and acting as peers
> to each other
> * xxx clients syncing to the 3 Unix boxes.
>
> Now here's the rub; if I pull the plug on the gps machine then the 3
> boxes sync with each other but gradually lower their stratum levels to
> 16 at which point they become useless to their clients. What have I
> missed here?
>
> I'm thinking of an alternative setup with both a Unix box at stratum 1
> (on its own clock) and the GPS machine - the latter being "preferred" by
> its clients.
>
> Any comments? (and thanks in advance).
>
> John.
>
> ----------------------------------------------------------------------
> John.Gregson@nomura.co.uk | Unix Infrastructure, Nomura
> London
> ----------------------------------------------------------------------
> The views expressed herein do not necessarily reflect the views of
> Nomura International plc and cannot be relied upon by any other party.
> Nomura International plc is a member of the London Stock Exchange and
> is regulated by The Securities and Futures Authority
> ----------------------------------------------------------------------
From: "Marc Brett" <Marc.Brett@waii.com> [-/+]
Date: 21 Jul 1997 13:32:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: caesium [-/+] DCF77 [-/+] IERS [-/+] NIST [-/+] synchronised [-/+] TAI [-/+]
L. F. Sheldon, Jr. <lsheldon@creighton.edu> wrote:
> On 18 Jul 1997, Paul Eggert wrote:
> > James Youngman <JYoungman@vggas.com> writes:
> >
> > > When was UTC introduced?
> >
> > The current UTC system was introduced at 1972-01-01 00:00:00 UTC.
> >
> > The previous system was also called `UTC' but it operated differently;
> > each day had 24*60*60 seconds, but periodically the clock
> > frequency was adjusted, so that civil seconds in one period would have a
> > slightly different length from civil seconds in the next period.
> >
> > > Before that, did GMT have leap-seconds with respect to TAI?
> >
> > No. The first leap second was 1972-06-30 23:59:60 UTC.
> OK, I'll do it. I was hoping somebody else would, but . . . .
> I am a ROF who (still) thinks "GMT" is the base of All That Is True.
> What is "TAI" (besides a strange dance I see young folk doing on
> occasion)?
GMT is as obsolete as the British Empire. A good idea at the time, but
completely eclipsed by modern realities. Depending on who you talk to,
GMT might mean either UTC, UT, or UT2. Best not to use it at all. The
following 2 articles (written by others, I hasten to add) should explain
things better than I ever could.
[MB] Here's one repost...
------------------------------
RISKS-LIST: Risks-Forum Digest Wednesday 14 May 1997 Volume 19 : Issue 14
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
------------------------------
~Date: Mon, 28 Apr 1997 09:36:11 +0100
~From: "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
~Subject: A definitive clarification of time measurement
Peter Ladkin, Universitaet Bielefeld, Technische Fakultaet, Postfach 10 01 31,
D-33501 Bielefeld, Germany http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326
(From John Laverty via Peter Ladkin)
In Britain, the National Physical Laboratory is the canonical site for
questions concerning standard time, and the Royal Greenwich Observatory
(which is now in Cambridge) refers all questions there. I talked to
Dr. John Laverty of Time and Frequency Services, CETM (jrl@taf.npl.co.uk),
who kindly supplied me with the following account of time standards.
The position of the sun in the sky has been used as a basis for measuring
time for many centuries. One simple example is that 12 noon in local solar
time occurs when the sun is directly `overhead'. However, local solar time
does not provide as uniform a time scale as that based more implicitly on
the rotation of the Earth about its axis. The Earth's orbit is elliptical
and its axis tilted, so that the actual position of the sun against the
background of stars appears a little ahead or behind the expected position.
The accumulated error varies from 14 minutes slow in February to 16 minutes
fast in November. These effects can be predicted, and a more uniform
timescale can be established on the basis of a hypothetical 'mean' sun that
moves with uniform speed across the sky. Greenwich Mean Time (GMT) is
probably the most well known example of such a time scale: GMT is the local
time on the Greenwich meridian based on the position of a hypothetical mean
sun.
The need to coordinate time measurement and agree on a standard time was
driven by improved communications, particularly by the railways, when the
differences in the local time at different locations became very noticeable.
Greenwich Mean Time was established as a world time standard at the
International Meridian Conference in 1884. The time scales in active use
today are Universal Time (UT), Coordinated Universal Time (UTC) and
International Atomic Time (TAI). They are described below along with some
of the reasons for their use.
Greenwich Mean Time (GMT) and Universal Time (UT) are very closely related.
Before 1925 January 1, the twenty four hour GMT day was taken to commence at
noon, while since that date the convention has been for the GMT day to begin
at midnight. The term Universal Time (UT) was introduced in 1928 by
astronomers to denote GMT measured from Greenwich Mean Midnight, to be clear
about the convention for the start of the day.
Now there are actually three different definitions: UT_0, UT_1, UT_2 (using
underscores to denote subscripting). UT_0 is based on `direct' observation
of the earth's rotation on the prime meridian, UT_1 is adjusted to account
for the small movements of the Earth relative to the axis of rotation (polar
variations), and UT_2 adjusts for seasonal variations. The maximal
difference between all three is of the order of a few tens of milliseconds.
The term `UT' thus crudely refers to all three for large granularities, and
for finer granularity, the term is ambiguous and one needs to specify which
of the UT's one is referring to.
Starting in the 1930's with the development of quartz crystal oscillators,
but particularly in the 1950's with the introduction of atomic clocks,
better measurements have been available. As a consequence of studies
comparing atomic clocks and astronomical observations, it was realised that
atomic clocks offered a more much more stable time standard than one based
on the rotation of the Earth. In 1967, the SI second was redefined as "the
second is the duration of 9192631770 periods of the radiation corresponding
to the transition between the two hyperfine levels of the ground state of
the caesium 133 atom". The international time scale based on the SI second
is International Atomic Time (TAI). TAI was synchronised with UT at the
beginning of 1958. It is a more stable time scale than UT, but UT and TAI
naturally drift apart because they are based on different principles.
Universal Coordinated Time (UTC) is a compromise between TAI and UT and was
established in its current form on 1 Jan 1972. It uses the SI definition of
the second, but introduces leap seconds by convention in order that the
difference between UTC and UT shall never be more than one second. There
have been 20 leap seconds introduced since January 1972; the first at 1 July
1972. The 21st leap second is scheduled for 1 July 1997. So UTC and TAI run
in lockstep, but with conventional separation, which is now 30 seconds and
will become 31 seconds on 1 July 1997 (By the beginning of 1972 TAI and UT
had drifted apart by 10 seconds from the `synchronisation' point at the
begining of 1958, which accounts for the extra 10 seconds in addition to the
leap seconds). UTC is the current world time standard, as indicated by the
recommendations of the International Telecommunications Union (ITU) for
example.
There are some 50 or so centers around the world which measure TAI/UTC using
commercial atomic clocks, with just a few laboratory based 'primary' caesium
standards which are are able to measure the time with greatest accuracy.
The PTB in Germany has the distinction of having the longest running and
most reliable primary caesium standards. The NPL, having developed the
first caesium atomic clock in the 1950's, is currently working on the `next
generation' standard based on the caesium fountain method demonstrated at
the LPTF in Paris. There are other primary caesium standards at NIST in the
US, NRC in Canada, CRL in Japan and in Moscow. The institute responsible
for maintaining TAI and UTC is the BIPM in Paris, and the decision as to
when to introduce leap seconds is made by the IERS, also in Paris, who
measure UT also.
The Royal Greenwich Observatory (RGO) no longer maintain their own time
standard. It is recognised that GMT and UT are equivalent, so that now the
IERS provide the information necessary to determine GMT. However, the
appropriate definition of UT should be used instead of GMT if the
distinction between UT_0, UT_1 and UT_2 is important for a given
application.
The time standards that are so carefully measured by astronomers and
metrologists need to be made available if they are to be of use, and radio
time signals are one of the most common ways of making UTC available. In
Western Europe, NPL broadcasts the UK time on 60 kHz from the BT Radio
Station at Rugby (call sign MSF), and similarly, the PTB broadcasts Central
European Time from Frankfurt (call sign DCF77) on 77.5 kHz. There are
similar transmitters operated by other countries around the globe. The
other common means of accessing standard time is through the Global
Positioning System (GPS) navigation system, where accurate position and time
information allow a receiver to calculate its position from the times of
flight (at the speed of light) of signals from a number of GPS satellites.
The GPS system was developed, as its name implies, for positioning, but a
welcome spin-off is accurate time. The GPS time signals offer high-accuracy
UTC (one microsecond time accuracies are readily achievable) and global
coverage, but the LF radio time signals, although limited to a range of
typically 1500 km, offer the advantage of broadcasting the local time
including summertime changes (to millisecond time accuracies).
------------------------------
[MB] And another...
------------------------------
In article <slrn5moo6h.47d.paul@wit387304.student.utwente.nl>,
Paul Boven <e.p.boven@student.utwente.nl> wrote:
TAI = International Atomic Time. Defined by about a dozen atomic clocks
distributed worldwide.
UTC = Coordinated Universal Time. Differs from TAI by an integral
number of seconds. When needed, leap seconds are introduced in UTC
to keep the difference between UTC and UT less than 0.9 s.
UTC was introduced in 1972.
UT = Universal time. Defined by the Earth's rotation, and determined
by astronomical observations. This time scale is slightly irregular.
There are several different definitions of UT, but the difference
between them is always less than about 0.03 s. Usually one means
UT2 when saying UT. UT2 is UT corrected for pole wandering, and
seasonal variations in the Earth's rotational speed.
ET = Ephemeris Time. Was used 1960-1983, and was replaced by TDT and TDB
in 1984. For most purposes, ET up to 1983 Dec 31 and TDT from 1984
Jan 1 can be regarded as a continuous time-scale.
TDT = Terrestial Dynamical Time. Used as a time-scale of ephemerides
from the Earth's surface. TDT = TAI + 32.184. Formerly called
ET, Ephemeris Time.
TDB = Barycentric Dynamical Time. Used as a time-scale of ephemerides
referred to the barycentre of the solar system. Differs from TDT
by at most a few milliseconds.
TT = Terrestial Time. Used instead of TDT or TDB when the difference
between them doesn't matter.
GMT = Greenwich Mean Time. It's ambiguous, and is now used (although
not in astronomy) in the sense of UTC in addition to the earlier
sense of UT. Prior to 1925, it was reckoned for astronomical
purposes from Greenwich mean noon (12h UT)
TDT = TAI+32.184s ==> UT-UTC = TAI-UTC - (TDT-UT) + 32.184s
Starting at TAI-UTC TDT-UT UT-UTC
1972-01-01 +10 +42.23 -0.05
1972-07-01 +11 +42.80 +0.38
1973-01-01 +12 +43.37 +0.81
1973-07-01 " +43.93 +0.25
1974-01-01 +13 +44.49 +0.69
1974-07-01 " +44.99 +0.19
1975-01-01 +14 +45.48 +0.70
1975-07-01 " +45.97 +0.21
1976-01-01 +15 +46.46 +0.72
1976-07-01 " +46.99 +0.19
1977-01-01 +16 +47.52 +0.66
1977-07-01 " +48.03 +0.15
1978-01-01 +17 +48.53 +0.65
1978-07-01 " +49.06 +0.12
1979-01-01 +18 +49.59 +0.59
1979-07-01 " +50.07 +0.11
1980-01-01 +19 +50.54 +0.64
1980-07-01 " +50.96 +0.22
1981-01-01 " +51.38 -0.20
1981-07-01 +20 +51.78 +0.40
1982-01-01 " +52.17 +0.01
1982-07-01 +21 +52.57 +0.61
1983-01-01 " +52.96 +0.22
1983-07-01 +22 +53.38 +0.80
1984-01-01 " +53.79 +0.39
1984-07-01 " +54.07 +0.11
1985-01-01 " +54.34 -0.16
1985-07-01 +23 +54.61 +0.57
1986-01-01 " +54.87 +0.31
1986-07-01 " +55.10 +0.08
1987-01-01 " +55.32 -0.14
1987-07-01 " +55.57 -0.39
1988-01-01 +24 +55.82 +0.36
1988-07-01 " +56.06 +0.12
1989-01-01 " +56.30 -0.12
1989-07-01 " +56.58 -0.40
1990-01-01 +25 +56.86 +0.32
1990-07-01 " +57.22 -0.04
1991-01-01 +26 +57.57 +0.61
1991-07-01 " +57.94 +0.24
1992-01-01 " +58.31 -0.13
1992-07-01 +27 +58.72 +0.46
1993-01-01 " +59.12 +0.06
1993-07-01 +28 +59.55 +0.63
1994-01-01 " +59.98 +0.20
1994-07-01 +29 +60.38 +0.80
1995-01-01 " +60.78 +0.40
1995-07-01 " +61.2 0.0
1996-01-01 +30 +61.6 +0.6
1996-07-01 " +62.0 +0.2
1997-01-01 " +62.4 -0.2
1997-07-01 +31 +62.8 +0.4
For the latest status concerning leap seconds in UTC, send e-mail to
adsmail@tycho.usno.navy.mil with a Subject: line of 'leap' and no
text. You will receive in reply a list of past and provisional future
leap seconds.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch@saaf.se paul.schlyter@ausys.se paul@inorbit.com
WWW: http://spitfire.ausys.se/psr -- updated daily!
LEAP SECONDS ARE ANNOUNCED IN TIME SERVICE ANNOUNCEMENT (TSA) SERIES 14
AS SOON AS NOTIFICATION IS RECEIVED FROM THE CENTRAL BUREAU OF THE
INTERNATIONAL EARTH ROTATION SERVICE (IERS). SUCH NOTIFICATION OCCURS
8 TO 10 WEEKS IN ADVANCE. IF A LEAP SECOND IS TO OCCUR, THE PREFERRED
DATES ARE 1) DECEMBER 31 OR 2) JUNE 30. IF REQUIRED, A LEAP SECOND
MAY BE ANNOUNCED FOR EITHER MARCH 31 OR SEPTEMBER 30. ALL LEAP SECONDS
OCCUR AT 23H 59M 60S UTC.
------------------------------
--
Marc Brett +44 181 560 3160 Western Atlas
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB England
From: Christopher Spry <cspry@sghms.ac.uk>
Date: Thu, 24 Jul 1997 10:24:06 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Setting the time in IRIX to a 'time server'
X-Keywords: dialup [-/+] SGI [-/+]
Micah Freedman wrote:
> My SGI looses 2-3 min/day. I'd like to setup it up to get the time from
> somewhere....
There are at least three ways to set the time on an SGI computer to one or
more ‘time servers’.
(a) ‘timeslave’ See the man pages.
(b) ‘timed’. See the man pages. Use ‘chkconfig’ to see if (a) or (b) are
running and to turn them on and off.
(c) xntpd. There is useful information on ‘xntpd’ at
http://www.umbc.edu/pdsrc/docs/xntpd-html/index.html.
I use (c) on my networked Indy. I have no experience of using a PPP dialup
script for this purpose.
From: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) [-/+]
Date: 22 Jul 1997 19:25:50 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: timezone [-/+]
In article <33D4F772.41C67EA6@utcc.torontou.edu>,
Harald Koch <chk@utcc.torontou.edu> wrote:
>Calling it UTC is also misleading in that no UNIX system I'm aware of
>keeps track of leap-seconds.
All systems which use the Arthur Olson timezone code are capable of
dealing with leap seconds. However, because POSIX botched the
definition of time_t values, standards-compliant systems are not
permitted to use this support.
The Olson code also included a pair of functions to perform the
mapping between time_t values following the POSIX definition, and
those defined sensibly. Unfortunately, that still doesn't help; the
standard is simply broken.
One thing which the Olson code can't do is deal with the pre-UTC
timescale (since the Epoch is 1970, not 1972). It's a pity ken and
dmr were unable to anticipate the need to handle leap seconds....
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
From: The Browns <suneedle@erols.com> [-/+]
Date: Thu, 24 Jul 1997 18:49:45 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: setting backup stratum [-/+]
X-Keywords: peer [-/+]
Tim Anderson wrote:
>
> Does anyone know how to configure xntpd to have a "fallback"
> stratum if the server goes down?
>
> For instance, when my stratum 1 server goes down, the stratum 2
> servers become stratum 16. When this happens, none of the systems
> get time updates.
> If my S1 server goes down, I want my S2 servers to take over at,
> say, stratum 4...
>
Don't rely on a single source of time, even if it's your own. Your
stratum 2 servers can also peer with a couple different stratum 2
servers on the internet. They can also peer with one another if the're
all using different sources. All that backup gives you protection
against outages and insanity, while your well-calibrated stratum one
server gives you accuracy.
--Jerry Brown
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 25 Jul 1997 16:50:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: setting backup stratum [-/+]
X-Keywords: DTS [-/+] fudge [-/+] prefer [-/+]
Tim Anderson (tim.anderson@sanjose.vlsi.com) wrote:
: Does anyone know how to configure xntpd to have a "fallback"
: stratum if the server goes down?
: For instance, when my stratum 1 server goes down, the stratum 2
: servers become stratum 16. When this happens, none of the systems
: get time updates.
: If my S1 server goes down, I want my S2 servers to take over at,
: say, stratum 4...
: I am using xntpd in the following config:
: - 1 stratum 1 server connected to a clock
: - 5 stratum 2 servers
: - several stratum 3 servers
: - everyone else is on stratum 4
: ----------------------------------------------------------------
: Tim J. Anderson | Magicians cannot be killed,
: tim.anderson@sanjose.vlsi.com | they just become
: Sr. UNIX Administrator | Metaphysically Challenged
: ----------------------------------------------------------------
Howdy,
Having about 3 sources of time is very nice, but to keep your world
ticking when the outside link goes down (without a radio clock), add:
server 127.127.1.0 # local clock fallback
fudge 127.127.1.0 stratum 10 # show poor quality
to the top NTP server's ntp.conf. Kill and restart.
Watchout for the prefer keyword in a local refclock line. It
has several different effects. Unless you have prefer, the local
refclock will NOT be used as a source for broadcasts or multicasts.
With prefer, the xntpd will NOT make the drift adjustments. I
suggest NOT using prefer unless the local refclock is disiplined by
some other system (DTS, lockclock, etc.).
When the outside link dies, the top server in your world will fall
to stratum 11 ( one beyond the fudge ) and it will give out its
OS time in respose to NTP queries. Without "prefer", the daemon
will keep making the drift adjustments, so a few seconds per
week kind of accuracy is possible. At least all the clients
will be togeather.
To have an alternate top server, step the fudge stratum by 2, so
the alternate will follow the top server when the outside is doa.
If the top goes down, the clients can still follow the alternate.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: mogul@actitis.pa.dec.com (Jeffrey Mogul)
Date: 25 Jul 1997 01:03:03 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Ultrix and ntpd
X-Keywords: dosynctodr [-/+]
In article <Pine.SUN.3.90.970722140302.12812A-100000@spof01.gsfc.nasa.gov>, Chris Raymond <raymond@spof01.gsfc.nasa.gov> writes:
|> My question is: is there some action I need to take a la
|> SunOS or Solaris "dosynctodr", to turn the system clock
|> wholly over to ntpd, or does Ultrix already do the right
|> thing? Does anyone know?
The ULTRIX ntpd daemon is NTP version 1, but aside from that
it basically does the right thing. And for almost all purposes,
NTP V1 is just fine.
We run a bunch of older ULTRIX systems, and they all seem to be
within a millisecond or so of our stratum-1 server.
As far as I know, you can also run recent versions of xntpd
on ULTRIX, but we've basically been leaving our ULTRIX systems
alone for several years (don't fix what ain't broke).
-Jeff
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 25 Jul 1997 16:37:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp on cisco 2500 [-/+]
X-Keywords: auth [-/+] broadcast [-/+] calendar [-/+] timezone [-/+]
Tatsuya Kawasaki (tatsuya@giganet.net) wrote:
: could you tell me the way to set up ntp on cisco?
: thnx in adv.
: tatsuya
Howdy,
Cicso routers IOS 10 and later have NTP built in. From comp.dcom.sys.cisco:
See Configuring NTP on CCO at:
http://www.cisco.com/univercd/data/doc/software/11_2/cfun/1csysmgt.htm
includes the NTP sections (last I looked).
Here are the NTP lines that are running on the departmental router near me:
clock timezone MST -7
clock summer-time MDT recurring
!
interface Ethernet1/0
ip address xxx.xxx.xx.254 255.255.255.0
ip broadcast-address xxx.xxx.xx.255
ntp broadcast
!
ntp clock-period 17179870
ntp update-calendar
ntp server xxx.xxx.xxx.1
ntp server xxx.xxx.yyy.1
The timezone and summer-time lines declare the local time details.
I've shown one ethernet to show how the b-cast is set up. I don't
think that authenticated b-cast can be sent, but I think the
Cicso has some auth for talking with servers.
The ntp clock-period xxxxxxx is generated by the router and shouldn't
be entered. It is the drift memory like ntp.drift file in xntpd.
The router guru tends to use IP#s not names, but I think either will
work. The IP# might work better if the DNS system was just waking
up when the router was booting.
The routing choices to the servers are saved somewhere. When a
T1 line got moved from this router to another without a full reboot,
the user packets learned the new path and worked, but the server
that used to go over the directly connected T1 link went unreachable
until it was unconfiged and configed anew.
If someone knows how to use authenticated b-cast, please chime in !
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 25 Jul 1997 21:07:11 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
X-Keywords: adjustment [-/+] Mills [-/+] panic [-/+] SNTP [-/+] stability [-/+]
In article <5rb34n$cmc@lilypad.rutgers.edu>,
Rick Thomas <rbthomas@lilypad.rutgers.edu> wrote:
>I'm not up on the math (Laplace Transforms and the theory of stability
>of Phase/Frequency locked loops) but I've heard it said that when you
>allow the dynamic adjustment of clock frequency while trying to keep
>the clocks in phase, the system goes wildly unstable (chaotic?).
>
>Anybody who really knows want to comment? Dr Mills?
That is effectively the case. The modern salary slave is supposed to
work in a state of suppressed panic - NTP works in a state of suppressed
chaotic instability.
It is easy to design stable NTP-like algorithms (my SNTP client uses one
such), but you have to use different criteria. You can't optimise for
everything at once.
TANSTAAFL, in fact.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
From: Simon Leinen <simon@limmat.switch.ch>
Date: 28 Jul 1997 13:35:34 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp on cisco 2500 [-/+]
X-Keywords: auth [-/+] broadcast [-/+]
bwb@etl.noaa.gov (Bruce Bartram) writes:
> interface Ethernet1/0
> ip address xxx.xxx.xx.254 255.255.255.0
> ip broadcast-address xxx.xxx.xx.255
> ntp broadcast
> [...]
> I've shown one ethernet to show how the b-cast is set up. I don't
> think that authenticated b-cast can be sent, but I think the
> Cicso has some auth for talking with servers.
You can send authenticated broadcast NTP packets using
interface iiiii
ntp broadcast key xx
ntp authentication-key xx md5 yyyyyyyy
--
Simon.
From: Matthew.Healy@yale.edu (Matthew D. Healy)
Date: Fri, 25 Jul 1997 15:53:00 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
In article <5r6f05$f4a@electra.saaf.se>, pausch@electra.saaf.se (Paul
Schlyter) wrote:
...
>
> For the latest status concerning leap seconds in UTC, send e-mail to
> adsmail@tycho.usno.navy.mil with a Subject: line of 'leap' and no
> text. You will receive in reply a list of past and provisional future
> leap seconds.
Um, that one is a tad out of date; here's the last few lines of the
reply I got from that robot:
: 1994 JUN 30 NO. 56
:
:
:Note: The last leap second occurred June 30, 1994.
: As of June 30, 1994 there has been a total of 19 leap seconds.
:
:
:Fri Aug 26 14:42:53 utc 1994
:
On the other hand, here are some URLs to more recent data:
http://tycho.usno.navy.mil/gps_datafiles.html
ftp://maia.usno.navy.mil/ser7/tai-utc.dat
ftp://tycho.usno.navy.mil/pub/series/ser14.txt
ftp://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE
ftp://maia.usno.navy.mil/ser7/deltat.preds
--------
Matthew.Healy@yale.edu http://ycmi.med.yale.edu/~healy/
As of 09 Jul 1997, only 905 days until Y2K....
Any person with a phone line can become a town crier with a voice
that resonates farther than it could from any soapbox.
--The US Supreme Court, overturning the Communications Decency Act
From: "Dr Thomas A Clark (W3IWI)" <clark@tomcat.gsfc.nasa.gov>
Date: Tue, 29 Jul 1997 17:13:39 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: adjustment [-/+] TAI [-/+]
> > In article <wkracwtm9n.fsf@vggas.com>, James Youngman <JYoungman@vggas.com> writes:
> >
> > : When was UTC introduced?
> >
> > Not quite sure. The first leap second was in 1972, but the TAI-UTC table
> > at ftp://maia.usno.navy.mil/ser7/tai-utc.dat goes back to 1961.
> > However the difference was not an integral number of seconds before
> > 1972 and was expressed as a time-dependent formula. On January 1st 1972
> > TAI-UTC was set at 10.0 seconds. It is currently 31.0 seconds.
> >
> >
> > : Before that, did GMT have leap-seconds with respect to TAI?
> > : (I checked the web and foind definitions but no indication of when
> > : these things were introduced).
> >
> > GMT has never had leap seconds, as it is defined by celestial observation,
> > and therefore tracks the Earth. These days GMT is loosely used as an
> > alternative name for UTC, but I'm not aware that the formal definition
> > of GMT has ever changed.
>
> GMT has never been precisely defined. Due to its usage as UT2 in some
> circumstances and UTC in others, it's ambiguous. It's an obsolete term,
> which should be replaced with UTC, UT0, UT1 or UT2, whenever you
> want an accuracy where the differences between the various UT's does
> matter.
Prior to 1972, the UT=GMT >>>RATE<<< was constantly adjusted to keep
in step with the earth's rotation. Every year or so, all the time-
keepers and observatories had to diddle the frequency on the
oscillator on their GMT clocks to keep in step. This was a real
nightmare! In 1972, UTC was defined as running at the TAI rate,
which happens to differ by ~2x10e-8 from the current rotational
speed of the earth. This means that once every 5x10e7 seconds,
the earth is out of step by ~1 second with TAI and a leap second
is introduced. Since 1 year ~ (pi)x10e7 seconds, the adjustment
is made about every 1.5 years (always Dec.31 or Jun.30 at 23:59:60
when it is done).
Tom Clark
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 27 Jul 1997 13:34:37 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: TAI [-/+]
In article <Matthew.Healy-2507971553000001@pudding.med.yale.edu>,
Matthew D. Healy <Matthew.Healy@yale.edu> wrote:
> In article <5r6f05$f4a@electra.saaf.se>, pausch@electra.saaf.se (Paul
> Schlyter) wrote:
>
> ...
>>
>> For the latest status concerning leap seconds in UTC, send e-mail to
>> adsmail@tycho.usno.navy.mil with a Subject: line of 'leap' and no
>> text. You will receive in reply a list of past and provisional future
>> leap seconds.
>
> Um, that one is a tad out of date; here's the last few lines of the
> reply I got from that robot:
>
> : 1994 JUN 30 NO. 56
> :
> :
> :Note: The last leap second occurred June 30, 1994.
> : As of June 30, 1994 there has been a total of 19 leap seconds.
> :
> :
> :Fri Aug 26 14:42:53 utc 1994
> :
>
> On the other hand, here are some URLs to more recent data:
>
> http://tycho.usno.navy.mil/gps_datafiles.html
>
> ftp://maia.usno.navy.mil/ser7/tai-utc.dat
>
> ftp://tycho.usno.navy.mil/pub/series/ser14.txt
>
> http://maia.usno.navy.mil/
>
> ftp://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE
>
> ftp://maia.usno.navy.mil/ser7/deltat.preds
Thanks for pointing this out -- I have modified my text accordingly.
--------------------------------------------------------------------
TAI = International Atomic Time. Defined by about a dozen atomic clocks
distributed worldwide. TAI-UT1 was approximately 0 on 1958 Jan 1.
UTC = Coordinated Universal Time. Differs from TAI by an integral
number of seconds. When needed, leap seconds are introduced in UTC
to keep the difference between UTC and UT less than 0.9 s.
UTC was introduced in 1972.
UT = Universal time. Defined by the Earth's rotation, and determined
by astronomical observations. This time scale is slightly irregular.
There are several different definitions of UT, but the difference
between them is always less than about 0.03 s. Usually one means
UT2 when saying UT. UT2 is UT corrected for pole wandering, and
seasonal variations in the Earth's rotational speed. We also have
UT1 (not corrected for seasonal variations) and UT0 (not corrected
at all).
ET = Ephemeris Time. Was used 1960-1983, and was replaced by TDT and TDB
in 1984. For most purposes, ET up to 1983 Dec 31 and TDT from 1984
Jan 1 can be regarded as a continuous time-scale.
TDT = Terrestial Dynamical Time. Used as a time-scale of ephemerides
from the Earth's surface. TDT = TAI + 32.184. Formerly called
ET, Ephemeris Time.
TDB = Barycentric Dynamical Time. Used as a time-scale of ephemerides
referred to the barycentre of the solar system. Differs from TDT
by at most a few milliseconds.
TT = Terrestial Time. Used instead of TDT or TDB when the difference
between them doesn't matter.
GMT = Greenwich Mean Time. It's ambiguous, and is now used (although
not in astronomy) in the sense of UTC in addition to the earlier
sense of UT. Prior to 1925, it was reckoned for astronomical
purposes from Greenwich mean noon (12h UT)
TDT = TAI+32.184s ==> UT-UTC = TAI-UTC - (TDT-UT) + 32.184s
Starting at TAI-UTC TDT-UT UT-UTC
1972-01-01 +10 +42.23 -0.05
1972-07-01 +11 +42.80 +0.38
1973-01-01 +12 +43.37 +0.81
1973-07-01 " +43.93 +0.25
1974-01-01 +13 +44.49 +0.69
1974-07-01 " +44.99 +0.19
1975-01-01 +14 +45.48 +0.70
1975-07-01 " +45.97 +0.21
1976-01-01 +15 +46.46 +0.72
1976-07-01 " +46.99 +0.19
1977-01-01 +16 +47.52 +0.66
1977-07-01 " +48.03 +0.15
1978-01-01 +17 +48.53 +0.65
1978-07-01 " +49.06 +0.12
1979-01-01 +18 +49.59 +0.59
1979-07-01 " +50.07 +0.11
1980-01-01 +19 +50.54 +0.64
1980-07-01 " +50.96 +0.22
1981-01-01 " +51.38 -0.20
1981-07-01 +20 +51.78 +0.40
1982-01-01 " +52.17 +0.01
1982-07-01 +21 +52.57 +0.61
1983-01-01 " +52.96 +0.22
1983-07-01 +22 +53.38 +0.80
1984-01-01 " +53.79 +0.39
1984-07-01 " +54.07 +0.11
1985-01-01 " +54.34 -0.16
1985-07-01 +23 +54.61 +0.57
1986-01-01 " +54.87 +0.31
1986-07-01 " +55.10 +0.08
1987-01-01 " +55.32 -0.14
1987-07-01 " +55.57 -0.39
1988-01-01 +24 +55.82 +0.36
1988-07-01 " +56.06 +0.12
1989-01-01 " +56.30 -0.12
1989-07-01 " +56.58 -0.40
1990-01-01 +25 +56.86 +0.32
1990-07-01 " +57.22 -0.04
1991-01-01 +26 +57.57 +0.61
1991-07-01 " +57.94 +0.24
1992-01-01 " +58.31 -0.13
1992-07-01 +27 +58.72 +0.46
1993-01-01 " +59.12 +0.06
1993-07-01 +28 +59.55 +0.63
1994-01-01 " +59.98 +0.20
1994-07-01 +29 +60.38 +0.80
1995-01-01 " +60.78 +0.40
1995-07-01 " +61.2 0.0
1996-01-01 +30 +61.6 +0.6
1996-07-01 " +62.0 +0.2
1997-01-01 " +62.4 -0.2
1997-07-01 +31 +62.8 +0.4
Earlier, one could get the latest status concerning leap seconds in
UTC by sending e-mail to adsmail@tycho.usno.navy.mil with a Subject:
line of 'leap' and no text. You would then receive in reply a list of
past and provisional future leap seconds. However, this site seems
to not have been updated since 1994. More up-to-date information
can be obtained among these sites (thanks to Matthew.Healy@yale.edu
for providing these URL's):
http://tycho.usno.navy.mil/gps_datafiles.html
ftp://maia.usno.navy.mil/ser7/tai-utc.dat
ftp://tycho.usno.navy.mil/pub/series/ser14.txt
ftp://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE
ftp://maia.usno.navy.mil/ser7/deltat.preds
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch@saaf.se paul.schlyter@ausys.se paul@inorbit.com
WWW: http://spitfire.ausys.se/psr -- updated daily!
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Mon, 04 Aug 1997 14:41:05 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
X-Keywords: jitter [-/+] prefer [-/+] stability [-/+]
Ulrich Windl wrote:
>
> In article <5qdn8a$ka3@lyra.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick
> Maclaren) writes:
>
> > There is also the point that it was designed for the networks of
> > the 1970s, where local clocks were usually mains-driven and grossly
> > erratic. Modern crystal clocks are pretty consistent (though they
> > may drift very badly), and it is possible to maintain excellent
> > accuracy with very much simpler algorithms.
>
> I'm no specialist on this, but I think that clocks clocked by mains
> frequency would be much more stable on the long-term than
> quartz-oscillators. At least in Germany the companies do
> phase-synchronize the whole electric network to minimize loss when
> switching sources. Maybe some even use NTP to synchronize, but I don't
> really know. (But I have a radio-clock at home that is clocked by
> mains; that one is rather stable over time)
You are both right:
The clock crystals used in our computers do indeed show quite good local
stability, especially when running in a server that's installed in a
temperature-controlled environment.
The bad thing about them is that they can (and usually do) drift a lot.
A case in point: A PC clock used to drift 3+ seconds/day. I wrote a
little program to take over all date/time related functions, and ran it
off the CMOS clock interrupt (which was supposed to happen once/second).
To calibrate my sw clock, I made two modem calls to a Swedish UTC
reference clock, on two successive days.
This sw clock had an accumulated error of just 0.06 seconds after
free-running for a week.
The mains-controlled clocks (at least those in Western Europe) OTOH will
show very good long-time stability, because the power grid makes sure
that the _average_ frequency is exactly 50 Hz.
The instantaneous frequency can and will drop below 50.0 Hz however,
whenever a large load is put on the grid: When this happens the
frequency will later go a little above norm to make the average correct.
I don't believe the power grid is good enough for NTP, which seems to
prefer sub-millicsecond jitter in the reference clocks.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: robin@acm.nospam.org (Robin O'Leary) [-/+]
Date: 6 Aug 1997 16:14:05 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
X-Keywords: broadcast [-/+] implementation [-/+] Mills [-/+] PPS [-/+] precision [-/+] TAI [-/+]
In article <5qddnt$m96$1@pheidippides.axion.bt.co.uk>, John Sager
<jcs@zoo.bt.co.uk> wrote:
> I now think that NTP should support TAI in some form. My previous view
> was that most NTP users needed UTC, so this should be the main offering,
> whereas TAI users, being much in the minority, should bear the pain of doing
> the conversion. However I now think that TAI will become increasingly
> sought after on the net.
Hooray! I hope John Sager's article will inaugurate the long-overdue
Campaign for Real Time!
I have always thought NTP should be based on TAI and provide UTC
as a correction. After all, as Dave Mills says in RFC1305, ``One of
the goals of this discussion is to provide a standard chronometry for
precision dating of present and future events in a global networking
community.'', but, without a crystal ball, UTC completely fails to
provide the ``future'' bit. It's daft we don't know how many
UTC seconds there will be in, say, the year 2000! Just comparing
sub-second time-stamps properly on systems governed by NTP is terribly
hard, as the system clock can jump backwards without telling you.
I'd love to see this semi-annual silliness scrapped.
As John says, it would be best to change the NTP internals to work in
TAI, with an adjunct mechanism to disseminate difference-from-UTC so
UTC can be reported where necessary. NTP should provide a way to log
changes in the difference in a form which would enable system or client
software to compute historical conversions between TAI and UTC. Just an
ever-growing text file of TAI/UTC difference values would be adequate.
Such a major change in convention would be unworkable without a
corresponding change in protocol: many broadcast time services offer only
UTC, so the interface for refclock drivers must be able to accept both
UTC and TAI; given the large installed base of NTP servers, the network
interface should also be able to cope with a mixture of UTC and TAI;
clients that ask NTP for the current time need to be able to get answers
in both TAI and UTC (though arguably this is something system software
should address). These problems can all be solved if the protocols
include fields to describe the time standard(s) used.
Timestamps should preferably be in both TAI and UTC (maybe as an offset),
but it must be possible to supply just one of the two, with an indicator
to say which. Then TAI+offset receivers (like GPS) and UTC+offset
receivers can fill in both sorts of time and claim them both present;
a UTC-only receiver can just fill in the UTC field and claim only to
know UTC; and a TAI-only refclock or an NTP server temporarily cut off
from a source of leap-second information but still having PPS inputs
would claim to know TAI but not UTC. This mechanism could be made even
more general by having a timescale indicator byte so new timescales
(or formats) could be supported in future.
What's more, with a bit of ingenuity and some filtering of abrupt
one-second steps in UTC-only higher-stratum servers, xntpd could switch
between servers which offer different sorts of time whilst preserving
or even deducing any missing fields from what has gone before.
This seems workable and better than what we have now. I haven't figured
out whether this needs to run on a separate port from the existing NTP
implementation, or whether the new fields can be added to the protocol
in a way that preserves backwards compatibility. To avoid any possible
confusion it would probably be safest to use a new port number for
TAI-based NTP.
Robin O'Leary.
--
<robin@acm.org> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.
From: djb@koobera.math.uic.edu (D. J. Bernstein) [-/+]
Date: 6 Aug 1997 20:53:21 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
X-Keywords: SNTP [-/+] TAI [-/+]
Robin O'Leary <robin@acm.nospam.org> wrote:
> Just comparing
> sub-second time-stamps properly on systems governed by NTP is terribly
> hard, as the system clock can jump backwards without telling you.
This point deserves emphasis. I've put together an introductory page
explaining TAI, UTC, UNIX time, and why the NTP timescale is bad:
http://pobox.com/~djb/proto/utc-harmful.txt
I also have a very simple UNIX SNTP client that lets you set your clock
to TAI---just tell it the TAI-UTC difference (currently 31):
http://pobox.com/~djb/clockspeed.html
And, for the foundation of a time system that won't break in the year
2036, I've put together some 64-bit and 128-bit time manipulation code,
including UTC-to-TAI conversion 100x faster than UNIX mktime():
http://pobox.com/~djb/libtai.html
Send an empty message to djb-libtai-subscribe@koobera.math.uic.edu to
join the libtai mailing list.
---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html
From: djb@koobera.math.uic.edu (D. J. Bernstein) [-/+]
Date: 7 Aug 1997 02:26:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
Typos corrected, and a note added about negative leap seconds:
http://pobox.com/~djb/proto/utc-harmful.html
---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html
From: zypher@kdsi.net (Ronald J. Burk)
Date: Tue, 05 Aug 1997 03:17:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Radio Clock & xntpd [-/+]
X-Keywords: compatible [-/+]
On Mon, 21 Jul 1997 15:52:05 -0700, "James W. Abendschan"
<jwa@jammed.com> wrote:
>
>I'm looking for a radio clock (presumably VHF, since the clock will
>sit inside of a locked room) that will tie to the serial port on
>a SPARCserver and provide time information to UNIX xntpd.
>
>Can anyone reccomend a vendor for an xntpd-compatible radio clock?
>
>James
>
>--
>James W. Abendschan jwa@jammed.com http://www.jammed.com/
>
Try posting in alt.horology. This is a get together ng for clock
vendors and others interested in clocks.
From: "John W. Edwards" <jedwards@accurate-automation.com>
Date: Tue, 05 Aug 1997 07:32:45 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Radio Clock & xntpd [-/+]
X-Keywords: broadcast [-/+] compatible [-/+] Garmin [-/+]
Ronald J. Burk wrote:
>
> On Mon, 21 Jul 1997 15:52:05 -0700, "James W. Abendschan"
> <jwa@jammed.com> wrote:
>
> >
> >I'm looking for a radio clock (presumably VHF, since the clock will
> >sit inside of a locked room) that will tie to the serial port on
> >a SPARCserver and provide time information to UNIX xntpd.
> >
> >Can anyone reccomend a vendor for an xntpd-compatible radio clock?
> >
> >James
> >
> >--
>
> Try posting in alt.horology. This is a get together ng for clock
> vendors and others interested in clocks.
Hmmm... aren't most of the radio broadcast on HF? Somthing else that I
have considered using here at the office is a cheap Garmin GPS unit on
the roof and a pair of low cost spread spectrum digital tranceivers...
your probably talking ~$800 or so (just a guess).
--
-------------------------------------------------------
John W. Edwards
Accurate Automation Corporation
jedwards@accurate-automation.com
Office - (423) 894 - 4646
-------------------------------------------------------
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 6 Aug 1997 17:56:09 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: debugging levels and logging
X-Keywords: dispersion [-/+] peer [-/+] RFC [-/+]
D. B. Karron (karron@casi.net) wrote:
: How can i watch ntp operate once installed to verify what it is doing ?
: D.
: --
: Dr. D. B. Karron
: Chief Technical Officer and Founder
: Computer Aided Surgery, Inc. (C.A.S.I.)
: 300 East 33rd Street, Suite 4N
: New York, New York, 10016
: e-mail: karron@casi.net
: voice : (212) 686 8748
: fax : (212) 448 0261
: http : //www.casi.net/
Howdy,
The "peek" tools are:
ntptrace [server] program that asks localhost or server about its
offset using the old version packets. It then
crawls up the NTP tree from the sync peer info
ntpdate -d <server> probes <server> and reports offset and dispersion.
-d uses high (un-privledged) ports, gives lots of
details and doesn't try to set the time.
ntpq [server] interactive or command line program to query
NTP servers using the RFC query format.
Popular commands include: ? (show avail commands)
peer, rv, assoc
xntpdc [server] interactive or command line program to query
NTP servers using the xntp query and control format.
This format might not make sense to NTP programs
other than xntpd. Popular commands include:
?, peer, sysi, showpeer <server>, monlist, authinfo
I learned to play with all of them, but I mostly use xntpdc.
I use "xntpdc -p" to take a quick peek at the xntpd server on localhost.
I'd use: "ntpdate -d <server>" and look at the return value and
response text to probe a server with a cron shell job to automatically
check to see if a server was running and at what stratum.
Bruce Bartram bbartram@etl.noaa.gov just anthter chimehead
From: "Marc Brett" <Marc.Brett@waii.com> [-/+]
Date: 7 Aug 1997 14:50:09 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Validating synchronization to 10ms [-/+]
X-Keywords: ACTS [-/+] configuration [-/+] documentation [-/+] maxpoll [-/+] minpoll [-/+] peer [-/+] poll [-/+] release [-/+] stability [-/+]
NTP doesn't use up much bandwidth or CPU, so a single UNIX workstation
can easily service 300+ clients with a load too small to be
measurable. I'm not sure how much "heart" your integrated GPS/NTP unit
has, but it'll probably manage just fine.
You may want to consider setting up one or more of your machines as
stratum 2 servers which feed the rest of the network. This will give
you some redundancy and flexibility for adding backup time sources.
There are "maxpoll" and "minpoll" parameters in the server and peer
keywords for limiting the range of polling intervals. Whether this
will give increased accuracy or stability is an open question. In our
experience poll time is not a great factor. Much more critical is the
loading (and subsequent asymetry) on the network. If the ping times
start to vary a lot, then your time differences will go up by a similar
amount. During the quiet times, the delta-t here is much much better
than 1 ms. However when the LAN is saturated, we can get much worse
than 10 ms for short periods of time.
You'd be well served by an arrangement like this:
* 3 stratum two servers,
* each stratum two server is in turn served by 3 independent
stratum one sources. These stratum one servers get time from
different time signals (say GPS, Omega, WWV, Loran, ACTS,
etc. Are there even 9???).
* Remaining clients get time from these 3 stratum two servers.
* Go with the default minpoll and maxpoll for all servers & clients
When the network loading gets very high (and irregular), then the clients
have three servers to choose from, and can make sane decisions about which
2 are the most reliable.
The second suggestion (9 radio clocks) is expensive, and clearly
overkill for most shops. However, if the 10ms delta-t is that
important to you, you might want to consider slotting another Ethernet
card into each of the stratum 2 servers, and have a dedicated NTP-only
wire connecting the GPS box with the 3 servers. That way, the ping
response times will be consistent despite the load on the centre's LAN.
Even that's expensive though. Better to fire up the system and see how
it behaves. You'll probably find that 10ms delta-t 95% of the time is
more than adequate for most needs.
PS: You can use "ntptrace", "ntpdate -d <server>", "ntpq", and "xntpdc"
for checking delta-t between machines.
Regards,
Marc "It's not *my* money" Brett
Brett Kettering <brettk@llnl.gov> wrote:
> In our final system we will have a closed network of many nodes.
> Current plans call for 13 UltraSPARC stations, 4 Enterprise 3000
> workstations, and 8 SPARC CPUs in VME chassises running whatever is the
> latest release of Solaris when we field. There will also be
> approximately 260 VME chassises with the latest version of VxWorks when
> we field.
> We have 1 network-based GPS time unit (with NTP server onboard in ROM)
> on the network with its own IP address. The goal is to ensure that all
> the nodes think it is the same time to within 10ms so that when logging
> is done by our widely distributed control system that an event can be
> tracked across computers with logs that have monotonically increasing
> time stamps.
> The current plan is for all these Solaris and VxWorks computers to use
> the GPS unit as the source of time in our system. Will this overload
> the GPS unit?
> I currently have two Solaris workstations synchronizing their time from
> the GPS unit. How do I validate that they have their system time set to
> within 10ms of each other? To this point I have just run the X/Motif
> "clock" application which shows the seconds ticking way together.
> I have read and re-read the configuration documentation and I still
> don't understand if there are parameters that I can set in the daemon
> (xntpd) to make it poll the GPS unit more or less frequently depending
> on how close I want the daemon to set the workstation's time to that of
> the GPS unit. Any pointers to a clear explanation of this?
> How does the frequency at which a daemon polls a time source guarantee a
> synchronization accuracy?
> Thanks,
> Brett
> --
> Views and opinions expressed are mine and not those of
> Lawrence Livermore National Laboratory.
--
Marc Brett +44 181 560 3160 Western Atlas
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB England
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 6 Aug 1997 16:05:31 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Broadcast problems w/Solaris 2.5.1 xntpd 3-5.90
X-Keywords: auth [-/+] broadcast [-/+] delay [-/+] driftfile [-/+] multicast [-/+] password [-/+] peer [-/+] trustedkey [-/+]
James Rippas (jrippas@fcmc.com) wrote:
: I'm unable to get a client to sync with a server broadcasting on its
: local net. I verify the broadcast packets with snoop, and I've enabled
: broadcastclient in the config file, but the client never syncs. If I
: add the name of the server to the config file the client syncs.
: /etc/ntp.conf cotains the following
: broadcastclient 192.129.91.255
: driftfile /etc/ntp.drift
: starting ntp with the following options;
: /usr/local/bin/xntpd -b -l /var/log/ntp.log
: Any help is appreciated.
: -jim
Howdy,
I suspect that you haven't noticed that authorization is default
enabled for broadcast and multicast since xntp3.5f (or so).
To make auth work, the server ntp.conf needs:
keyfile /usr/local/etc/ntp.keys # chmod 400 (has secrets !)
trustedkey 1 # need to be able to auth
# client delay probe
broadcast x.y.z.255 key 1 # and send with this key
enable auth # default on, just to remember
The client would need ntp.conf:
keyfile /usr/local/etc/ntp.keys
trustedkey 1
broadcast client
driftfile /usr/local/etc/ntp.drift # makes it wake up faster
To kill auth, on both server and client:
disable auth
or use the -A invocation switch.
Typical symptoms of bad auth include:
The server is listed in the client's xntpdc peer output, but reach == 0
I think this means it caught the b-cast, but didn't get the auth, or
it didn't get a decent response from the server when it tried to
measure the delay.
xntpdc authinfo show keys not found
A minimal ntp.keys file might be:
1 M password
I suggest using MD5 and making sure the keys are 8 characters. I got
confused once when I had a longer key and presumed only the 1st 8 chars
mattered. My memory is that it worked some but not always (old foggy
recollections).
Hope this helps.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: Chris Raymond <raymond@spof01.gsfc.nasa.gov> [-/+]
Date: Fri, 8 Aug 1997 18:24:22 -0400 (EDT) [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: tickadj gives error on Solaris 2.5.1 [-/+]
X-Keywords: adjustment [-/+] dosynctodr [-/+] nsec_per_tick [-/+]
Um, Casper?
I've got empirical evidence that it CAN be done on a SPARC10
running Solaris 2.5.1 with xntpd3-5.90. The -t argument needs
to be multiplied by 1000, so to get the desired "9999" value,
the syntax would be "./tickadj -t 9999000". In my case, I used
"./tickadj -t 10001000" because the drift value was rather high
and positive. This adjustment made it smaller and negative.
FYI, here's the results when I run "./tickadj" (no args):
KERNEL nsec_per_tick = 10001000 nsec
KERNEL tick = 10001 usec (from nsec_per_tick kernel variable)
PRESET tick = 10000 usec
dosynctodr is off
KERNEL hz = 100
calculated hz = 100.00 Hz
So it seems your blanket statement about Solaris 2.5.1 was not
correct.
Thanks,
Chris Raymond
On 7 Aug 1997, Casper H.S. Dik - Network Security Engineer wrote:
> Brett Kettering <brettk@llnl.gov> writes:
>
> >It was suggested to change the tick kernal variable to 9999 for Solaris
> >machines. Does anyone know why this is not working on our Solaris
> >machines? Is this not necessary with Solaris 2.5.1?
>
>
> Well, it's not possible with Solaris 2.5.1 and no alternative exists fo
> Ultras.
>
> It's interesting how much kernel tuning folklore exists.
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.
>
>