From: neil@nharris.demon.co.uk (Neil Harris) [-/+]
Date: Thu, 27 Feb 1997 11:15:06 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local time source
X-Keywords: fudge [-/+] synchronised [-/+]
(posted and emailed)
In article <33137575.5438@sol.amd.com>, Jeff Short <short@sol.amd.com> wrote:
>I know I have seen it posted here sometime in the past but, I cannot
>seem to locate it now (when I need it).
>
>Does anyone know how to setup a xntpd server so that it syncs to its own
>clock. (i.e. it treats it's local unix clock as the master). I currently
>have an isolated
>network where it is important to have the clocks synced to each other
>but the absolute value of time is not important.
>
>Please respond by email to the below address.
>--
>
>Jeff Short
Try
server 127.127.1.0
fudge 127.127.1.0 stratum 10
in /etc/ntp.conf
This will make your server appeaer to be a stratum 11 server,
when synchronised to its local clock (127.127.1.x)
-- Neil
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 27 Feb 1997 23:04:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd wierd driftfile values
X-Keywords: SNTP [-/+] stability [-/+]
In article <331573D1.694C@tfs.com>,
Joost van Vroonhoven <joost@tfs.com> wrote:
>
>This seems due to very high values in the /etc/ntp.drift file,
>which I've seen to contain values like -22000 and 24000.
>When I remove the file, effectively setting the value to zero,
>and bring xntpd back up, it synchronises nicely inside 10 minutes.
I find it simply astounding that xntp stores a single value in the
drift file, because even my simple SNTP client stores more like 1K.
There is just no way that a program can recover enough information
from a single value to maintain stability. But I am a statistician
by training, and so regard the estimation of errors as of equal
importance to the estimation of the values :-)
I would recommend upgrading xntp, and using an alternative mechanism
to check for xntp going gently bananas.
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: 4 Mar 1997 11:35:11 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp 3-5.89 Hogs CPU on Solaris 2.5
X-Keywords: bug [-/+] configuration [-/+] SNTP [-/+]
In article <tkevans.857338570@barkeep>, tkevans@barkeep.es.dupont.com (Tim Evans) writes:
|> I've just installed 3-5.89 on a bunch of Solaris 2.5 machines (including
|> some x86 hardware). I used the suggested change to /etc/systems in the
|> hints file. On all of the systems, however, xntpd shoots up to 50-90%
|> CPU utilization within a few hours of startup. The correc time's nice,
|> but users can't do anything on the systems which are too busy setting
|> their timeclocks to do anything else.
|>
|> Anyone have a solution?
1) Back off to a working version of xntp and wait for it to be
fixed properly.
2) Use an alternative method (e.g. my SNTP code) while you wait
for xtnp to be fixed properly.
3) Take a deep breath, put an icepack on your head, pour yourself
a large whisky, and try to debug the code.
That problem indicates that there is a serious error in xtnp's own
internal checking - it should just not DO that, no matter how badly
things are going wrong. At best, fiddling with the configuration
will merely hide the underlying bug.
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: "Douglas W. Hogarth" <DougHo@internetMCI.com>
Date: 4 Mar 1997 03:15:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: pushing time to clients
X-Keywords: broadcast [-/+] bug [-/+] poll [-/+] synchronized [-/+] update [-/+] Windows [-/+]
I am the author of the TimeServ program that you mention.
It is not "supported" but if you are on a LAN you could try something like
the following:
Edit the client's TimeServ.ini to say Type=NTP and
NTPServer=BroadcastClient (then run TimeServ -update and restart the time
service).
When you want to "push", have an NTP server broadcast an NTP packet to the
network which includes that client.
If the time didn't change by some gross amount (such as over 12 hours),
TimeServ should immediately query the server which made the broadcast, and
set the time (then it will loop back, waiting for another broadcast).
Presumably a Solaris NTP client could do similar (but probably would set
the time from the broadcast rather than performing the extra query).
If I have a bug in TimeServ relating to the above, I'm willing to try to
fix it. But I'm probably not interested in enhancing the feature (such as
to remove the extra query or allow gross time changes), and I don't plan to
write the broadcast/NTP server (the piece doing the "push") since it
probably already exists in xntpd source code.
--
Doug Hogarth's Home Page http://www.digitaldaze.com/dougho/
Bjoern Haake <bxh@dsc.com> wrote in article <33170BBC.53F9@dsc.com>...
>
> We have a small cluster with 6-10 nodes (Windows
> NT 4.0 and also two Solaris machines). We want to
> have the synchronized, but not necessarily after
> a very accurate outside source, e.g. one NT
> machine is considered to be the time server. I
> tried out different programs (TimeSync, TimeServ)
> and I was able that clocks could synchronize in
> the specified interval via a poll. We would also
> like to 'push' the time. That means when the time
> is changed at the server, it should be immediately
> reported to all the nodes in the cluster (NT AND
> Solaris). I couldn't figure it out with those two
> mentioned programs (Cadence didn't even install).
From: Kevin Oberman <oberman@es.net> [-/+]
Date: 04 Mar 1997 12:39:14 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for VMS [-/+]
X-Keywords: CHU [-/+] synchronized [-/+]
"Weeble" <richard.beckett@ukonline.co.uk> writes:
> Good old DTSS (Distributed Time Synchronization System ?)
>
> Part of Decnet Extensions (No longer supported), and Decnet/OSI (now called
> Decnet/Plus ?)
>
> We've been running it for at least 5 years, and it proves very reliable.
DTSS is very good for synchronizing many systems. It has many nice
capabilities, but is very different in basic philosophy from ntp.
ntp is, in theory, a system to accurately set system times. DTSS is a
system to synchronize the time multiple systems.
While this sounds like the same thing, it is NOT.
NTP tries to sync to a single source. It uses a number of calculations
to try to determine which available source is most likely correct and,
as long as it does not decide to switch to another source, it uses no
input from any other source.
DTSS takes the times on multiple systems and synchronizes them to
match. If these systems include systems synced to an external source
like CHU, GPS, or WWV, all of the systems will tend to drift to match
the synced system.
Both tend to give you systems synchronized to a standard source, but
NTP will tend to be more accurate and to converge more quickly. But it
will be less stable. If it determines that a given source is not
longer the best, it can "jump". (Not instantly, but it will drift the
time to a slightly different source.)
DTSS will tend to be very stable as a group of clocks will be averages
and, if some are linked to an external source, all will drift to that
time. But it is usually slow to converge and less accurate.
Both are likely good enough to meet the needs of most applications,
but in some cases the differences are significant.
I will also mention that DCE's time system is based on DTSS and shares
its characteristics. So this is applicable to non-DECnet systems, as
well.
--
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: "Weeble" <richard.beckett@ukonline.co.uk>
Date: 4 Mar 1997 20:01:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for VMS [-/+]
X-Keywords: VMS [-/+]
Good old DTSS (Distributed Time Synchronization System ?)
Part of Decnet Extensions (No longer supported), and Decnet/OSI (now called
Decnet/Plus ?)
We've been running it for at least 5 years, and it proves very reliable.
Pankaj Arora <parora@citicorp.com> wrote in article
<5fe0ve$32v@spruce.citicorp.com>...
> How can I synchronise TIME for a network of VMS machines running
> DECNet.
> --
>
________________________________________________________________________
> Pankaj Arora EMail: pankaj.arora@citicorp.com
> CGIN - Citibank N.A., 51 Bras Basah Rd
> #07-03 Plaza By The Park, Singapore 18994
>
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 4 Mar 1997 21:56:44 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for VMS [-/+]
X-Keywords: peer [-/+] SNTP [-/+] synchronized [-/+] VMS [-/+]
In article <l4rahvz91p.fsf@congo.llnl.gov>,
Kevin Oberman <oberman@es.net> wrote:
>
>DTSS is very good for synchronizing many systems. It has many nice
>capabilities, but is very different in basic philosophy from ntp.
>
>ntp is, in theory, a system to accurately set system times. DTSS is a
>system to synchronize the time multiple systems.
>
>While this sounds like the same thing, it is NOT.
>
> ...
>
>Both tend to give you systems synchronized to a standard source, but
>NTP will tend to be more accurate and to converge more quickly. But it
>will be less stable. If it determines that a given source is not
>longer the best, it can "jump". (Not instantly, but it will drift the
>time to a slightly different source.)
>
>DTSS will tend to be very stable as a group of clocks will be averages
>and, if some are linked to an external source, all will drift to that
>time. But it is usually slow to converge and less accurate.
Well, well, well. Most interesting. Now, if anyone ports an SNTP
system to those, we shall have three different models! I don't really
like using the term SNTP, because the techniques are ancient, but it
simplifies discussion. In any case, the model has the properties:
It converges much faster than NTP, is more stable, but is the
least accurate method. In particular, it uses information only
from the servers on a direct path back to the 'root' (i.e. true
time). No peer information is used.
If anyone ports my code to VMS, please tell me how tricky it was :-)
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: "Greg Schueman" <schueman@ix.netcom.com> [-/+]
Date: 5 Mar 1997 05:11:09 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for Win NT
X-Keywords: bug [-/+] Windows [-/+]
Joe Philipps <rchandra@hal9000.buf.servtech.com> wrote in article
<5f2mvb$qvg$1@post.servtech.com>...
> One thing I'd like to note is that at one time (where I work...I'm not
> there now), I had downloaded some binary distribution of NTP :-(sorry,
> don't remember where) and went through the install on 3.51
> Workstation. This particular package would not install under 4.0
> (claimed that the Windows version was wrong). It became an
> automatically started service. Subsequently, I upgraded to 4.0. The
> service was not removed, but seems to continue to function just fine
> under 4.0 SP1.
Being the author of the installer for XNTP on NT, the problem was a
bug/feature
in the version of InstallShield SDK used to compile it. Newer versions
install
fine on NT 4.0.
>
> I guess what I'm saying is, if you've gotten NTP for 3.51, you don't
> need to re-acquire it just because you switch to 4.0.
True, however the latest version has a number of bug fixes, and supports
the Local_Clock as a reference source. The latest compiled version for NT
is
XNTP3-5.87.6.
You can find it at: ftp://ftp.drcoffsite.com/ntxntpbin-*.zip
For access send email to <access@drcoffsite.com>.
-Greg
From: "Maciej W. Rozycki" <macro@macro.ds2.pg.gda.pl>
Date: Tue, 4 Mar 1997 21:05:31 +0100 [-/+]
Newsgroups: comp.os.linux.networking,comp.os.linux.setup,comp.protocols.time.ntp
Subject: Re: xntpd 3-5.89 and rdate.nlm [-/+]
X-Keywords: Novell [-/+]
On 3 Mar 1997, Rockingham Memorial Hospital wrote:
> that it had changed ports from the previous version. The old version
> queried port 37 and the new version queried port 123.
>
> My question is this: Did any old version of xntpd support port 37 and has
> it since discontinued support for that port? I can't think of any other
> reason why my setup doesn't work anymore. RDATE.NLM from MurkWorks is
> pretty old, 1992, I think, so it most likely polls on port 37. If xntpd
> doesn't support port 37 anymore, is there another product for Novell that
> I can use? Is there a way I can make xntpd listen on port 37?
123 is the correct port for the ntp service. Port 37 is for the time
service that is independent of ntp and is served by a different daemon.
Just look into '/etc/inetd.conf' and ensure you have a line like:
time stream tcp nowait nobody /usr/sbin/in.timed in.timed
In this case, 'in.timed' is the name of the daemon ('intimed' is the name
of the RPM package).
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
From: longyear@net.com.com (Al Longyear)
Date: Thu, 6 Mar 1997 14:31:00 GMT [-/+]
Newsgroups: comp.os.linux.networking,comp.os.linux.setup,comp.protocols.time.ntp
Subject: Re: xntpd 3-5.89 and rdate.nlm [-/+]
"Maciej W. Rozycki" <macro@macro.ds2.pg.gda.pl> writes:
> 123 is the correct port for the ntp service. Port 37 is for the time
>service that is independent of ntp and is served by a different daemon.
>Just look into '/etc/inetd.conf' and ensure you have a line like:
>time stream tcp nowait nobody /usr/sbin/in.timed in.timed
>In this case, 'in.timed' is the name of the daemon ('intimed' is the name
>of the RPM package).
Redhat has this incorrect. It is probably not so much RedHat as it is
that they copied the sample from somewhere else. It is that sample
which is incorrect. (See the man page for 'timed' on your redhat
system.)
'in.timed' is a daemon and is meant to be started by the rc startup
scripts. It is not a inetd service any more than named is an inetd
service.
The 'time' protocol that you need to add to inetd is internal. Adding
the lines:
time dgram udp wait root internal
time stream tcp nowait root internal
to the /etc/inetd.conf file and telling inetd to reload the file will
enable rdate to work against the computer. The identd process handles
the time protocol internally.
To get ntpdate to work against the system, you will need xntpd which
is also started by the rc startup scripts.
--
Al Longyear longyear@netcom.com
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 6 Mar 1997 19:39:14 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate [-/+]
X-Keywords: delay [-/+] dispersion [-/+] filter [-/+] firewall [-/+] multicast [-/+] precision [-/+]
Howdy,
The only difference between the "ntpdate <server>" that fails and the
"ntpdate -d <server>" which looks fine is that the 2nd one uses an un-privledged
IP port and the first one uses port 123. The next step in debugging this
possilbe firewall problem is to try:
ntpdate -u <server>
NOTES: as root of course
I think this switch exists in that rev of ntpdate
Also "ntptrace <server>" uses un-privledged packets and defaults to version 1.
If that works, the evidence is that the un-privledged packets make it
and the privledged don't, which usually points to a picky firewall between
you and the proposed <server>. If this is the case xntpd won't make it
to the same server either.
I hope this or the other responses gets you pointed in the right direction.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
-----
Alastair Young (younga1@midas-kapiti.com) wrote:
: I cannot get ntpdate to set the time on my Sun (4.1.3)
: ntpdate -d looks ok (see below) but ntpdate fails (see below).
: I've debugged it and (I think) it thinks that the delay is zero
: in clock_select() - why I don't know. Any ideas?
: [Strange that it should be happy to work out my offset and
: then refuse to set the time...]
: ---------
: # ntpdate ntp2.mcc.ac.uk
: ntpdate ntp2.mcc.ac.uk
: 5 Mar 18:53:20 ntpdate[4137]: no server suitable for synchronization
: found
: ---------
: # ntpdate -d ntp2.mcc.ac.uk
: 5 Mar 18:53:05 ntpdate[4136]: ntpdate version=3.4x (beta multicast);
: Sat Mar 1
: 13:18:52 GMT 1997 (1)
: transmit(130.88.200.4)
: receive(130.88.200.4)
: transmit(130.88.200.4)
: receive(130.88.200.4)
: transmit(130.88.200.4)
: receive(130.88.200.4)
: transmit(130.88.200.4)
: receive(130.88.200.4)
: transmit(130.88.200.4)
: server 130.88.200.4, port 123
: stratum 2, precision -6, leap 00, trust 000
: refid [193.62.83.9], delay 0.08873, dispersion 0.00098
: transmitted 4, in filter 4
: reference time: b6c83df6.91d90000 Wed, Mar 5 1997 18:46:14.569
: originate timestamp: b6c83fb0.1ce9c000 Wed, Mar 5 1997 18:53:36.112
: transmit timestamp: b6c83f91.d5441000 Wed, Mar 5 1997 18:53:05.833
: filter delay: 0.09041 0.08873 0.08894 0.09390
: 0.00000 0.00000 0.00000 0.00000
: filter offset: 30.25501 30.25600 30.25528 30.25291
: 0.000000 0.000000 0.000000 0.000000
: delay 0.08873, dispersion 0.00098
: offset 30.256001
: 5 Mar 18:53:05 ntpdate[4136]: step time server 130.88.200.4 offset
: 30.256001 sec
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 07 Mar 1997 09:35:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate [-/+]
Another thing to watch out is: If xntpd is running on the local
machine, port 123 is busy and ntpdate refuses to set the time.
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 07 Mar 1997 11:20:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: program versions [-/+]
Currently there is no possibility to find out the version of a NTP
daemon other than looking at the startup message. xntpdc has a version
command, but it only shows its own version. Wouldn't it be wise to
have such a thing? Unfortunately it's rather late to start with that
now.
As 3.5f ist widely spread, but called a "beta", I wonder which
versions are currently running at udel...
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 7 Mar 1997 13:29:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How do I deal with timezones? [-/+]
X-Keywords: bug [-/+] FAQ [-/+] timezone [-/+]
In article <332004CB.20B1@cisco.com>, Ove Hansen <ohansen@cisco.com> writes:
|>
|> I can't believe this could be so difficult, I've read the FAQ and
|> www.eecis.udel.edu and pointers from there and "grepped -i" for
|> "timezone" and "time zone" through my xntp3-5.89-export source tree,
|> but I'm still stuck. All I want is to use "ntpdate" to set the
|> time when my systems boots up, pointing to an NTP server in another
|> timezone. ntpdate works, the time is set, however it's set to the
|> time on the remote server, which depending on where the client is
|> can be hours wrong. My /etc/TIMEZONE file contains "TZ=WET" for
|> example, and tracing shows ntpdate opens /usr/share/lib/zoneinfo/WET.
|> This is under Solaris 2.5.1 BTW. Any pointers would be extremely
|> welcome.
All Unix timestamps are in UTC (which used to be called GMT), and
I have difficulty believing that ntpdate has a bug so crass. The
reason that /usr/share/lib/zoneinfo/WET is being read is almost
certainly because the C library is doing so either as part of its
setup, or to format a diagnostic.
If you are in the WET zone (as I assume you are), then the obvious
cause is that the servers you are pointing at have been totally
incorrectly set up - this is fairly common. But, before moaning
at their administrators, check that you are quite sure of your
facts - it is very easy to get confused by having incorrect TZ
variable settings when you display the time. And all systems set
them up slightly differently and usually incompetently :-(
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: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 7 Mar 1997 23:19:06 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How do I deal with timezones? [-/+]
X-Keywords: FAQ [-/+] syslog [-/+] timezone [-/+]
Howdy,
As others have pointed out, un*x systems and ntp all work in
UTC (Zulu or GMT) time. The entire xntp package only uses timezone
to display times in the logfile or to display to the user.
ntpdate -d <server> lists the ref, orig, and xmit times in
this process's timezone by using the localtime() call, and then
once more at the end when it prints the syslog'ish line. It is
the system library routines that get the timezone.
If the "ntpdate <server>" is on a radio clock that is
mis-configured to output local time, or if the server is using
its un-disiplined clock as a reference, the server could be
giving "bad time". Try another server.
You might be prove a crazy server by using "ntpq -p <server>".
Look at the reference ids. Most public servers contact several
time sources and the xntpd program will print a message and die
if its servers are on UTC and the server isn't. ("step too large")
I think that very few public servers have ever been off due to timezone.
The most likely problem is that your system isn't configured
with a sensible default timezone. While this seems very simple,
I've seen very strange errors when /etc/TIMEZONE doesn't set
the default timezone to the local wallclock. It is so easy for
root to "date <wallclock time>" when the TZ is UTC. Since
each process has its own TZ, mistakes can get masked. Check your
startup scripts such as $HOME/.profile (or ~/.cshrc ~/.login)
for some special treat left behind...
If you ask your system "date -u", it should return the
UTC time. Or (for /bin/sh) "$ TZ=0 date" You might want to
try (again sh) "TZ=0 ntpdate -d <server>".
My Solaris 2.5 system has "tail -1 /etc/TIMEZONE"
TZ=US/Mountain
Most users are in this timezone and are happy to just let the
default environment variable make things right. When I travel
to other timezones, I sometimes put a "TZ=US/Central" in my
.profile, so I still get the timezone I'm calling in from.
Another possible blunder that would produce wild timezone effects
would be to misname or somehow mangle the /usr/share/lib/zoneinfo/
files. The library programs access the "zic" compiled zoneinfo
files to convert system time (UTC seconds since 1970) to human
readable / sensible text strings like 1997 Mar 7 15:56:25. While
I've never met such a problem, the possiblities are endless....
If this is the case, I'd reload the entire /usr/share/lib/zoneinfo
for the distribution or another host that isn't messed up.
The home of the timezone geeks seems to be:
ftp://elsie.nci.nih.gov
Happier chiming ! remember to start very simple and add in
complexity when the first stuff is working.
Bruce Bartram bbartram@etl.noaa.gov
-----
Ove Hansen (ohansen@cisco.com) wrote:
: Hi all,
: I can't believe this could be so difficult, I've read the FAQ and
: www.eecis.udel.edu and pointers from there and "grepped -i" for
: "timezone" and "time zone" through my xntp3-5.89-export source tree,
: but I'm still stuck. All I want is to use "ntpdate" to set the
: time when my systems boots up, pointing to an NTP server in another
: timezone. ntpdate works, the time is set, however it's set to the
: time on the remote server, which depending on where the client is
: can be hours wrong. My /etc/TIMEZONE file contains "TZ=WET" for
: example, and tracing shows ntpdate opens /usr/share/lib/zoneinfo/WET.
: This is under Solaris 2.5.1 BTW. Any pointers would be extremely
: welcome.
: Thanks in advance,
: Ove Hansen
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 8 Mar 1997 11:10:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How do I deal with timezones? [-/+]
X-Keywords: configuration [-/+] timezone [-/+]
In article <5fq7pa$kj7$1@mwrns.boulder.noaa.gov>,
Bruce Bartram <bwb@etl.noaa.gov> wrote:
>
>If you ask your system "date -u", it should return the
>UTC time. Or (for /bin/sh) "$ TZ=0 date" You might want to
>try (again sh) "TZ=0 ntpdate -d <server>".
>
>My Solaris 2.5 system has "tail -1 /etc/TIMEZONE"
> TZ=US/Mountain
>Most users are in this timezone and are happy to just let the
>default environment variable make things right. When I travel
>to other timezones, I sometimes put a "TZ=US/Central" in my
>.profile, so I still get the timezone I'm calling in from.
Watch out for this, however. Life is not so simple. You can typically
set the timezone in several of the following ways:
When compiling the kernel.
By the system maintenance tool.
In the kernel or system configuration files (if any).
In the system initialisation scripts (e.g. /etc/rc).
In the scripts that start the system daemons (e.g. inet).
In the system's initial profiles (e.g. /etc/profile).
In the default profiles you are set up with.
If you are lucky, all except the first two will set the zone by setting
the TZ variable. /etc/TIMEZONE is often confusing, because it may be
used by several of the above steps (or ignored completely). But you are
then at the mercy of the C library as to whether it uses the TZ variable,
reads /etc/TIMEZONE (or equivalent) itself or uses the system call to
read the kernel variable. And not all commands will call the C library,
anyway :-(
This problem is getting rarer, as the influence of POSIX is spreading,
but it still occasionally causes confusion. The best 100% reliable way
of finding out the time your systems is running on is to print the value
returned from the time() system call and compare it with a known correct
system.
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: Gwilym Rowlands <Gwilym.Rowlands@osi.co.uk>
Date: Mon, 10 Mar 1997 17:09:39 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Which time protocol NTP or DTS [-/+]
X-Keywords: configuration [-/+] documentation [-/+] DTS [-/+]
I am looking into the problem of which time protocol to use
when creating a DCE configuration, consisting of multiple
cells, each with multiple systems. The network of systems
must be suitable for hosting applications which span multiple
cells and require a single view of the correct time. Although
the time only needs to be accurate to a second, it is
important that all systems within the network are the same.
The obvious answer is to use the DCE DTS service, however this
does not seem capable of co-ordinating the time between
multiple cells. It is true that it can cope with connections
over WAN links, however that still seems to be within a single
cell.
The DCE manuals suggest that one DTS system within the cell
is defined to be the master and that it takes it's time from
an NTP source. This would mean you use NTP between cells and
DTS within cells. However this seem unnecessarily complex.
The last idea seems to be to use NTP throughout the network and
not to bother with DTS. However the downside to this option is
that NTP does not seem to be as tolerant as DTS, when dealing
with inaccuracies introduced by network failure.
This seems a rather fundamental question, yet one that the
any documentation seems reluctant to discuss further than simply
introducing the options. Does anyone have any experience of
this situation and any recommendations?
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 11 Mar 1997 20:35:18 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Solaris 2.5.1 [-/+]
X-Keywords: timezone [-/+]
In article <5g1kb9$abj$3@skynet.usb.ve> Manual wrote:
: Please, sorry my english
Seems as good as mine !
: I'm trying to use ntp on a Solaris network but I have a problem, I'm in
: Venezuela and the timezone here is AST = GMT-4 but ntp works correctly only
: with GMT+4. What could be happening ?
: Thanks.
Here is the short version of my email followup
Howdy,
WARNING: I only have about a years experience with xntpd.
Solaris 2.5 - sparc, xntp3-5.89.8. I suggest you change to version
ftp://louie.udel.edu/pub/ntp/testing/xntp3-5.89.8.tar.gz
or
ftp://louie.udel.edu/pub/ntp/xntp3-5f.tar.gz
if you have anything in between.
I think that you have a typical timezone problem, compounded by some
missing or broken files if your machine has the same stock timezone
stuff that mine has. My zoneinfo file GMT-4 seems to be GMT+4.
In my opinion, the correct solution is to, as root
zic /usr/share/lib/zoneinfo/southamerica
and set your default to TZ=America/Caracas. Of course, I disclaim
all knowledge of how this really works.
xntpd only uses timezone stuff to print logfile messages or other
user text output. It runs completely in UTC seconds since 1900
in the NTP format.
In my opinion, the default timezone for a system should be whatever
is neede to make the "date" command return the same answer as
"wall clock" (local time). This information lives in the file
/etc/TIMEZONE (a link to /etc/default/init). My last line looks like:
tail -1 /etc/TIMEZONE
TZ=US/Mountain
The timezone refers to a binary file in the /usr/share/lib/zoneinfo/ and
in my case the US directory Mountain file.
These files are the output of the "zic" zone info compiler. Sun delivers some of the
files already to use. When I looked in the distribution package on this Solaris 2.5
host, I found that the text file /usr/share/lib/southamerica had Venezuela as being
GMT-4 since 1965, but I didn't find the .../America/Caracas file. I used zic to
make the file, and I think that you should do the same if you don't already have it.
Here is what I did to test it. I moved to a test directory and ran :
zic -d . /usr/share/lib/zoneinfo/southamerica
and found it had created directory America with a bunch of files for various
interesting places in South and Central America. As root, I then
mkdir /usr/share/lib/zoneinfo/America
cp America/Caracas /usr/share/lib/zoneinfo/America/
and tested the results, as a simple user, by
/bin/sh
$ TZ=America/Caracas date
Tue Mar 11 16:09:23 AST 1997
$ date -u
Tue Mar 11 20:09:27 GMT 1997
If you don't have a correct TZ for root, when the operator sets the time
by "date -s 12:34" or whatever, entering the time on the wall clock, ntp
will shift things back to UTC when you run ntpdate, and it appears that
the problem is due to ntp.
It seems that the timezone geeks live at
ftp://elsie.nci.nih.gov
Happy Chiming Bruce Bartram bbartram@etl.noaa.gov
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 11 Mar 1997 22:11:57 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Solaris 2.5.1 [-/+]
X-Keywords: daylight [-/+] prefer [-/+] timezone [-/+]
follow-up to my earlier followup
Bruce Bartram (bwb@etl.noaa.gov) wrote:
: In article <5g1kb9$abj$3@skynet.usb.ve> Manual wrote:
: : I'm trying to use ntp on a Solaris network but I have a problem, I'm in
: : Venezuela and the timezone here is AST = GMT-4 but ntp works correctly only
: : with GMT+4. What could be happening ?
: : Thanks.
: I think that you have a typical timezone problem, compounded by some
: missing or broken files if your machine has the same stock timezone
: stuff that mine has. My zoneinfo file GMT-4 seems to be GMT+4.
When I went and looked into /usr/share/lib/zoneinfo in more detail,
I read the etcetera file. The basic filenames GMT-4 are in the
POSIX offset format. For users who prefer the "old style, non-POSIX"
format, use Etc/GMT-4. I checked that every Etc/ file was the exact match
for the base file after exchanging + and -.
So the "broken" thing, in my limited opinion, is the POSIX format choice
of sign, and not my host or Sun's distribution. Since I've never
been good at making sign decisions, I think that I must forgive POSIX,
and at least it is a standard.
The correct answer is still "zic /usr/share/lib/zoneinfo/southamerica"
and use TZ=America/Caracas. This allows for political changes in
daylight savings time and gives the zone name AST.
From: Mike O'Connor <mjo@dojo.mi.org> [-/+]
Date: Mon, 10 Mar 1997 21:20:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Binary dist. XNTP for IRIX 5.3 or 6.2 [-/+]
X-Keywords: SGI [-/+]
In article <01bc2989$19ef41e0$e9011e8b@win95tst1.cetelco.dk>,
Mads Ladefoged <mads.ladefoged@cetelco.dk> wrote:
:Do anybody know where to find a binary dist of XNTP in a recently version
:to run on SGI IRIX 5.3 or 6.2??
Check out:
http://reality.sgi.com/scotth_corp/info/xntp.html
--
Michael J. O'Connor WWW: http://dojo.mi.org/~mjo/ Email: mjo@dojo.mi.org
InterNIC WHOIS: MJO (has my PGP & Geek Code info) Phone: +1 810-848-4481
=--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"It's a lot more fun to blame things than to fix them." -Calvin
From: Mike O'Connor <mjo@dojo.mi.org> [-/+]
Date: Mon, 10 Mar 1997 21:20:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Binary dist. XNTP for IRIX 5.3 or 6.2 [-/+]
X-Keywords: SGI [-/+]
In article <01bc2989$19ef41e0$e9011e8b@win95tst1.cetelco.dk>,
Mads Ladefoged <mads.ladefoged@cetelco.dk> wrote:
:Do anybody know where to find a binary dist of XNTP in a recently version
:to run on SGI IRIX 5.3 or 6.2??
Check out:
http://reality.sgi.com/scotth_corp/info/xntp.html
--
Michael J. O'Connor WWW: http://dojo.mi.org/~mjo/ Email: mjo@dojo.mi.org
InterNIC WHOIS: MJO (has my PGP & Geek Code info) Phone: +1 810-848-4481
=--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"It's a lot more fun to blame things than to fix them." -Calvin
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 07 Mar 1997 09:35:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate [-/+]
Another thing to watch out is: If xntpd is running on the local
machine, port 123 is busy and ntpdate refuses to set the time.
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 11 Mar 1997 10:48:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: DTS [-/+] SNTP [-/+]
In article <33244052.5F5F@osi.co.uk>, Gwilym Rowlands <Gwilym.Rowlands@osi.co.uk> writes:
|>
|> The last idea seems to be to use NTP throughout the network and
|> not to bother with DTS. However the downside to this option is
|> that NTP does not seem to be as tolerant as DTS, when dealing
|> with inaccuracies introduced by network failure.
This will depend on how consistent the systems' clocks are, and
how long the network failure is likely to last. We had quite
severe problems with a repeater, and this led to effective
inaccessibilities of the order of a day or two, but even SNTP kept
the time consistent to within 0.2 seconds. However, despite the
fact that one system has a 57 ppm drift, its clock is pretty
consistent and therefore drift correction works well. Note that I
was using my SNTP client and not xntp.
If you require internal consistencies of 0.01 seconds or less, then
things are much harder. I know that xntp can be set up to provide
this, but it isn't easy and I don't know how prone it is to going
wrong (or even haywire).
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: Harold Lockhart <hal@platsol.com> [-/+]
Date: Thu, 13 Mar 1997 11:23:34 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: configuration [-/+] documentation [-/+] DTS [-/+] synchronized [-/+]
Gwilym Rowlands wrote:
>
> I am looking into the problem of which time protocol to use
> when creating a DCE configuration, consisting of multiple
> cells, each with multiple systems.
[...]
> The obvious answer is to use the DCE DTS service, however this
> does not seem capable of co-ordinating the time between
> multiple cells.
I was hoping Rich or somebody would comment on this aspect. There is no
obvious architectural reason why DTS could not coordinate across
multiple cells, but DCE does not permit it, or at least the way to do it
is not documented.
> This seems a rather fundamental question, yet one that the
> any documentation seems reluctant to discuss further than simply
> introducing the options. Does anyone have any experience of
> this situation and any recommendations?
My recommendation is to use DTS in conjunction with a few GPS time
receivers. You can buy such devices as a PC card for $300 or less. If
you have one (or two) in each cell, all time will be synchronized. The
major advantage of DTS is that time is authenticated. This is not a
theoretical problem, a couple of years ago some attackers defeated a
Securid system by spoofing NTP and doing a replay.
Hal
=================================================================
Harold W. Lockhart Jr. Platinum Solutions Inc.
Chief Technical Architect 8 New England Executive Park
Email: hal@platsol.com Burlington, MA 01803 USA
Voice: (617)273-6406 Fax: (617)229-2969
=================================================================
From: rsalz@osf.org (Rich Salz)
Date: 13 Mar 1997 16:57:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: DTS [-/+]
In <33282A06.3D5E@platsol.com> hal@platsol.com writes:
>I was hoping Rich or somebody would comment on this aspect. There is no
>obvious architectural reason why DTS could not coordinate across
>multiple cells, but DCE does not permit it, or at least the way to do it
>is not documented.
Well, with an invitation like that...
I think the best way to do this is in DCE 1.2.2 with the "global groups"
you can add foreign entitites into your local main-DTS cell ACL's.
/r$
From: sam@cs.stir.ac.uk (Sam Nelson) [-/+]
Date: 12 Mar 1997 09:10:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timetravel in NT [-/+]
X-Keywords: daylight [-/+] DST [-/+] timezone [-/+]
In article <5fnrjl$1m10$1@news-s01.ny.us.ibm.net>, svercek@ibm.net (John Svercek) writes:
| I need to determint the time in GMT given a future date and timezone
| (taking into account daylight savingst time). Is there a system function
| which will do this. If not, I think there exists a system table which
| contains the rules for every timezone. Where is it so I could write the
| translator myself.
|
This is impossible in any general sense, because in many parts of the world,
and hence many timezones, the DST switch isn't decided algorithmically and is
often only decided a year at a time. For example, in the UK at present, there
are still arguments going on about whether we should `synchronise' with `the
rest of Europe', i.e., move everything forward one hour, and there are noises
from France apparently about abolishing DST altogether (now _there's_ a smart
idea...!).
Any attempt to predict `localtime' anywhere in the world more than a few
months ahead is doomed to failure---I reckon.
--
Sam. (Insert bandwidth-wasting disclaimer here)
Any scientific advancement that comes about as the result of Scots
doing strange things to sheep must be regarded as highly suspect...