From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 9 Jul 1997 19:20:37 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How to multi(or broad)cast time using server's system clock?
X-Keywords: auth [-/+] broadcast [-/+] delay [-/+] fudge [-/+] implementation [-/+] multicast [-/+] prefer [-/+] SNTP [-/+] trustedkey [-/+]
In article <01bc8c37$0f312460$a9a848a6@thinktank> you wrote:
: I need to multicast the time to a bunch of clients setup on a subnet. I
: don't want to use an internet source and don't want to buy a radio clock.
: This is for unit testing an implementation of SNTP client on an ethernet
: board, so I just need to setup a single server on an NT machine. I would
: appreciate some tips!!
Howdy,
ftp://ftp.udel.edu/pub/ntp/testing/xntp3-5.90.2.tar.gz
should compile and work on a WinNT machine. There is
no support for radio clocks, but the "local refclock" should work.
A binary version is available, see the attached posting from Greg.
The ntp.conf file (I don't know the NTish names, but the ntp.conf
lines should be the same):
server 127.127.1.0 prefer # local refclock
fudge 127.127.1.0 stratum 14 # show poor quality
broadcast 224.0.1.1 key 1 ttl 1 # multicast
keyfile /usr/local/etc/ntp.keys # actually should be the
# NTish address
trustedkey 1
enable auth
The ntp.keys file should be like:
1 M yourpass
It is strongly suggested that un-disiplined time NEVER be b-cast
or ESPECIALLY MULTICAST, since these things can go much farther
than expected. The prefer keyword overrides a code check that
blocks -casting of local clock derrived time. This keyword also
stops xntpd from making the ntp.drift corrections.
Authorization is default on since before 3.5f. I add it to ntp.conf
to force me to remember it is on. I think the "trustedkey 1" line
isn't needed for SNTP clients, but xntpd -cast clients seem to
need to to be able to get the server to respond to the client's
effort to measured the -cast delay value (only when the client awakes).
You should probably test with both auth and "disable auth" if the
client code can handle both formats. With "diable auth", I think
the broadcast line should NOT have the "key 1". key 0 is widely
known (something like 0 ?) and might allow you to ignore ntp.keys.
WARNING: this advice is NOT trustworthy !!! I'm just guessing !!!
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
emailled to poster
----- Greg's recent posting about WinNT xntpd binaries
Look for the lastest version, especially 3-5.90.2, if
available. (This might be in a testing sub-dir ?)
~From: "Greg" <schueman@ix.netcom.com>
~Newsgroups: comp.protocols.time.ntp
~Subject: Re: WinNT NTP and Time Zone?
~Date: 21 Jun 1997 04:38:05 GMT
Brian,
Grab the latest version XNTP 3-5.90.1b from ftp.drcoffsite.com and let
me
know whether the problem still exists. The _ftime() function was causing
Day Light Savings time problems, and I wonder whether it might have other
problems related to time zones.
Send email to <access@drcoffsite.com> for access to the site.
The latest NT for Intel binaries are there.
-Greg
From: "Xavier NAZART" <nci@wanadoo.fr>
Date: 9 Jul 1997 06:44:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: ANNOUNCE : TIME SERVER for NetWare and Windows NT
X-Keywords: synchronized [-/+]
Network Time Synchronization System (NTSS) keep your Network at true time
by using an external GPS receiver connected to the serial port of one or
more NetWare or NT servers.
All your file servers, HTTP, FTP, SMTP, POP or News servers will be at the
same time and do'nt send messages or documents dated in the future.
All servers and Workstations of your network will be time synchronized to
the reference time servers by using Client Agents available for DOS,
WINDOWS 3.x,
WIN95 operating system and NetWare 3.x servers.
GPNCA100 receiver can be used anywhere around the world. Time data are
received from satellites.
For NetWare 4.x environnment, Time synchronization is recommanded for NDS
operations across WAN connections.
For more informations about NTSS, please send a message to nci@wanadoo.fr
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 11 Jul 1997 19:26:21 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Problem with DEC Unix on ALPHA
X-Keywords: bug [-/+] configuration [-/+] driftfile [-/+] Linux [-/+]
Paolo Agati (agati@euris.area.trieste.it) wrote:
: I have a problem with NTP running on a Digital ALPHA. The ALPHA
: (ALPHA Server 4100, 2 ALPHA 64 CPUs at 233 MHz, OS DEC Unix 4.0B
: rev 564, ntp version 3.4x) is acting as a time server for a local
: network of SUN workstations (CPU Sparc3, OS SunOs 4.1.3, ntp
: version 3.5-89). The problem is that the SUNs loose the
: synchronization with the ALPHA about every 20 minutes. The server is
: configured at Stratum 10 and on the SUNs tickadj is run at boot
: with following parameters:
: -s -a 5 -t <some value computed from driftfile>
: In another LAN we have a Linux box acting as time server (CPU i486
: at 50 MHz, Linux 1.2.8, ntp 3.4y) for some SUNs (same configuration
: as above) and everything is running fine.
: Any suggestions?
: TIA
: Paolo Agati Euris S.r.l.
: +39 40 89801
: Via Caboto, 12
: agati@euris.area.trieste.it I-34100, TRIESTE
: Italy
Howdy,
My experience is with sparc-Solaris 2.5 xntp 3-5.89.8. I suggest
that you AVOID xntp versions from 3-5.86 to 3-5.89.7. There are
some bad troubles with ntp_io.c near 3-5.89 that got fixed in
3-5.89.5, but some other stuff was broken for Solaris until
3-5.89.8. Some of the troubles involved loosing track of which
packet was which and the reach would fall. Things depended on
the exact timing of the arrival of the packets.
While 3.4x is fairly old, it should still be fine. I suggest
updating it as well to avoid a bug in all versions of xntpd
before 3-5.87 that can make the daemon quit with a error message
about "time step too large" with a number like 2^30 seconds.
The program didn't reject server answers that were correct except
for a few high bits. One public server started sending such
broken packets in December 1996.
The current version is
ftp://ftp.udel.edu/pub/ntp/testing/xntp3-5.90.2.tar.gz
which should be much better !!! I haven't tried it yet, but
downloaded it last night.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 14 Jul 1997 08:00:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for MVS5.1? [-/+]
X-Keywords: FAQ [-/+] MVS [-/+] SNTP [-/+]
In article <01bc8fef$8134ad00$39518ed0@pooter>, "Ed Jones" <ejones1@nr.infi.net> writes:
|> We have a need to synch the clocks on all of our servers. We don't need
|> to synch to UTC, but we need all the Unix servers to match the Mainframe's
|> time.
|> Is there an xntpd daemon for MVS?
This is a FAQ. The answer is "we believe not, nor likely to be".
It would be fairly easy to port my SNTP program to MVS and run it
in server mode, but porting xntp would be a horrendous task (if it
were possible at all, which is doubtful).
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: "Marc Brett" <Marc.Brett@waii.com> [-/+]
Date: 14 Jul 1997 17:51:46 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for MVS5.1? [-/+]
X-Keywords: mainframe [-/+] Mills [-/+] MVS [-/+]
Ed Jones <ejones1@nr.infi.net> wrote:
> We have a need to synch the clocks on all of our servers. We don't need
> to synch to UTC, but we need all the Unix servers to match the Mainframe's
> time.
> Is there an xntpd daemon for MVS?
A Sysplex Timer can control the clock(s) on the mainframe(s). An
RS-232 cable connects that to a PC, which in turn can set the clock on
the Timer. Run an NTP client on the PC, and write another daemon to
deliver time messages from the PC down the serial cable and into the
Timer. All the Unix servers just run vanilla NTP.
That's the theory anyway. If it works for you, please send the source
for the daemon to Dave Mills.
--
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: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 14 Jul 1997 17:22:18 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
In article <Pine.LNX.3.96.970713172850.6239M-100000@reflections.eng.mindspring.net>, Todd Graham Lewis <tlewis@mindspring.net> writes:
|> Is NTP adequate? What improvements would people like to see?
|>
|> Anyone care to say (or speculate) what advances are planned for the next
|> year with xntp?
I am not overly optimistic that any more changes WILL be advances :-(
One of the reasons that xntp is starting to become so unreliable is
that it has grown in complexity beyond all reason. The algorithm
always was diabolically complex, but the code base has become almost
completely unstructured. Without a complete rewrite to simplify it,
any significant extra features will cause large numbers of extra
problems.
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.
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: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 14 Jul 1997 14:39:57 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
X-Keywords: TAI [-/+] update [-/+]
In article <Pine.LNX.3.96.970713172850.6239M-100000@reflections.eng.mindspring.net>, Todd Graham Lewis <tlewis@mindspring.net> writes:
: Is NTP adequate? What improvements would people like to see?
:
: Anyone care to say (or speculate) what advances are planned for the next
: year with xntp?
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.
Perhaps the base timescale should be TAI with UTC offset transmitted in
the protocol together with indication of when the next update is to occur,
similar to the way GPS does. However this would be a significant change
to the protocol and would place more requirements on Stratum 1 servers,
particularly the non-GPS ones that don't give advance leap second warnings.
The other thing that we don't currently get but which a TAI-based
protocol should support is distributing a list of leap-second insertion
points. This is necessary for calculating exact delta times into the past
using UTC as the endpoints of the interval. Again this adds extra
requirements on Stratum 1 servers, but the database is small with
only occasional updates.
J
From: The Browns <suneedle@erols.com> [-/+]
Date: Tue, 15 Jul 1997 18:39:01 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TCP Based Service [-/+]
X-Keywords: firewall [-/+] TCP [-/+] UDP [-/+]
Marc Albert wrote:
>
> One problem with NTP as it stands today is that it is based upon UDP and
> UDP is not allowed through most firewalls as a matter of policy. Does
> anyone
> know a way of delivering NTP services via TCP or tunneled through some
> TCP based service.
>
> Thanks in advance.
>
> /Marc
You could always use the firewall as your NTP server.
--Jerry Brown
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 16 Jul 1997 10:51:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
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)
Ulrich
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 16 Jul 1997 16:14:28 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? [-/+]
X-Keywords: SNTP [-/+] stability [-/+]
In article <WIU09524.97Jul16125147@rrzc4>, wiu09524@rrzc4 (Ulrich Windl) writes:
|> 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)
No, that is a matter of stability over SPACE - what NTP needs is
stability over TIME. The UK has had a national grid for longer
than most countries and the frequency certainly used to wander by
several percent from the nominal 50 Hz. Even if a mains frequency
clock was right at the end of the day, it might be off by several
seconds at various times during the day. It is quite possible that
the modern mains supplies are extremely consistent, because it is
now 25 years later.
But long-term accuracy is only part of the point. The other one
is how long you can go between resynchronisations, and THAT is
where quartz clocks really help. I run my SNTP client with one
packet every 5-24 hours (depending), and I can maintain BETTER
consistency with my single NTP server than it can maintain with
its parents and peers (using full NTP). And this remained the
case when my link spent some weeks falling apart because of a bad
repeater.
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: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 18 Jul 1997 02:36:53 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNTP for unix?
X-Keywords: implementation [-/+] SNTP [-/+]
In article <33CE6581.77E7C350@east.sun.com>,
Brian Utterback <brian.utterback@east.sun.com> wrote:
>I am looking for a SNTP client implementation, preferably for UNIX.
>
>Anybody got an SNTP implentation I can look at?
Yes. Look at dist/msntp-1.3.tar.gz (I think) on oozelum.csi.cam.ac.uk.
There is a further (and almost certainly final) version due shortly.
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: Todd Graham Lewis <tlewis@mindspring.net>
Date: Tue, 15 Jul 1997 00:02:35 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for MVS5.1? [-/+]
X-Keywords: Linux [-/+] mainframe [-/+] MVS [-/+]
On 15 Jul 1997, Ed Jones wrote:
> Sorry, perhaps I wasn't clear. I know it's tough to set the time on the
> mainframe. I merely want to use the mainframes clock to set the unix
> machines. So, I need an ntp SERVER for the mainframe. I'm begining
> to see it's not likely I'm going to get one. THanks for the help, however.
Even if there's no ntp server for MVS, you might be able to find an rdate
server or, all else failing, use ICMP timestamps. These will probably be
good enough for your purposes (~1sec accuracy?).
--
Todd Graham Lewis Manager of Web Engineering MindSpring Enterprises
(800) 719-4664, x2804 Linux! tlewis@mindspring.net
From: markl@glyphic.com (Mark Lentczner)
Date: Wed, 16 Jul 1997 13:00:05 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp problem on Linux
X-Keywords: configuration [-/+] Linux [-/+] loopstats [-/+]
In article <5p8c9q$308@netnews.upenn.edu>, hughett@galton.psycha.upenn.edu
(Paul Hughett) wrote:
> I am running xntp version 3.5f under Linux 1.2.13 on an Intel
>486 but it is not managing to synchronize to the timeserver;
>instead, xntp is setting the clock forward by 0.43 sec every
>38 minutes.
This is your problem: Your system's timing is off by 188.6 parts per
million more than xntp can handle. So, while xntp is trying valiantly to
correct, you still drift. When it gets far off, xntp does a step rather
than a slew. When it steps it looses syncronization with the other time
sources (as thier offset appears to jump by the step amount.) If you use
a newer version of xntp (say 3.5-90), it won't even do that.... (long
story).
You can double check that this is the problem by looking at the ntp.drift
file (which directory this is in depends on your configuration). If this
value in this file is pegged at a value (in your case probably about +87),
then yes, this is what's happening. If you're keeping loopstats, look at
the last column. If it doesn't fluctuate, but stays pegged, this another
clue.
Simple fix: Kill xntpd. As root run "tickadj". This will print out the
current version of 'tick'. Add two (there is a 100 to 1 ratio between
this number and parts per million off of the clock). Then run "tickadj v"
where v is the new value. Start xntpd. Example:
& killall xntpd
& tickadj
tick = 9995
& tickadj 9997
& xntpd
Note that your tickadj might have slightly different command syntax.
Remember: you want to set the 'tick' variable, not the 'tickadj' variable.
Now add the "tickadj v" line to your start up scripts just before the line
that runs xntpd on boot. Note that once calcualted, "v" is contant.
-----------------------
Mark Lentczner
Glyphic Technology
markl@glyphic.com
http://www.glyphic.com/
From: eggert@twinsun.com (Paul Eggert) [-/+]
Date: 18 Jul 1997 17:38:23 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: TAI [-/+]
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.
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 20 Jul 1997 09:15:37 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: TAI [-/+]
In article <wkracwtm9n.fsf@vggas.com>,
James Youngman <JYoungman@vggas.com> wrote:
> When was UTC introduced?
In 1972.
> Before that, did GMT have leap-seconds with respect to TAI?
No. Back then GMT referred to UT2, a slightly irregular time
scale, without leap seconds, defined by the Earth's rotation.
The term GMT is ambigouos and obsolete, and should really be
avoided anytime you want an accuracy where leap seconds matters.
Instead use one of the more precisely defined terms UTC, UT0,
UT1 or UT2.
--
----------------------------------------------------------------
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: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) [-/+]
Date: 15 Jul 1997 21:06:55 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TCP Based Service [-/+]
X-Keywords: TCP [-/+] UDP [-/+]
In article <01bc9159$33b75120$50f168a8@marc.driscollfarm.com> you write:
>One problem with NTP as it stands today is that it is based upon UDP and
>UDP is not allowed through most firewalls as a matter of policy.
The correct solution to which is application of a stiff board to the
heads of network managers who are under the bizarre illusion that this
makes their systems more secure.
>Does
>anyone
>know a way of delivering NTP services via TCP or tunneled through some
>TCP based service.
No. How could there be? TCP makes no guarantees that data will be
delivered expeditiously.
If the management is that paranoid, then they should probably invest
the $4000 or so that it would take to get a proper GPS-referenced
dedicated NTP server.
-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: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 21 Jul 1997 10:02:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: 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.
J
From: Brian K. Garrett <bkg@teleport.com>
Date: 21 Jul 1997 14:42:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: TAI [-/+]
L. F. Sheldon, Jr. <lsheldon@creighton.edu> wrote:
: 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)?
It stands for Temps Atomique Internationale, or International Atomic Time.
Unlike pre-1972 GMT, which had (as has been mentioned) seconds which were
"stretched" or "shrunk" depending on the vagaries of the earth's rotation,
TAI (on which UTC is based) uses the standard Systeme International second
as determined by cesium clocks.
Now it's my turn. What does ROF mean?
Brian Garrett <bkg@teleport.com>
From: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 21 Jul 1997 10:29:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Question about NTP timezone
X-Keywords: daylight [-/+] delay [-/+] resolution [-/+] RFC [-/+] timezone [-/+]
In article <5qntp0$hp2@pegasus.rutgers.edu>, modoski@pegasus.rutgers.edu (David Modoski) writes:
: I need to ask a question that is probably very obvious. Does NTP communicate
: at a universal time? From the RFC I'm assuming it is UTC. This would make
: sense to me since each host can adjust the time accordingly. However, is
: there any way that once my NTP server is set that I can send out the NTP
: time to our internal machines relative to the time zone on our internal
: NTP server??
NTP distributes UTC and it relies on the local machines knowing which
timezone they are in. There is no facility in the protocol for signalling
timezone information. Well-designed operating systems maintain an offset
from UTC which is applied when local time is requested. On Unix systems
this uses information kept in a 'zoneinfo' directory which also has
daylight saving time rules.
Of the other time protocols 'time' (port 37) defines its time as GMT seconds
since the start of this century and says nothing about timezones.
'daytime' on port 13 returns an ASCII string with the local time & date,
but it only has 1 second resolution and indeterminate network delay.
J
From: djb@koobera.math.uic.edu (D. J. Bernstein) [-/+]
Date: 22 Jul 1997 13:36:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: TAI [-/+]
L. F. Sheldon, Jr. <lsheldon@creighton.edu> wrote:
> What is "TAI" (besides a strange dance I see young folk doing on
> occasion)?
TAI is the foundation of the universe. TAI is the _real_ time standard.
More precisely, it's real time, without leap seconds. UTC is some number
of seconds away from TAI; a leap second is a change in that number.
Storing times in TAI is better than storing times in UTC, for the same
reason that UTC is better than local time. It's a shame that NTP got
this wrong.
---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html
From: Achim Gratz <gratz@ite.inf.tu-dresden.de> [-/+]
Date: 23 Jul 1997 13:52:09 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd server suddenly stops working
srp336@optimum.com (Steven R. Pfister) writes:
> We've been using xntpd for over a year and a half now, running under
> SunOS 4.1.3. It's been working fine, until a few weeks ago. I haven't
> seen any errors in any logs, but the /etc/ntp.drift file hasn't changed
> and the time is several minutes behind another server, which uses the
> exact same time server and which seems to be having no problem. Where
> should I start to debug this?
I've seen this too, with various xntpd versions (haven't had time to
try .90.x versions yet). It seems happy to synchronise to the wrong
time at an offset of +-{1,16,god knows what else} seconds. I help
myself in this case by rdate'ing the machine in question as long as
the drift file seems to be ok. Oftentimes the deamon just consumes
cycles and doesn't seem to synchronise at all, in which case a restart
is in order. I've played with nice and raising priority seems to help
a bit, but once after a while it just hangs there.
Does anyone know why trimming the clock doesn't work on Ultra's?
Tickadj works fine and shows a changed tick value, but the clock
frequency stays the same.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
From: Harald Koch <chk@utcc.torontou.edu>
Date: Tue, 22 Jul 1997 14:09:55 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: synchronized [-/+] TAI [-/+]
James Youngman wrote:
>
> The information I was really after was information about the "Unix
> epoch"; I have seen it referred to as "00:00, Jan 1 1970 UTC" but I
> suspect that calling it "UTC" here is misleading since our current
> version of UTC did not exist at that time.
Calling it UTC is also misleading in that no UNIX system I'm aware of
keeps track of leap-seconds. Thus UNIX time is like TAI, except that
it is synchronized to the current UTC-TAI difference. In still other
words, UNIX time is not terribly useful for keeping timestamps, since
those timestamps "move" in time whenever leap-seconds occur.
(What would one call such a time scale, other than "broken"? :-)
--
chk@utcc.utoronto.ca
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 22 Jul 1997 11:03:03 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: TAI [-/+]
In article <5qvc45$5de$1@pheidippides.axion.bt.co.uk>,
John Sager <jcs@zoo.bt.co.uk> wrote:
> 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.
--
----------------------------------------------------------------
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: 22 Jul 1997 11:16:34 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
In article <5qvodd$1ar8$1@mail1.wg.waii.com>,
Marc Brett <Marc.Brett@waii.com> wrote:
> 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.
....and precisely how is "UT" defined? :-)
UT too is ambiguous -- it may meay UT0, UT1, UT2, or UTC. Use "UT" only
when the differences between the various UT's are insignificant (which
should be in most situations).
> Best not to use it at all.
Agreed!
--
----------------------------------------------------------------
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: Ian G Batten <I.G.Batten@batten.eu.org> [-/+]
Date: 23 Jul 1997 07:25:51 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: UTC introduced when? [-/+]
X-Keywords: FreeBSD [-/+] TAI [-/+] timezone [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
In article <5r3fhu$erp$1@khavrinen.lcs.mit.edu>,
Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote:
> 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.
I've not looked at it in a while, but when we got NTP fired up on a very
early NetBSD (0.something --- this was pre-FreeBSD, pre-OpenBSD, and a
386 machine we _bought_ _for_ _the_ _purpose_, which make it when,
1994?) we noticed that NTP was consistently 14? 18? seconds off from our
other systems. We finally realised this was the UTC/TAI offset.
ian
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQB1AwUBM9Wx+coy0yij3IvtAQHV1gL/UoO/sVclFTNMIhk1GqPuF84/VgN83KAY
4WTj4qWl+8KOcRMKCgzDJVS9y0WfGvADBBhDURqm4Tw8WY7OX2qlnwWjOG9ooiVI
4lhZ15umqkRRZLVd3c9GiyvLU/eTYhmX
=BZUv
-----END PGP SIGNATURE-----
From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]
Date: 21 Jul 1997 19:45:20 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Windows NT [-/+]
X-Keywords: implementation [-/+] Windows [-/+]
>I am searching for a NTP implementation for Windows NT 4.
>Some idea?
Does "implementation" mean server or client?
In any case, the you can find pointers to software which runs on NT from the
NTP home page at:
http://www.eecis.udel.edu/~ntp/
And the source and executable for my 95/NT client can be found at:
http://home.att.net/~Tom.Horsley/ntptime.html