From: vjs@calcite.rhyolite.com (Vernon Schryver) [-/+]
Date: 2 May 1997 11:13:06 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How do I check the all of my systems are in sync ? [-/+]
In article <5kcmdo$4tq1@farstar.frb.gov>, Greg <kokopelli@radix.net> wrote:
> ...
>This works fine for unix clients running xntpd, but on my NT machines I run
>TimeServer. Any way to check that they are synching okay, w/o running a
>digital clock on NT and Unix machine and comparing ticks.
Do your UNIX boxes also have `timed`? If so, does
the command `timedc clockdiff host1 host2 ... hostn` work?
Vernon Schryver vjs@rhyolite.com
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 29 Apr 1997 12:08:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: drift file exceeds 100 [-/+]
X-Keywords: nsec_per_tick [-/+] PPM [-/+]
In article <WIU09524.97Apr28160855@rrzc4>, wiu09524@rrzc4 (Ulrich Windl)
writes:
>In article <33647547.7353@cellnet.co.uk> Anthony Bowles <abowles@cellnet.co.uk> writes:
>> I've got a couple of Solaris 2.x machines who's drift files are
>> in excess of plus or minus 100.
>
>If you divide your value of tick by your value of HZ , you'll get the
>number of PPM that one tick is worth (e.g. 10000 / 100Hz == 100ppm).
>If you have a drift of 137.33 with tick == 10000, using tick == 9999
>your drift should be 37.33 then.
Note however that at least in xntp 3-5.90, where on at least Solaris
2.5.1 tickadj apparently adjusts the nsec_per_tick variable, the
argument to tickadj -t (like the variable of course) is in
*nano*seconds, not microseconds.
--Per Hedeland
per@erix.ericsson.se
From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]
Date: Tue, 29 Apr 1997 09:32:03 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Synchronizing solutions not using NTP
Mark Olson wrote:
>
> Are there any non-NTP algorithms for transmitting time from one machine
> to another and still getting an accuracy of a second? For my
> application, I can't use NTP but I still need a way of synchronizing two
> machines to within some reasonable accuracy.
rdate, for example.
Damon
From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]
Date: Thu, 01 May 1997 13:13:34 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Stratum-1 source for < $5,000? [-/+]
X-Keywords: implementation [-/+] TrueTime [-/+]
Vernon Schryver wrote:
>
> In article <5k84qu$2ea4@mail1.wg.waii.com>,
> Frank Vance <fvance@plum.wg.waii.com> wrote:
> >H. Peter Anvin (hpa@transmeta.com) wrote:
> >: I would like to hear suggestions for a stratum-1 source that is
> >: accurate to ~ 1 ms or so, and works well with xntpd. If possible, I
> >: would like to keep this under $5,000.
>
> > ...
> > There are probably others I don't know about.
>
> I thought TrueTime's XL-AK GPS receiver with RS-232 interface is
> supposed to be < $1000, but now I can't find the notes I made while
> talking to a rep. I think even TrueTimes GPS-with-Ethernet NTP
> box is cheaper than $5000.
A little less than GBP4000 after an extra dealer's cut has been
taken. I am considering buying one myself.
> By the way, how recent is the NTP implementation in that box?
Well, it's V3, but it would be nice to know what sort of a job
it will do if you cross-sync with a few other s-1 servers over
the Net.
Damon
From: David Ross <rossde@acm.org> [-/+]
Date: Sat, 03 May 1997 17:53:42 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: HOWTO circumvent leap seconds - HELP??? [-/+]
X-Keywords: bug [-/+] Datum [-/+] implementation [-/+] synchronized [-/+] TAI [-/+]
Robert Karban wrote [in part]:
>
> Just a clarification:
>
> The main reason why we want to handle leap seconds "manually" is the
> following:
>
> We have one stratum-1 server (our own) to which everything is
> synchronized.
> It is a Datum GPS receiver that as a problematic leap second
> implementation, meaning
> it counts: 23:59:59 -> 23:59:60 -> 00:00:00
> This behaviour drives our NTP clients crazy, meaning that they don't
> trust this server anymore.
What you have is a serious bug in your client software. 23:59:60 (and
even 23.59:60.9) are legal times under international convention.
Since you are involved in astronomical observations, you might consider
doing everything in TAI (which has no leap-seconds) rather than UTC.
Then, such computations as time-series analysis, integrating orbits,
etc, can reliably depend on all units of time being uniform. That is,
every minute will have exactly 60 seconds, and every day will have 86400
seconds. (Note: Under the convention, it is theoretically possible for
a UTC minute to have only 59 seconds through a negative leap-second.)
If you use TAI, of course, you will need software to convert to UTC for
displays and from UTC for inputs; you will also have to convert from TAI
through UTC to obtain the sidereal angle. This software would require a
table of leap-seconds. This is neither complicated nor innovative; back
in 1969, I tested software for tracking earth-orbiting military
satellites that worked exactly this way.
--
David E. Ross
Newt Gingrich got a loan. For details, go to
http://www.geocities.com/CapitolHill/6727 and select Editorials.
From: David Ross <rossde@acm.org> [-/+]
Date: Sun, 04 May 1997 10:40:40 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: HOWTO circumvent leap seconds - HELP??? [-/+]
X-Keywords: TAI [-/+] timezone [-/+]
Paul Boven wrote:
>
> On 4 May 1997 10:12:40 +0200, Paul Schlyter <pausch@electra.saaf.se> wrote:
> [--8<-- Interesting thread snipped -->8--]
>
> >As a matter of fact, he'll need to convert to UT2....
> >...and also a table converting UTC to UT2 -- this quantity varies
> >continuously.
>
> What kind of timezone is UT2? A second universal time?
> Just curious.
UT is the time computed from the rotation of the earth, taking into
account all variations in the rotation.
UT0 is UT averaged to take into account only the effects of polar
wander, seasonal periodicities (annual and semi-annual), and the secular
(nearly linear) decay in the earth's rotation. Short-term tidal
periodicities and other effects are eliminated.
UT1 is UT0 averaged to eliminate polar wander.
UT2 is UT1 averages to eliminate the seasonal periodicities. There is a
linear relationship between UT2 and UTC.
UTC is atomic time, offset from TAI (by the leap-second) so that
|UTC-UT1|<1.0sec. That is UTC remains close to earth-rotation time.
The progression of transformations from TAI to sidereal angle (GHA or
Greenwich hour angle) is TAI > UTC > UT2 > UT1 > UT0 > GHA. Since UT0
is a function of location (latitude and longitude), it is often omitted
when computing GHA.
GHA is the angle between the Greenwich meridian and the vernal equinox,
a measure of the rotation of the earth. It is used to convert between
earth-based, rotating coordinates and star-based, inertial coordinates.
For example, the GHA is used when computing orbits of earth-orbiting
satellites (relatively simple in inertial coordinates) from ground-based
radar tracking (rotating coordinates).
In the overall transformation from TAI to GHA, the most complicated part
is the table-lookup for the transformation between TAI and UTC. All the
other parts are relatively simple formulae.
--
David E. Ross
http://www.geocities.com/CapitolHill/6727
(I keep changing it, so visit again.)
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 4 May 1997 10:12:40 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: HOWTO circumvent leap seconds - HELP??? [-/+]
X-Keywords: TAI [-/+]
In article <336BDE16.101C@acm.org>, David Ross <rossde@acm.org> wrote:
> Since you are involved in astronomical observations, you might consider
> doing everything in TAI (which has no leap-seconds) rather than UTC.
> Then, such computations as time-series analysis, integrating orbits,
> etc, can reliably depend on all units of time being uniform. That is,
> every minute will have exactly 60 seconds, and every day will have 86400
> seconds. (Note: Under the convention, it is theoretically possible for
> a UTC minute to have only 59 seconds through a negative leap-second.)
> If you use TAI, of course, you will need software to convert to UTC for
> displays and from UTC for inputs; you will also have to convert from TAI
> through UTC to obtain the sidereal angle.
As a matter of fact, he'll need to convert to UT2....
> This software would require a table of leap-seconds.
...and also a table converting UTC to UT2 -- this quantity varies
continuously.
> This is neither complicated nor innovative; back in 1969, I tested
> software for tracking earth-orbiting military satellites that worked
> exactly this way.
Back then UTC didn't exist -- it's been used only since 1972.
Today the most practical way to handle this is through some device
which receives time signals over the radio; some of these time
signals have the current difference TAI-UTC and even UTC-UT2 encoded
into them.
--
----------------------------------------------------------------
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: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 5 May 1997 21:46:43 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: HOWTO circumvent leap seconds - HELP??? [-/+]
X-Keywords: TAI [-/+] timezone [-/+]
In article <slrn5moo6h.47d.paul@wit387304.student.utwente.nl>,
Paul Boven <e.p.boven@student.utwente.nl> wrote:
> On 4 May 1997 10:12:40 +0200, Paul Schlyter <pausch@electra.saaf.se> wrote:
> [--8<-- Interesting thread snipped -->8--]
>
> >As a matter of fact, he'll need to convert to UT2....
> >...and also a table converting UTC to UT2 -- this quantity varies
> >continuously.
>
> What kind of timezone is UT2? A second universal time?
> Just curious.
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!
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 5 May 1997 21:48:55 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: HOWTO circumvent leap seconds - HELP??? [-/+]
X-Keywords: TAI [-/+] timezone [-/+]
In article <336CCA18.1409@acm.org>, David Ross <rossde@acm.org> wrote:
> Paul Boven wrote:
>
>> On 4 May 1997 10:12:40 +0200, Paul Schlyter <pausch@electra.saaf.se> wrote:
>> [--8<-- Interesting thread snipped -->8--]
>>
>> >As a matter of fact, he'll need to convert to UT2....
>> >...and also a table converting UTC to UT2 -- this quantity varies
>> >continuously.
>>
>> What kind of timezone is UT2? A second universal time?
>> Just curious.
>
> UT is the time computed from the rotation of the earth, taking into
> account all variations in the rotation.
>
> UT0 is UT averaged to take into account only the effects of polar
> wander, seasonal periodicities (annual and semi-annual), and the secular
> (nearly linear) decay in the earth's rotation. Short-term tidal
> periodicities and other effects are eliminated.
>
> UT1 is UT0 averaged to eliminate polar wander.
>
> UT2 is UT1 averages to eliminate the seasonal periodicities. There is a
> linear relationship between UT2 and UTC.
>
> UTC is atomic time, offset from TAI (by the leap-second) so that
> |UTC-UT1|<1.0sec. That is UTC remains close to earth-rotation time.
To be picky, I think the condition is: |UTC-UT2|<0.9s
One could add that the differences between UT0, UT1 and UT2 usually do
not exceed 0.01 seconds.
> The progression of transformations from TAI to sidereal angle (GHA or
> Greenwich hour angle) is TAI > UTC > UT2 > UT1 > UT0 > GHA. Since UT0
> is a function of location (latitude and longitude), it is often omitted
> when computing GHA.
>
> GHA is the angle between the Greenwich meridian and the vernal equinox,
> a measure of the rotation of the earth. It is used to convert between
> earth-based, rotating coordinates and star-based, inertial coordinates.
Unfortunately, these star-based coordinates aren't quite inertial. The
RA/Dec frame of reference rotates once every 26,000 years...
> For example, the GHA is used when computing orbits of earth-orbiting
> satellites (relatively simple in inertial coordinates) from ground-based
> radar tracking (rotating coordinates).
The GHA is also used when computing rise/set times of any celestial body.
> In the overall transformation from TAI to GHA, the most complicated part
> is the table-lookup for the transformation between TAI and UTC. All the
> other parts are relatively simple formulae.
The conversion UT2 > UT1 is realtively simple. The conversion UT1 > UT0
is less simple, but so small that it usually can be ignored.
But the convertion UTC > UT2 is definiteily NOT simple! It involves the
same table as the conversion TAI > UTC, plus some function or table which
accurately represents the varying speed of the Earth's rotation....
--
----------------------------------------------------------------
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: Kevin Oberman <oberman@es.net> [-/+]
Date: 05 May 1997 13:36:07 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Confused [-/+]
X-Keywords: release [-/+]
pete@rayleigh.tt.aftac.gov (Pete Geenhuizen) writes:
> I want in install ntp, but am confused as to what to install, so could
> someone tell me the difference between:
> xntp3-5.90.tar.gz
> and
> xntp3.5f.tar.Z
> BTW, for what it's worth this is an all Sun only network.
I assume that you know that .Z means Unix compressed and .gz means
gzipped. GZIP is newer than compress and works much better. It is also
not subject to patent restrictions which compress is. gunzip can
uncompress both formats.
The other issue is 3.5.90 vs. 3.5f. 3.5f is not undergoing any
maintenance and is rather buggy. 3.5.90 is the latest official release
and I would strongly suggest running it.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
From: Damon at play <dhd@exnet.com> [-/+]
Date: Mon, 5 May 1997 19:49:37 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,uk.telecom
Subject: New driver for GBP70 MSF receiver
As it says folks; a new xntp driver for this cheap-and-cheerful MSF
receiver.
For code and other details (such as where you can buy the clock from),
see:
http://www2.exnet.com/NTP/ARC/ARC.html
(I've cross-posted this to uk.telecom to alert potential UK users of
this
nice clock which is OK as a cheap backup to a `real' time source; I
suggest
you delete u.t on followups that only concern c.p.t.n.)
Cheers,
Damon
--
Damon s0dhd@exnet.com, d@hd.org
http://www2.exnet.com/ http://www.exnet.com/CV/DHDCV.html
Public NTP time server: http://www2.exnet.com/NTP.html
Looking for cross-feeds of c.p.t.n to improve propagation! [esp
.au,.de,.jp]
From: Carl Brewer <carl@abm.com.au> [-/+]
Date: Wed, 07 May 1997 07:45:22 +1100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: compied ntp client
Brad Glidewell wrote:
>
> No C compiler, is there a copiled ntp client somewhere?
>
> (SunOS atm 5.5.1 Generic sun4u sparc SUNW,Ultra-1)
I did one for 3.5-87, it's at ftp.library.uwa.edu.au somewhere.
It's a solaris package.
I'll shortly be doing one for 3.5.90 (5.5.1 and 5.6) and putting it
in the same place.
From: "Steve Harwood" <steve.harwood@worldnet.att.net>
Date: 1 May 1997 03:50:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Stratum-1 source for < $5,000? [-/+]
X-Keywords: Arbiter [-/+] Bancomm [-/+] Datum [-/+] Mills [-/+] release [-/+] WWVB [-/+]
We use a Datum TS-2100 at the office. Don't believe their sales
literature--have the features promised are not in the initial release of
firmware...
Also, on April 1st (what a date to for this to happen), the TS-2100 told
all our servers it was June 2037! It took us a while to recover--but
Datum's tech support was of NO help.
Also, the TS-2100 product has only one person at Datum you can talk to --
Chris Gonsolves. He is the product manager, is always out of the office
and seems to only return calls after 3pm Pacific time (not a big help if
you are on the East coast like myself)--you have to be good with phone-tag
for any assitance!
Just a few comments. Hope you find a better solution. Also, the TS-2100
is REAL CLOSE to the $5,000 figure...
Frank Vance <fvance@plum.wg.waii.com> wrote in article
<5k84qu$2ea4@mail1.wg.waii.com>...
> H. Peter Anvin (hpa@transmeta.com) wrote:
> : I would like to hear suggestions for a stratum-1 source that is
> : accurate to ~ 1 ms or so, and works well with xntpd. If possible, I
> : would like to keep this under $5,000.
>
> : Unfortunately, the xntp docs aren't really helpful in determining how
> : well the various supported clocks work.
>
> I am awaiting the arrival of our Arbiter Systems 1092A, which
> sells for about $850 (USD). Arbiter loaned a unit to Dr. Mills,
> so he could write a xntp driver. That driver is now included in the
> xntp distribution (driver type 11).
>
> This unit is a standard GPS time code receiver, and requires
> a host of some sort to interface with it and do all the NTP
> phase-locked loop and protocol stuff.
>
> Arbiter Systems can be reached at +1 800 321 3831 (for those outside
> the US and Canada the number is +1 805 237 3831)
>
> A solution I have not priced, but I suspect is less than $5,000
> is the BanComm TymServe 2100. In one rack-mounted box, you get the
> GPS receiver, some sort of processor, and a 10BaseT and AUI
> connection for Ethernet. And it speaks NTP version 3.
>
> Datum Inc. (Bancomm's parent) can be reached at +1 800 348 0648
> (for those outside the us and Canada Bancomm's number is +1 408 578
4161).
>
>
> A non-GPS solution is the SpectraCom NetClock/2, which is a WWVB
> receiver. In 1994, it listed for $1500. I don't know what it costs
> now, but it works with xntp driver type 4.
>
> SpectraCom is at +1 716 381 4827.
>
>
> There are probably others I don't know about.
>
>
>
> --
> Frank Vance +1 713 963 2426 Western Geophysical
> Frank.Vance@waii.com 10001 Richmond Avenue
> FAX: +1 713 963 2490 Houston, TX 77042 USA
>
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 5 May 1997 18:16:46 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Confused [-/+]
X-Keywords: bug [-/+] DES [-/+] release [-/+]
Howdy,
I suggest xntp3-5.90.tar.gz or the "export" version.
The older version 3.5f is quite stable and should
work, but the newer version has a very important bug fix
and a huge number of improvements. Many of these
improvements are valuable on Solaris (tickadj has
more features, for example). The export version
doesn't have the DES signature code, but I suggest
you use the MD5 signatures, which are the default.
The version number sequence was 3.4r when I first
saw xntpd. 3.4<alpahbetic> rolled to 3.5<alphabetic>
up to 3.5f. The next versions were named 3-5.86
thru 3-5.89.7, and I DON'T reccommend using them. There
was a major code conversion that really improved things,
but a very ancient bug (that exists in 3.5f, too) and a
few other troubles made December through February a bit
of an adventure. (I think root daemons should be boring.)
I use xntpd on sparc Solaris 2.5 and have been on
3-5.89.8 for a couple of months. I think the "release"
version 3-5.90 is the good choice, and I'll be there
in the next couple of weeks.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
followup posted and email
-----
Pete Geenhuizen (pete@rayleigh.tt.aftac.gov) wrote:
: I want in install ntp, but am confused as to what to install,
: so could someone tell me the difference between:
: xntp3-5.90.tar.gz
: and
: xntp3.5f.tar.Z
: BTW, for what it's worth this is an all Sun only network.
: Thanks
: Pete
: --
: ----------------------------------------------------------------------------
: Pete Geenhuizen
: pete@gasbuggy.rockledge.fl.us
: "The credibility gap is taken care of by the gullibility fill"
: Andy Capp
From: fvance@plum.wg.waii.com (Frank Vance) [-/+]
Date: 9 May 1997 16:16:03 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Is there a radio clock in Australia?
X-Keywords: CHU [-/+] DCF77 [-/+] prefer [-/+] WWVB [-/+]
Robin Kimberley (robk@oldtimer.win-uk.net) wrote:
:
: In article <m2rafkt6le.fsf@reddwarf.aup.com.au>, Manfred Bartz (mbartz@werple.net.au) writes:
: >
: >There used to be a radio time signal based in Australia (VNG) but I
: >cannot find any references to that anywhere.
: >
: >WWV/WWVH can only be heard for some time of the day, so I really would
: >prefer a closer signal.
: >
: >Any help appreciated.
: Why not consider GPS? It is available everywhere.
One reason to consider an alternative to GPS would be for redundancy.
One would hope there will never be problems with the GPS system, but,
at this point in time, I think it would be prudent to have a backup
time source.
There are several ways to accomplish this:
1. A non-GPS navigation system, like the Russian GLONASS or the
GPS augementation system proposed by IntelSat. Both Ashtech and
3S Navigation make GLONASS/GPS receivers.
2. a Standard Station radio receiver, such as those which use WWV/WWVH,
WWVB, CHU, MSF, DCF77, and TDF. (What others are there now?)
3. a very accurate time base, such as an cesium oscillator
(A few years back, Westinghouse announced a research project to
develop a grapefruit sized (or smaller) atomic clock costing less
than $1,000 USD. What ever happened to that?)
--
Frank Vance +1 713 963 2426 Western Geophysical
Frank.Vance@waii.com 10001 Richmond Avenue
FAX: +1 713 963 2490 Houston, TX 77042 USA
From: "Marc Brett" <Marc.Brett@waii.com> [-/+]
Date: 9 May 1997 17:14:02 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: RDS (Was: Is there a radio clock in Australia?)
X-Keywords: CHU [-/+] DCF77 [-/+] resolution [-/+] WWVB [-/+]
Frank Vance <fvance@plum.wg.waii.com> wrote:
> : Why not consider GPS? It is available everywhere.
> One reason to consider an alternative to GPS would be for redundancy.
> One would hope there will never be problems with the GPS system, but,
> at this point in time, I think it would be prudent to have a backup
> time source.
> There are several ways to accomplish this:
> 1. A non-GPS navigation system, like the Russian GLONASS or the
> GPS augementation system proposed by IntelSat. Both Ashtech and
> 3S Navigation make GLONASS/GPS receivers.
> 2. a Standard Station radio receiver, such as those which use WWV/WWVH,
> WWVB, CHU, MSF, DCF77, and TDF. (What others are there now?)
> 3. a very accurate time base, such as an cesium oscillator
> (A few years back, Westinghouse announced a research project to
> develop a grapefruit sized (or smaller) atomic clock costing less
> than $1,000 USD. What ever happened to that?)
Speaking of alternatives, has anybody investigated using RDS (RBDS in
the States), the digital signal encoded in many commercial FM radio
signals. ( See http://www.rds.org.uk )
It's almost universal here in the UK, and many stations include the CT
(clock/time) frame. The BBC, for example, in turn get their time
reference from the MSF (Rugby) transmitter, so it's traceable to a
reliable source
However, the recommended repetition rate for CT frames is only 0.02
frames per second (about once per minute), and I don't know any details
about the encoding itself. What is the time resolution? Is there
an "on-time" character sent with the frame?
In short, what is the ultimate resolution that you can expect with
this signal? Is it suitable for use by NTP?
--
Marc Brett Western Atlas
Marc.Brett@waii.com +44 181 560 3160
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Tue, 13 May 1997 21:20:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: I need to sync. clocks with no external source [-/+]
X-Keywords: Mills [-/+] peer [-/+] RFC [-/+]
In <33783A62.41F3@gb.swissbank.com> Andrew Hickson writes:
> I help maintain about 40 mail servers gloablly, and there is a
> requirement to sync the clocks on all the servers. We have no internet
> access, so I need to set up one (or more) server(s) as the master time,
> and get all the other servers to adjust to this.
>
> Is NTP the right tool to use. If NTP IS the right tool, what do I need
> to do to run without external sources. I've looked in the NTP faq area,
> but can't really make any sense.
I think NTP is the right tool to use in such an environment. It *is*
possible to run NTP without any external references (you can designate
internal clocks as reference clocks) but it will be a major hassle if
you have more than one pseudo-primary server. Or you have a very bad
single point of failure if you use only one pseudo-primary server.
With about 40 servers distributed world-wide, I would equip 6 of them
with a radio-clock. Probably 2 in the US, 2 in Europe and 2 in the Pacific
area. In NTP-terms, these servers will be your stratum-1 servers. They
should be configured as peers to each other. The other 30-odd servers
would each sync to 2 or 3 of the stratum 1's and peer with 2 or 3 of the
other servers. The "best" topology will depend on the way your network
is structured, but NTP is very flexible in that regard.
You might want to read Dr. Mills' RFC on the subject (RFC 1305?) for better
understanding of the protocol.
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]
Date: Tue, 13 May 1997 13:28:26 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: I need to sync. clocks with no external source [-/+]
X-Keywords: fudge [-/+] restrict [-/+]
Andrew Hickson wrote:
>
> I help maintain about 40 mail servers gloablly, and there is a
> requirement to sync the clocks on all the servers. We have no internet
> access, so I need to set up one (or more) server(s) as the master time,
> and get all the other servers to adjust to this.
>
> Is NTP the right tool to use. If NTP IS the right tool, what do I need
> to do to run without external sources. I've looked in the NTP faq area,
> but can't really make any sense.
>
> Any help will be gratefully received.
>
> Thanks,
>
> Robin.
>
> Please reply to robin.wakefield@gb.swissbank.com
I'm posting the reply too because I just answered more-or-less
the exact same question yesterday.
Set your master clock up to sync to its local clock (127.127.1.X)
and I suggest you set it to a high stratum so that when you get real
external time your machine's clock will be ignored.
Under old xntpds this could be done with:
server 127.127.1.9
in the config file; now it is:
server 127.127.1.0
fudge 127.127.1.0 stratum 9
Remember to trust your local clock for time if you restrict
who you will trust for modifications and time.
Then sync your other machines to the master.
Damon
From: Mark Atwood <zot@ampersand.com>
Date: 16 May 1997 16:59:49 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: How simple can a broadcast client be?
X-Keywords: auth [-/+] broadcast [-/+] Cisco [-/+] configuration [-/+] dosynctodr [-/+]
My Cisco router is acting as an NTP broadcast server.
I've built and installed xntp3-5.90 on several Solaris 2.5 boxes. I
want to configure them as broadcast clients.
After setting dosynctodr to zero, I ran "xntpd -b", but a "ntptrace
localhost" showed it never sync'ed up. So then i created a
/etc/ntp.conf file with just the "broadcastclient" line. It still
never synced up. After some more experaments, I ended up with a
ntp.conf file that said:
disable auth
enable bclient
broadcastclient
and at LAST, it synced up.
Is this really the simplist configuration for a "mere" broadcast
client?
--
Mark Atwood | Support the anti-Spam amendment
zot@ampersand.com | Join at http://www.cauce.org/
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 6 May 1997 17:23:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How do I check the all of my systems are in sync ? [-/+]
[ how to check a WinNT box for working xntpd ...]
I think that there is a place in the WinNT controls to
launch typical network services like port 13 or port 37
(daytime or time). With either of these, a perl
script could check that the time was close.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: ktk@ktk.bidmc.harvard.edu (Kristofer T. Karas)
Date: 19 May 1997 21:54:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for Linux
X-Keywords: adjtimex [-/+] Linux [-/+]
In article <01bc6495$70ad1fb0$a5441ed1@guiness>,
Ron Harter <rharter@flash.net> wrote:
>Can someone tell me where I can get a version of NTP for Linux? Do I need
>to download the source and just compile it?
Yes, works fine. It configures with autoconf, so is easy to compile.
Since I don't have any stratum-1 local sources, I disable the internal
clocks, save for the system RTC, by doing:
./configure --disable-all-clocks --enable-LOCAL-CLOCK
As always, YMMV.
Also get the adjtimex package, from sunsite in
/pub/Linux/system/admin/time/, which is a nice utility for calibrating
the TICK value on your local clock - necessary on some machines with
very poor (erratic) system clocks.
--
Kristofer Karas - SysAdmin, BI Deaconness Med. Ctr. - ktk@ktk.bidmc.harvard.edu
AMA/CCS, DoD, RF900RR, HawkGT, !car *** http://ktk.bidmc.harvard.edu/~ktk/
"Health nuts are going to feel stupid someday, lying in hospitals dying
of nothing." -- Redd Foxx *** Will design LISP machines for food
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 21 May 1997 17:55:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp 3-5.90 client shows 8 Hour offset [-/+]
X-Keywords: daylight [-/+] timezone [-/+] Windows [-/+]
Peter.Moreton@chase.com wrote:
: I have an NTP server v3-5.90 running on Windows NT 4.0,when I point an
: NTP client (both Sunos & NT) to this server,it sets the local clock 8
: hours (!) ahead of the time on theNTPserver. Interestingly, ntpdate &
: ntptrace both report an 'offset' of 28800 seconds, which is of course, 8
: hours.I have RTFM'd everywhere, What am I doing wrong?Thanks, Peter
: Moreton, Peter.Moreton@chase.com
Howdy,
Without any real knowledge, I suspect that you have timezone troubles.
If the NT server is getting time from a real outside ntp source, its
time is most likely correct, since ntp works in UTC and I think any
local setup strangeness is ignored or canceled.
If the NT server is using local refclock without outside servers, the
timezone is important. You might have interesting times near the
daylight savings time changes, too.
The clients might have the timezone trouble.
Timezone trouble is quite common ! With the wrong default timezone
(especially sign of timezone), the host gets set to wristwatch with
a number of hours offset, but things don't look wrong, since the TZ
error cancels back out when you look at the time / date, again with
the default and compared to the same wristwatch.
The POSIX convention for time offset sign is different than I expect.
On the Sunos client, I suggest you set the default TZ to the correct
political name timezone and check things by using sh
$ date
$ date -u
$ TZ=US/Central date
to make sure the /usr/share/lib/zoneinfo/US/... files are working.
Also try pointing the clients to other servers out on the internet,
if you can. "ntpdate -d <outside server>"
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: "Doug Hogarth" <DougHo@niceties.com> [-/+]
Date: 22 May 1997 15:09:44 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp 3-5.90 client shows 8 Hour offset [-/+]
X-Keywords: DST [-/+]
Setting the proper time zone on WinNT is done using Settings - Control
Panel - Date/Time - Time Zone (not a TZ environment variable although you
can set that too, if you want). As you mentioned, it is important to also
have the DST checkbox correct (or you might notice time off by an hour or
whatever).
From: Peter.Moreton@chase.com
Date: Fri, 23 May 1997 08:02:02 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp 3-5.90 client shows 8 Hour offset [-/+]
X-Keywords: daylight [-/+] timezone [-/+] Windows [-/+]
In article <5lvcub$pti$1@mwrns.boulder.noaa.gov>,
bwb@etl.noaa.gov (Bruce Bartram) wrote:
>
> Peter.Moreton@chase.com wrote:
> : I have an NTP server v3-5.90 running on Windows NT 4.0,when I point an
> : NTP client (both Sunos & NT) to this server,it sets the local clock 8
> : hours (!) ahead of the time on theNTPserver. Interestingly, ntpdate &
> : ntptrace both report an 'offset' of 28800 seconds, which is of course, 8
> : hours.I have RTFM'd everywhere, What am I doing wrong?Thanks, Peter
> : Moreton, Peter.Moreton@chase.com
>
> Howdy,
> Without any real knowledge, I suspect that you have timezone troubles.
> If the NT server is getting time from a real outside ntp source, its
> time is most likely correct, since ntp works in UTC and I think any
> local setup strangeness is ignored or canceled.
>
> If the NT server is using local refclock without outside servers, the
> timezone is important. You might have interesting times near the
> daylight savings time changes, too.
>
> The clients might have the timezone trouble.
>
> Timezone trouble is quite common ! With the wrong default timezone
> (especially sign of timezone), the host gets set to wristwatch with
> a number of hours offset, but things don't look wrong, since the TZ
> error cancels back out when you look at the time / date, again with
> the default and compared to the same wristwatch.
>
> The POSIX convention for time offset sign is different than I expect.
>
> On the Sunos client, I suggest you set the default TZ to the correct
> political name timezone and check things by using sh
> $ date
> $ date -u
> $ TZ=US/Central date
> to make sure the /usr/share/lib/zoneinfo/US/... files are working.
>
> Also try pointing the clients to other servers out on the internet,
> if you can. "ntpdate -d <outside server>"
>
> Bruce Bartram bbartram@etl.noaa.gov just another chimehead
Guys,
I found the problem! My NTP server did indeed have and incorrect
Timezone, although Control Panel, Date/Time showed it to be correct
(GMT), the 'C' RTL was returning PST. The following C program can be used
to check this:
/*
* TZ.C: view TZ on NT
*/
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
void main( void )
{
{
_tzset();
printf( "_daylight = %d\n", _daylight );
printf( "_timezone = %ld\n", _timezone );
printf( "_tzname[0] = %s\n", _tzname[0] );
}
exit( 0 );
}
It seems I have an errant service (in fact, the Galleon MSF clock driver)
that changes the Timezone to be PST when it starts. It does this in a way
that causes Control Panel, Date/Time to report GMT, but my TZ.C programs
reveals that the C RTL believes we are in PST.
The fix is to use Control Panel, Date/Time to change the timezone to
something else, and then back to GMT again. Now TZ.C reports a GMT
timezone. (If I start-up the Galleon driver, it goes back to PST)
Thanks for everyones suggestions
Peter Moreton
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
From: "Doug Hogarth" <DougHo@niceties.com> [-/+]
Date: 23 May 1997 23:33:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: need ntp for windows nt/gps receiver [-/+]
X-Keywords: configuration [-/+] NMEA [-/+]
The WinNT port of xntpd doesn't support any external reference clocks.
My TimeServ program (http://home1.gte.net/dougho/TimeServ.html) supports a
variety of external clocks but probably not the garmin - I don't think it
has the required "ZDA" sentence type of NMEA.
Jim Spears <jspears@ccgate.hac.com> wrote in article
<5m2ejs$mrs@hacgate2.hac.com>...
> we are looking for ntp to run on a windows nt platform. the
configuration we have
> in mind has this machine getting time from a garmin gps receiver and
acting as time
> server for a group of workstations. I know of WinSNTP but it does not
seem able to
> get time from external clocks, only across the net.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 26 May 1997 08:06:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: need ntp for windows nt/gps receiver [-/+]
X-Keywords: Linux [-/+]
NT 4.0 is a poor choice for an expensive GPS receiver. A PC running
Linux will perform much better at a lower price, I think.
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>