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
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
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
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?
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
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
http://maia.usno.navy.mil/
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?
> > 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?
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
http://maia.usno.navy.mil/
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?
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?
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?
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
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
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
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
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
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
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.
>
>
From: Chris Raymond <raymond@spof01.gsfc.nasa.gov>
Date: Sat, 9 Aug 1997 16:14:44 -0400 (EDT)
Newsgroups: comp.protocols.time.ntp
Subject: Re: tickadj gives error on Solaris 2.5.1
Hi Casper,
Okay, thanks for the correction. The net effect for this architecture
seems to be the satisfactory same, though.
Chris Raymond
On 9 Aug 1997, Casper H.S. Dik - Network Security Engineer wrote:
> Chris Raymond <raymond@spof01.gsfc.nasa.gov> writes:
>
> >KERNEL nsec_per_tick = 10001000 nsec
> >KERNEL tick = 10001 usec (from nsec_per_tick kernel variable)
<SNIP>
>
> Well, that's not "tick" but "nsec_per_tick" that you've changed (didn't
> know that tickadj had progress that far), but when I said:
>
> >> no alternative exists fo [sic] Ultras.
>
>
> I was correct. Ultras dp their clocks different and don't
> honor any kernel variable.
>
> (The clock ticks are derived from the %tick and %tick_cmpr register;
> and are so based directly on the systems clock frequency)
>
> 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.
>
>
From: "L. F. Sheldon, Jr." <lsheldon@creighton.edu>
Date: Wed, 6 Aug 1997 23:34:20 -0500
Newsgroups: comp.protocols.time.ntp
Subject: Re: Validating synchronization to 10ms
First and foremost we need to understand that I am not even close to
being an Authority on timekeeping, but I do have some ideas about this
situation.
On Wed, 6 Aug 1997, Brett Kettering 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 think it unlikely that it will be overloaded--but that is way off the
edge of my expertise, but I would think that if time is mission-critical,
you would want to have at least two high-quality time sources, so you
can break one, lose one, or have one isolated on the network without
reducing your source count to zero.
If at all possible, I'd include on the time-keeping network at least one
source from a distant point to provide a sanity check on your source(s).
It is not clear to me from your description what your intentions are,
but I would want as many machines running xntpd as you can to keep
things smooth, and to keep the network from wandering off in all directions
if you do lose your source.
> 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?
I don't think you can (or want to) adjust this--the daemons (if I under-
stand this stuff at all) will adjust their polling interval to the smallest
rate that they can and maintain stability.
> How does the frequency at which a daemon polls a time source guarantee a
> synchronization accuracy?
I think what "gaurantees" accuracy is allowing several daemons to
communicate with and cross-check each other--my belief is that this is
what the protocol is all about.
--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
. .
- L. F. (Larry) Sheldon, Jr. -
. Unix Systems Administration .
- Creighton University Computer Center-Old Gym -
. 2500 California Plaza .
- Omaha, Nebraska, U.S.A. 68178 We are all faced with -
. lsheldon@creighton.edu great opportunities .
- 402 280-2254 (work) brilliantly disguised as -
. 402 681-4726 (cellular) impossible situations. .
- 402 332-4622 (residence) -
. Bits and Pieces .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
From: rbthomas@lilypad.rutgers.edu (Rick Thomas)
Date: 8 Aug 1997 16:17:44 -0400
Newsgroups: comp.protocols.time.ntp
Subject: Re: What sort of synchronisation is "normal"?
ashtray@replicant.apana.org.au (John Newnham) writes:
>For reference, the xntpd which I run (and wish to improve)
>is on a 486 running linux, on a bursty and relatively
>low-bandwidth network, in a room of varying temperature.
>I am a competent unix admin, but I do not know the details
>of NTP. The daemon steps its clock at least twice a week,
>sometimes twice in one day (and I have tuned tickadj as
>finely as possible in order to achieve this). I have some
>ideas on how to improve things, but I was wondering what
>sort of result is considered "good", and what is "achieveable".
I'd guess that the main culprit is the bursty and relatively
low-bandwidth network. Not the room with varying temperature
or the tuning (or lack thereof) of tickadj.
If you can't improve the bandwidth of the network, there isn't much
you can do to avoid occasionally having your clock get stepped.
That said, there used to be a parameter in the code called something
like "SLEW_ALWAYS" that prevented stepping the clock by replacing it
with calls to adjtime that were somewhat more violent than the usual
ones used by xntpd. This at least prevented the clock from getting
set backwards by one or more seconds when things went bad. I'm not
sure if it's still there. You could grep the source for "SLEW" and
see what you find.
Rick
From: "Ishikawa,Chiaki,remove No Spam from the address"<ishikawa@personal-media.co.No.jp.Spam>
Date: 08 Aug 1997 17:14:03 +0900
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problem on xntp 3-5-90-export SunOS 4.1.4/Sparc 20
Hello,
My own follow-up:
It seems that the authentication option default setting has changed
between the releases.
A kind soul suggested that I may try putting "disable auth" on the
servers and see what happens because of these differences.
Voila, the client now is receiving time information from the gateway.
Also, I was advised to pick up the 3.-5.90.3-export, and so am running
it in the local LAN now.
Thank you!
--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142
From: Casper.Dik@Holland.Sun.COM (Casper H.S. Dik - Network Security Engineer)
Date: 9 Aug 1997 13:30:24 GMT
Newsgroups: comp.protocols.time.ntp
Subject: Re: tickadj gives error on Solaris 2.5.1
Chris Raymond <raymond@spof01.gsfc.nasa.gov> writes:
>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.
Well, that's not "tick" but "nsec_per_tick" that you've changed (didn't
know that tickadj had progress that far), but when I said:
>> no alternative exists fo [sic] Ultras.
I was correct. Ultras dp their clocks different and don't
honor any kernel variable.
(The clock ticks are derived from the %tick and %tick_cmpr register;
and are so based directly on the systems clock frequency)
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.
From: robk@oldtimer.win-uk.net (Robin Kimberley)
Date: Wed, 13 Aug 1997 15:42:09 GMT
Newsgroups: comp.protocols.time.ntp
Subject: Re: Radio Clock & xntpd
In article <>, Kevin Cousins (cousinsk@sg.adisys.com.au) writes:
>
>
>James> Can anyone reccomend a vendor for an xntpd-compatible radio clock?
>
>David> DATUM - use Datum Programmable Time System
>...
Kevin,
Why not take a look at Datum's TS2100 Network Time Server. GPS
front end, and NTP out on either AUI or 10baseT ethernet. All the
hard work has been done inside the "box". Just set up the IP
address and away you go!
Info available on Datum's Web site www.datum.com
We sell these units in the UK (very popular), but I believe the
Datum Rep in Australia is Scientific Devices Ltd (contact Graham
Sharpe?).
Good luck.
Rob Kimberley
Product Manager, Time and Frequency
Sematron UK Limited
Tel: ++44 1256 812 222
Fax: ++44 1256 812 666
Web: http://www.sematron.com
Mail: rkimberley@sematron.com
Home:-
Tel : ++44 1926 613 162
Fax : ++44 1926 613 775
Mail: robk@oldtimer.win-uk.net
From: "Marc Brett" <Marc.Brett@waii.com>
Date: 18 Aug 1997 11:58:45 GMT
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
Robin O'Leary <robin@acm.nospam.org> wrote:
> 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!
Sorry, but I must disagree with this "UTC considered harmful" bandwagon.
UTC is legal civil time in most of the world, and everything in people's
day-to-day lives synchronizes with it, not TAI. Computers are tools
which interface with peoples lives, and should, at least externally,
keep the same time as they do: UTC.
Translating from an internal representation of TAI to an external
representation of UTC adds an additional layer of complexity to the
system, and one more thing to go wrong. Who will maintain the TAI-UTC
offset? If it has to be done manually, then I guarantee it'll be done
wrong on some if not most systems. If it's centrally-distributed, who
will do it? As far as I know, only GPS is capable of distributing TAI
time (which by accident of design makes the TAI-GPS offset a constant).
WWV/WWVB/WWVL/WWVH (USA) can't do it. ACTS (USA) can't do it. DCF77
(Germany) and TDF (France) can't do it. CHU (Canada) can't do it. MSF
(UK) can't do it. GLONASS (Russia) can't do it. Not sure about LORAN
or OMEGA or GOES, but I doubt they can either. In these instances, the
offset will have to be sent "out-of-band", and no such broadcasting
mechanism exists today.
If you require that NTP carry the TAI-UTC offset, you have to get the
raw information from somewhere. You must either trust *only* GPS
receivers, or else trust the the thousands of human operators of the
radio receivers listed above to correctly program TAI-UTC offset every
time there is a leap-second event. Neither is a good option. Relying
solely on GPS introduces the possibility of a single point of failure
if the GPS system breaks down. Relying on thousands of unknown
operators, or even your own system administrator, for such an
infrequent and esoteric maintenance task is also unwise.
One of the nice things about NTP is its ability to draw on many
independent time sources. If you eliminate those time sources which
cannot distribute trustworthy TAI-UTC offsets, then at a stroke you
have eliminated most of of the robustness of the system.
For most users in most situations the leap second is a non-issue. It
breaks some things, but in most cases the applications and their users
are oblivious to it. Very few applications actually need the exact
number of seconds between events separated by years. Coarser time
measurements will usually suffice, and indeed are probably more
apropriate.
There will always exist people who need TAI, but they already have
software to cater to their needs. Their more exacting demands should
not burden the majority of users who only need and want 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: hughett@galton.psycha.upenn.edu (Paul Hughett)
Date: 18 Aug 1997 14:53:32 GMT
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
Marc Brett (Marc.Brett@waii.com) wrote:
: Robin O'Leary <robin@acm.nospam.org> wrote:
: > 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!
: Sorry, but I must disagree with this "UTC considered harmful" bandwagon.
: UTC is legal civil time in most of the world, and everything in people's
: day-to-day lives synchronizes with it, not TAI. Computers are tools
: which interface with peoples lives, and should, at least externally,
: keep the same time as they do: UTC.
: Translating from an internal representation of TAI to an external
: representation of UTC adds an additional layer of complexity to the
: system, and one more thing to go wrong. Who will maintain the TAI-UTC
: offset? If it has to be done manually, then I guarantee it'll be done
: wrong on some if not most systems. If it's centrally-distributed, who
: will do it?
[Several paragraphs of details omitted.]
: For most users in most situations the leap second is a non-issue. It
: breaks some things, but in most cases the applications and their users
: are oblivious to it. Very few applications actually need the exact
: number of seconds between events separated by years. Coarser time
: measurements will usually suffice, and indeed are probably more
: apropriate.
: There will always exist people who need TAI, but they already have
: software to cater to their needs. Their more exacting demands should
: not burden the majority of users who only need and want UTC.
Actually, as far as I know, both Unix and NTP use TAI internally and
convert to UTC only for external output to the users. The time in
Unix systems is kept as the number of seconds since the beginning of
1970; the exact definition of the second is not specified but is
presumably the atomic second. Thus, the Unix time variable is TAI
minus an offset equal to TAI at the beginning of the epoch.
Similarly, the time values passed around by NTP are also just the
number of second since the epoch, or TAI.
When you ask for the date in Unix, the system converts to YYYYMMDD
HHMMSS, including the necessary corrections for time zone, leap years,
daylight savings time, and leap seconds. Except for leap years, which
are hardwired into the code, this information is kept in a file
/etc/localtime (the location varies with different Unix systems);
information for other time zones is kept in /usr/lib/zoneinfo (again,
this varies). There is a program called zic which creates these
timezone files from a human-readable format.
Now, if you want your machine to express time in TAI externally as well
as internally, all you have to do is to create a TAI time zone which
omits all the leap second corrections but otherwise matches GMT or UTC.
The result cannot, strictly speaking, be called TAI since it is expressed
as YYMMDD HHMMSS rather than number of seconds, but that fine point
probably does not matter within a group who accepts that deviation.
Conversely, if you have not updated your zoneinfo files (or at least
localtime) since the last leap second was announced, your reported UTC
will be off by some number of leap seconds. Most people won't care;
the few that do care are most likely aware of this and have already
updated the files.
Marc is absolutely correct in saying that keeping TAI internally and
displaying UTC externally is complex and (if you're careless) error
prone; nevertheless, that is how it is actually done in Unix and NTP.
============================================================
Paul Hughett, Ph.D. Research Associate and
Neuropsychiatry Section Computer Systems Manager
10th floor Gates Building
Hospital of the University (215) 662-2826 (voice)
of Pennsylvania (215) 662-7903 (fax)
3400 Spruce Street
Philadelphia PA 19104 hughett@bbl.psycha.upenn.edu
A rose by any other name confuses the issue.
-Patrick E. Raume
============================================================