From: Simon Brickle <sbrickle@poboxes.com>
Date: Mon, 01 Dec 1997 13:58:40 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Monitoring NTP networks [-/+]
X-Keywords: FAQ [-/+] monitor [-/+] monitoring [-/+] synchronised [-/+]
Hello,
Here's a question that seems to be unanswered in the FAQ and other
newsgroup postings:
Once you've got your whole network nicely synchronised with NTP and
running smoothly, how do you make sure it stays that way ? I mean, are
there any good strategies or points to watch when monitoring the
operation of a network of NTP clients ?
I'm trying to use Tivoli, a systems management system, to watch my NTP
clients and make sure they stay under control. Messages written in
system log seem to vary between different platforms, so I'm basing my
monitors on two things:
1. The xntpd daemon is running, and
2. The value written to the drift file remains within +-100
If anyone else has set up a system to monitor xntpd's activity, please
let me know how you did it and how well it works.
Cheers,
Simon
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 02 Dec 1997 13:21:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: More xntp configuration problems [-/+]
X-Keywords: auth [-/+] delay [-/+] dispersion [-/+] monitor [-/+] poll [-/+] reset [-/+] stability [-/+] synchronized [-/+]
In article <3482D16B.7754882B@advim.no> Toralf Lund <toralf@advim.no> writes:
> OK. I _thought_ I had got an NTP sub-net up and running, but now I'm not
> quite so sure anymore. The clocks nearly run in sync, but inspecting the
> syslogs and using ntpq, I can see that synchronisation is frequently
> lost for no apparent reason. Re-synchronisation usually occurs after a
> few minutes. The following sequence of messages is typical:
>
> Dec 1 15:40:06 5D:wichita xntpd[7944]: time reset (step) -0.828887 s
A step of 0.8s should only happen after a restart of the daemon. If
you are getting a time step during nominal operation, you network
connection my be terribly slow.
> Dec 1 15:40:06 6D:wichita xntpd[7944]: synchronisation lost
> Dec 1 15:46:07 6D:wichita xntpd[7944]: synchronized to 193.214.130.1,
> stratum=3D4
>
> Also, ntpq commands 'pe' and 'as' often cause the message "select()
> returns 1" to be printed (please refer to a separate posting on this).
Strange, very strange: I never saw that. I'm running 2.0.32 here
without resets:
wiu09524@pc3103:/home/wiu09524 > ntpq -np
remote refid st t when poll reach delay offset disp
==============================================================================
+129.132.98.11 129.132.2.21 2 u 155 64 377 53.88 -3.221 1.98
-134.214.100.6 157.99.60.10 2 u 45 64 377 83.57 -1.039 16.51
-130.159.62.4 193.62.83.9 2 u 171 128 374 130.71 32.263 23.07
*130.159.132.11 192.93.2.20 2 u 35 64 377 114.56 -16.291 9.28
-134.226.81.3 129.132.2.21 2 u 82 256 273 154.02 -47.816 27.01
x194.207.34.9 129.211.2.1 3 u 790 1024 266 1234.09 448.183 854.69
193.78.78.34 131.188.41.1 2 u 870 1024 232 219.36 -49.023 2317.12
193.78.78.35 131.173.17.7 2 u 152 512 347 239.20 -68.115 2037.64
+132.199.98.103 129.132.1.11 3 u 51 64 377 2.69 -5.286 2.21
As you can see the dispersion can be quite high, so configure at least
three servers near (in terms of network topology) you.
[...]
> Can anybody tell me what I'm doing wrong? (And why is this so bloody
> hard? - I don't think I'm _that_ stupid...)
Try enabling statistics for further reference. Yoou can enable/disable
the file generation dynamically once you've configured it.
Again here I have
reference time: b82e88ce.9abc6000 Tue, Dec 2 1997 14:17:02.604
system flags: auth monitor pll kernel_sync
frequency: 0.000 ppm
stability: 94.486 ppm
Note that the frequency is stable (0.000).
From: "Brian K. Garrett" <bkg@user2.teleport.com> [-/+]
Date: 1 Dec 1997 20:13:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: WWVB upgrade status
X-Keywords: NIST [-/+] WWVB [-/+]
The planned power boost on WWVB from 13 kW to 40 kW is nearing completion.
According to NIST's web site (for which I have lost the URL; it's findable
through Altavista though) there will be scheduled service interruptions
between December 16 and 23, with the exact times and durations of such
interruptions to be announced.
I have not seen this info being publicized much but it seems that with so
many NTP systems relying on WWVB transmissions, a bit of a warning would
be in order so as to avoid some administrative headaches just before the
holidays. :)
Brian Garrett
bkg@teleport.com
From: Andrew Hood <ajhood@fl.net.au> [-/+]
Date: Tue, 02 Dec 1997 23:57:21 +1100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: More xntp configuration problems [-/+]
X-Keywords: reset [-/+] synchronized [-/+]
Toralf Lund wrote:
> OK. I _thought_ I had got an NTP sub-net up and running, but now I'm not
> quite so sure anymore. The clocks nearly run in sync, but inspecting the
> syslogs and using ntpq, I can see that synchronisation is frequently
> lost for no apparent reason. Re-synchronisation usually occurs after a
> few minutes. The following sequence of messages is typical:
>
> Dec 1 15:40:06 5D:wichita xntpd[7944]: time reset (step) -0.828887 s
> Dec 1 15:40:06 6D:wichita xntpd[7944]: synchronisation lost
> Dec 1 15:46:07 6D:wichita xntpd[7944]: synchronized to 193.214.130.1,
> stratum=4
>
That's what happens when the clock gets stepped. The algorithm has to
reestablish synchronisation. You will probably have this happening fairly
regularly.
I forget who suggested this algorithm for trimming the clock. I have
modified it for Linux from the original for Solaris, but the principle
remains the same.
0. Watch the value in ntp.drift and when it seems to stabilise continue at
step 1.
1. run tickadj without any options to get the value of tick.
2. calculate a new value of tick
newtick = oldtick*(1+drift/2^20)
3. run tickadj with the new value of tick.
4. repeat from step 0
eg for Linux (taken from another system - mine doesn't drift enough for
this calculation to change tick)
~# cat /etc/ntp.drift
269.799
~# tickadj
tick = 10000
~# echo 'scale=7; t=10000*(1+269.799/2^20)+0.5;scale=0;t/1'|bc
10003
~# tickadj 10003
or if you like to do it in one line (Linux only)
~# echo "scale=7;`tickadj`;drift=`cat /etc/ntp.drift`;
t=tick*(1+(drift)/2^20)+0.5;scale=0;t/1"|bc
10003
Drift may be negative in which case the new tick will be smaller than the
old tick
----- lots of stuff on which I have no comments deleted -----
Andy
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 02 Dec 1997 13:29:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: newby question... please advise... [-/+]
X-Keywords: fudge [-/+] synchronized [-/+]
In article <34833E0F.2C0E09FA@kodak.com> Kambiz Aghaiepour <kambiz@kodak.com> writes:
> I'm about to start using xntpd on a group of systems in a couple of our
> data centers. We are about to purchase GPS time sources that will be
> connected to dedicated time servers broadcasting NTP packets. Before
> the time servers are in place, I was planning on setting up two
> "pretend" time servers using internal clocks (at strata 10 and 12,
> master and slave) and preconfigure all clients to sync to these servers
> so that I don't have to change anything other than the server
> configurations once my time servers are in.
>
> My concern is, is there any danger of xntpd setting clocks backwards in
> time? My thinking is that if I never issue ntpdate, that xntpd will
Yes, xntpd CAN set the time backwards, but if you "fudge the drift" of
your local "fake server", just make it loose time until the true time
is later. Then time will jump forward. Now if you tell me your DBAs
don't like the time to jump forward either, you can compile xntpd with
SLEW_ALWAYS (or very similar). The xnptd will patiently be using
adjtime() to slew the clock.
I do NOT recommend using SLEW_ALWAYS after your clocks were set
up. Maybe just start your database after xntpd has synchronized.
> just slow or speed up the clock ticks until it gets to the "correct"
> time (which may take several days). I just want to make sure I don't
> upset any DBAs because system clocks *might* go backwards as a result of
> corrections.
>
During in-sync phase the time will not jump (more than a few microseconds).
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 2 Dec 1997 16:43:37 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: newby question... please advise... [-/+]
X-Keywords: SLEWALWAYS [-/+]
Kambiz Aghaiepour <kambiz@kodak.com> writes:
>I'm about to start using xntpd on a group of systems in a couple of our
>data centers. We are about to purchase GPS time sources that will be
>connected to dedicated time servers broadcasting NTP packets. Before
>the time servers are in place, I was planning on setting up two
>"pretend" time servers using internal clocks (at strata 10 and 12,
>master and slave) and preconfigure all clients to sync to these servers
>so that I don't have to change anything other than the server
>configurations once my time servers are in.
This should work fine. The rest of the net thanks you for remembering
to set your pseudo-servers at stratum 10 and 12! Accidents happen on
the best run networks. Bogus low-stratum numbered NTP packets have
a nasty habit of escaping and getting out into the wider world, where
they don't belong.
>My concern is, is there any danger of xntpd setting clocks backwards in
>time? My thinking is that if I never issue ntpdate, that xntpd will
>just slow or speed up the clock ticks until it gets to the "correct"
>time (which may take several days). I just want to make sure I don't
>upset any DBAs because system clocks *might* go backwards as a result of
>corrections.
Yes, it is possible for xntpd to step the clock backwards. However,
It is unlikely to happen once you have a stable drift value for the
local clock, and as long as you use ntpdate to set the system time at
system startup, before you start xntpd, and before you start your
database server programs. As Ulrich points out, you can compile with
SLEWALWAYS #define'ed to keep xntpd from ever stepping backwards, but
that has some drawbacks. Chiefest among the drawbacks is that if your
clock accidentally gets way out of sync (as can happen with very long
network delays between client and server) it may take a very long time
(days...) to get back into sync.
Enjoy!
Rick
From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 2 Dec 1997 22:28:43 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How benst to sync NT and Win95 clients? [-/+]
X-Keywords: Arbiter [-/+] PPS [-/+] SNTP [-/+]
Followup to: <WIU09524.97Dec2143124@rrzc4>
By author: Ulrich Windl <+DELETE_THIS+Ulrich.Windl@rz.uni-regensburg.de>
In newsgroup: comp.protocols.time.ntp
>
> In article <34837DBE.2AEBAD48@goodnet.com> "Geoffrey T. Cheshire" <gches@goodnet.com> writes:
>
> > I've got AtomTime and Dimension 4 on my win clients, but they can't seem
> > to talk to my Linux box. I get, e.g., "Unable to get time (error
> > 10061)" from AtomTime. Dimension 4 can SNTP to various hosts around the
> > net, but not mine. Any ideas?
>
> Simply check whether your Linux box serves NTP requests. I don't know
> AtomTime, but I use the rest with success.
>
We use D4 here, and our primary time source is a Linux box hooked up
to an Arbiter GPS receiver. With Ulrich's PPS patches[1] and xntpd,
it keeps time within about ±10 µs (the GPS receiver itself is rated at
1 µs). Most machines running the full xntpd can sync to it within
less than ±1 ms, even across routers; the D4 hosts are not quite that
good, but they certainly don't seem to complain.
The Arbiter box is very nice, a real plug-in solution; my only
complaint is that the PPS signal it produces has the "wrong" polarity,
although the newer iterations of Ulrich's patches handle that in
software.
-hpa
[1] Huge thanks to Ulrich and Ingo for incredible patience while
trying to debug this setup...
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
From: carl-junk@five-ten-sg.com (Carl Byington) [-/+]
Date: Wed, 03 Dec 1997 04:02:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd broadcast [-/+]
X-Keywords: auth [-/+] authentication [-/+] broadcast [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
In article <65unpt$kpt$1@news.vol.cz>, M.Kubecka@sh.cvut.cz says...
>So my broadcast address is 192.168.42.255 and my ntp.conf is:
[snip]
>broadcast 192.168.42.255
>#=20
>#=20
>
>But still nothing :-(((
>
>Can anyone hlep me????
For my subnet, on the server side I use:
broadcast 205.147.40.63
and on the clients I use:
disable auth
enable bclient
broadcastclient 205.147.40.63
The default seems to be to require authentication for the broadcasts
and I did not want to bother with that.
- --
Mail address munged for the obvious reason - remove the junk.
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
-----BEGIN PGP SIGNATURE-----
Version: 4.5
iQCVAwUBNITZ5NZjPoeWO7BhAQH4awQAh7u/MiLX+P3cQIW86XEurMZSpYzeCkTT
1cAr65bILNttvMnamBMjx6x4qcQ9DXXdnGa81qbe9nEDhY1eBetdDBky19JBi2aF
396wJhczhzBMGH3UHP5LGMtUE49jPe5HruH7/RcGNUCq69Q/YRe2p/YdPFI0yxr6
JmxMbsEPO3g=
=n4N0
-----END PGP SIGNATURE-----
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 03 Dec 1997 08:14:54 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: NTP FAQ v2 available
X-Keywords: FAQ [-/+]
I'd like to announce the availability of a new (hopefully final, at
least for this time) version of the NTP FAQ.
It's not a FAQ in the strict sense; it's a collection of "interesting"
(whatever that means) news and mail articles collected by Rick Thomas.
I did a conversion to HTML (plus some days of programming a suitable
utility). I also did formal HTML verification using James Clark's SGML
parser SP. Mostly tested with text-mode browser "lynx-2.7", some
versions of Netscape and IE 4 (was it "Incredible Executable"?, oh no,
it's the Internet Explorer ;-) The result of that all is available as
GNU-zipped tar on
ftp://pcphy4.physik.uni-regensburg.de/pub/wiu09524/NTP-FAQ-2E.tar.gz
and it is available online on
http://www-nw.rz.uni-regensburg.de/~wiu09524/faq2E.htm
(The compressed size is almost 500kB, the unpacked size is 2MB
distributed in abou 60 files of varying size)
Regards,
Ulrich Windl
From: Scott Henry <scotth@sgi.com>
Date: 03 Dec 1997 10:33:13 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.sys.sgi.admin
Subject: Re: More xntp configuration problems [-/+]
X-Keywords: SGI [-/+]
>>>>> "T" == Toralf Lund <toralf@advim.no> writes:
T> Does anyone know how to do this on an SGI? The Irix kernel doesn't have
T> a 'tickadj' value, only 'timetrim'. My question is really:
T> How do I calulate a new value for timetrim based on the one in
T> /etc/ntp.drift?
timetrim is in the units of nsec/sec (10^-9), but the value of
ntp.drift has changed between NTP releases (I've forgotten what the
ratio is). As long as the system can sync, you shouldn't worry about it.
I have found that if an `autoconfig -f` creates a /unix.install that
is different in size than /unix, that rebooting with the new kernel
will usually make a system sync again. I haven't been able to trace
the real problem...
--
Scott Henry <scotth@sgi.com> / Help! My disclaimer is missing!
IRIX MTS, / GIGO *really* means: Garbage in, Gospel Out
Silicon Graphics, Inc / http://reality.sgi.com/scotth/
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 4 Dec 1997 15:49:03 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.sys.sgi.admin
Subject: Re: More xntp configuration problems [-/+]
X-Keywords: SGI [-/+]
Toralf Lund <toralf@advim.no> writes:
>Does anyone know how to do this on an SGI? The Irix kernel doesn't have
>a 'tickadj' value, only 'timetrim'. My question is really:
>How do I calulate a new value for timetrim based on the one in
>/etc/ntp.drift?
The following is extracted from IRIX 6.4 /var/sysgen/mtune/kernel
>
> *
> * tunables for timer
> *
...
> * timetrim: The clock is adjusted by this signed number of nanoseconds
> * every second. It is limited to 3 milliseconds or 0.3% in clock.c.
> * Timed(1M) and timeslave(1M) put suggested values in /usr/adm/SYSLOG.
> *
> timer: static
>
> * name default minimum maximum
...
> timetrim 0
>
>
So the Units for timetrim are nanoseconds/second, and the use is as a
number to be added to '1,000,000,000' nanoseconds/second which is the
"base" clock rate.
The units for the number in the ntp.drift file are microseconds/second
(or parts-per-million) and it's use is as a number to be added to the
base ntp clock rate of '1,000,000' microseconds/second.
Based on that analysis, I'd guess that the correct algorithm is to
multiply the drift number by 1000 (convert from microseconds to
nanoseconds) and plug the result in for "timetrim".
Give it a try, and let us know how it works for you.
Enjoy!
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 2 Dec 1997 16:43:37 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: newby question... please advise... [-/+]
X-Keywords: SLEWALWAYS [-/+]
Kambiz Aghaiepour <kambiz@kodak.com> writes:
>I'm about to start using xntpd on a group of systems in a couple of our
>data centers. We are about to purchase GPS time sources that will be
>connected to dedicated time servers broadcasting NTP packets. Before
>the time servers are in place, I was planning on setting up two
>"pretend" time servers using internal clocks (at strata 10 and 12,
>master and slave) and preconfigure all clients to sync to these servers
>so that I don't have to change anything other than the server
>configurations once my time servers are in.
This should work fine. The rest of the net thanks you for remembering
to set your pseudo-servers at stratum 10 and 12! Accidents happen on
the best run networks. Bogus low-stratum numbered NTP packets have
a nasty habit of escaping and getting out into the wider world, where
they don't belong.
>My concern is, is there any danger of xntpd setting clocks backwards in
>time? My thinking is that if I never issue ntpdate, that xntpd will
>just slow or speed up the clock ticks until it gets to the "correct"
>time (which may take several days). I just want to make sure I don't
>upset any DBAs because system clocks *might* go backwards as a result of
>corrections.
Yes, it is possible for xntpd to step the clock backwards. However,
It is unlikely to happen once you have a stable drift value for the
local clock, and as long as you use ntpdate to set the system time at
system startup, before you start xntpd, and before you start your
database server programs. As Ulrich points out, you can compile with
SLEWALWAYS #define'ed to keep xntpd from ever stepping backwards, but
that has some drawbacks. Chiefest among the drawbacks is that if your
clock accidentally gets way out of sync (as can happen with very long
network delays between client and server) it may take a very long time
(days...) to get back into sync.
Enjoy!
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 4 Dec 1997 15:49:03 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.sys.sgi.admin
Subject: Re: More xntp configuration problems [-/+]
X-Keywords: SGI [-/+]
Toralf Lund <toralf@advim.no> writes:
>Does anyone know how to do this on an SGI? The Irix kernel doesn't have
>a 'tickadj' value, only 'timetrim'. My question is really:
>How do I calulate a new value for timetrim based on the one in
>/etc/ntp.drift?
The following is extracted from IRIX 6.4 /var/sysgen/mtune/kernel
>
> *
> * tunables for timer
> *
...
> * timetrim: The clock is adjusted by this signed number of nanoseconds
> * every second. It is limited to 3 milliseconds or 0.3% in clock.c.
> * Timed(1M) and timeslave(1M) put suggested values in /usr/adm/SYSLOG.
> *
> timer: static
>
> * name default minimum maximum
...
> timetrim 0
>
>
So the Units for timetrim are nanoseconds/second, and the use is as a
number to be added to '1,000,000,000' nanoseconds/second which is the
"base" clock rate.
The units for the number in the ntp.drift file are microseconds/second
(or parts-per-million) and it's use is as a number to be added to the
base ntp clock rate of '1,000,000' microseconds/second.
Based on that analysis, I'd guess that the correct algorithm is to
multiply the drift number by 10 (convert from microseconds to
nanoseconds) and plug the result in for "timetrim".
Give it a try, and let us know how it works for you.
Enjoy!
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 5 Dec 1997 16:27:18 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.sys.sgi.admin
Subject: Re: More xntp configuration problems [-/+]
rbthomas@lilypad.rutgers.edu (Rick Thomas) writes:
>Based on that analysis, I'd guess that the correct algorithm is to
>multiply the drift number by 10 (convert from microseconds to
^^^^
Should be 1000 (Obviously!)
>nanoseconds) and plug the result in for "timetrim".
>Give it a try, and let us know how it works for you.
>Enjoy!
>Rick
Sorry for the confusion!
Rick
From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 7 Dec 1997 11:17:16 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd, ntpdate and 'Daylight Savings Time' [-/+]
X-Keywords: AIX [-/+] synchronized [-/+] timezone [-/+]
Followup to: <348991DE.6C84@k4ziv.erols.com>
By author: rgarber@k4ziv.erols.com
In newsgroup: comp.protocols.time.ntp
>
> Roland Schmidt wrote:
> >
> > I use 'xntpd' with undisciplined local clock. A lot of clients are
> > synchronized with 'ntpdate -B <server>'.
> > This works very well all over the year, except for the day of changing
> > to 'Daylight Savings Time'.
> > Even if the time difference of a client is more then 30 minutes ntpdate
> > changes the clock speed in the wrong direction.
> > We work on a RS/6000 with AIX 4.
> > Could someone help me for solving this problem ?
> A simple solution would be to run the systems in UTC0 and use the
> local timezone variable EST5EDT in the users .profile or .cshrc etc.
> This way you would not be trying to step the clocks one hour and the
> system would take care of local time display.
Any Unix system that keeps its system clock on anything but UTC0 is
misconfigured. The Unix timezone model -- with xntpd/ntpdate relies
on -- is that the system clock is in UTC, and that the system library
is allowed to handle conversion to and from civil time. No jumps or
anything involved, and the system can tell the difference between,
say, Sun Oct 26 01:30:00 PST 1997 (time_t == 877858200) and Sun Oct 26
01:30:00 PDT 1997 (time_t == 877854600).
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
From: Kevin Oberman <oberman@es.net> [-/+]
Date: 05 Dec 1997 08:54:43 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate not recognizing server
X-Keywords: FAQ [-/+] firewall [-/+]
clake@belay.cs.utah.edu (Chad Lake) writes:
>
> I have the problem where I set up a server that is in sync with
> several internet hosts, and it is running xntpd fine. Now, I want to
> set a workstation to get its time from this host. However, on the
> workstation when I try to do a ntpdate I get the error: "4 Dec
> 18:13:30 ntpdate[23218]: no server suitable for synchronization found"
> However, I will say the the workstation CAN convert hostnames into IPs
> (I get the same error if I use the IP number), and this is not on a
> firewall...the machines are on the same subnet.
This is getting to be a real FAQ!
ntpdate will only adjust time to match a server that is close enough
to the system time to drift the clock. It will not step the time
unless the -b option is used.
I normally list several servers on the command line and, at boot time,
use the -b switch to force the system to sync. From that point on, as
long as your system clock is not too bad, ntpdate should work fine if
you can access your servers. And, by specifying multiple servers, your
odds are much better. (I normally sync the time on my home system a
couple of time a day.)
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
From: ktk@ktk.bidmc.harvard.edu (Kristofer T. Karas) [-/+]
Date: 5 Dec 1997 23:07:30 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: cannot compile NTP suite, restrict()
X-Keywords: bug [-/+] restrict [-/+] Slackware [-/+]
Dr. R. Chandra <rchandra@letter.com> wrote:
>I've installed Slackware 3.4 (gcc 2.7.2.3), ...
>gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -I../include -g -O2 -Wall -pipe
>ntp_config.c: In function `getconfig':
>ntp_config.c:1132: parse error before `restrict'
[Added Patrick Volkerding - Slackware's maintainer]
As I mentioned in a previous post, the problem is local to Slackware-3.4.
The gcc-2.7.2.3 that ships with this distribution is broken; however,
H.J.Lu's gcc-2.7.2.3.bin.tar.gz distribution (in the usual
sunsite/tsx-11 directories) works correctly. Install that, and you'll
be able to compile successfully.
To see if the problem was due to misplaced/broken include files, I
preprocessed (gcc -E) ntpconfig.c on a working system
(slackware-3.4 + H.J.'s gcc) and then ran the result verbosely through
gcc (gcc -v) on the vanilla slackware system; surprisingly, the same
error appeared, during gcc's code-generation stage. I say
"surprisingly" because I figured the problem was due to include-file
lossage; instead, it's squarely within the gcc executable (or perhaps
its associated library templates).
Patrick: I did not narrow the bug down to the level of which file in
/usr/lib/gcc-lib was the exact culprit - gcc, or perhaps one
of the syscall templates. i586 defaults not-withstanding,
you may wish to use H.J.'s binary distribution verbatim.
Kris
--
Kristofer Karas * Senior systems engineer/SysAdmin
AMA/CCS DoD RF900RR HawkGT !car * BI Deaconess Medical Center, Boston
"Build a system that even a fool can use, * http://ktk.bidmc.harvard.edu/~ktk/
and only a fool will want to use it." * Will design LISP machines for food
From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]
Date: 07 Dec 1997 15:32:36 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Time from TV broadcast signals? [-/+]
X-Keywords: broadcast [-/+]
I just got a new VCR which can pick up the correct time from a signal
broadcast by some TV stations (not to mention the VCR+ translation table as
well), and I'm just wondering if anyone here knows how accurate those time
signals are?
Is it just someone at the station looking at their watch and setting the
time on some box that adds the signal, or are the signals actually derived
from some reasonably accurate time source?
Just curious...
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+
From: "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> [-/+]
Organization: Universitaet Regensburg, Klinikum
To: rbthomas@lilypad.rutgers.edu (Rick Thomas (Rbt))
Date: Tue, 9 Dec 1997 11:22:37 +0100 [-/+]
Subject: (Fwd) 1 sentence [-/+]
Message-ID: <101D77281F43@rkdvmks1.ngate.uni-regensburg.de>
X-Keywords: FAQ [-/+]
Are you collecting NTP articles for a FAQ`Maybe add that:
Ulrich
------- Forwarded Message Follows -------
From: "Roger Broughton" <R.E.Broughton@newcastle.ac.uk>
Subject: 1 sentence [-/+]
To: Ulrich.Windl@rz.uni-regensburg.de
Date: Mon, 8 Dec 1997 17:25:22 +0000 (GMT) [-/+]
X-Keywords: FAQ [-/+]
> "What is NTP?" is possible the thing that's missing in the
> FAQ. Someone out there with a good 5 sentence summary?
Why 5 sentences?
What about 1:
NTP (Network Time Protocol) is a method by which a computer
can synchronise its clock to other computers' clocks and UTC
over an unreliable network coping with the possibility that
some of the other computer's clocks are wrong.
--
*** Roger Broughton (Operations Supervisor), Computing Service, ***
*** University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK. ***
*** Telephone: +44 191 222 8074 Fax: +44 191 222 8765 ***
From: "Saif Terai" <saif@swi.com.sg>
Date: 9 Dec 1997 01:25:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How benst to sync NT and Win95 clients? [-/+]
X-Keywords: SNTP [-/+]
Geoff,
10061 is a connection refused error. Below is an excerpt from Winsock Help
File. Make sure the daytime server is running on your Linux Box.
Cheers
Saif
saif@swi.com.sg
____________________________________________________________________________
__
WSAECONNREFUSED
(10061)
Connection refused.
No connection could be made because the target machine actively refused it.
This usually results from trying to connect to a service that is inactive
on the foreign host - i.e. one with no server application running.
____________________________________________________________________________
___
I've got AtomTime and Dimension 4 on my win clients, but they can't
seem
to talk to my Linux box. I get, e.g., "Unable to get time (error
10061)" from AtomTime. Dimension 4 can SNTP to various hosts around
the
net, but not mine. Any ideas?
Thanks,
Geoff
From: Matthew.Healy@yale.edu (Matthew D. Healy) [-/+]
Date: Mon, 08 Dec 1997 12:46:59 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time from TV broadcast signals? [-/+]
X-Keywords: broadcast [-/+] WWV [-/+]
In article <66f155$od5@bgtnsc03.worldnet.att.net>,
Tom.Horsley@worldnet.att.net (Thomas A. Horsley) wrote:
> I just got a new VCR which can pick up the correct time from a signal
> broadcast by some TV stations (not to mention the VCR+ translation table as
> well), and I'm just wondering if anyone here knows how accurate those time
> signals are?
There have been previous threads on this topic, and the consensus
seemed to be: it depends on the TV station. Some stations have GPS
boxes, or atomic clocks, or somesuch. Others have the engineer set
the thing by his or her watch from time to time. Many fall somewhere
between. For what it's worth, the "beep" before the hourly news on
WCBS-radio (New York) always seems to be spot-on as far as my ears
can tell.
If you have access to some time source you trust (an NTP server, or
a GPS, or WWV, or whatever), why not test it yourself and see how
your local stations do?
Question: in case it turns out some local stations do better than
others, does any VCR offer the ability to control which stations'
signals are trusted? Or is a feature one turns on globally? Of
course, if the protocol were designed correctly there would be
something equivalent to a stratum number in the signal -- but of
course the stations not bothering to set this correctly would
probably be the same ones that don't bother setting their clocks
accurately...
--------
Matthew.Healy@yale.edu http://ycmi.med.yale.edu/~healy/
As of 20 Oct 1997, only 802 days until Y2K....
Resistance _is_ futile! I have been absorbed by the BORG! After
years of Unix and MacOS, I just got myself a home Windoze Box :-(
From: Craig_Everhart@transarc.com
Date: Mon, 8 Dec 1997 15:34:36 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time from TV broadcast signals? [-/+]
X-Keywords: broadcast [-/+]
Excerpts from netnews.comp.protocols.time.ntp: 8-Dec-97 Re: Time from TV
broadcast .. Matthew D. Healy@yale.ed (1647)
> Question: in case it turns out some local stations do better than
> others, does any VCR offer the ability to control which stations'
> signals are trusted?
I have a Sony VHS VCR with the clock-set feature. The default seems to
be that it will scan for stations with the time signal, but it also says
that it lets you pick a station to use as time source.
Craig
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 8 Dec 1997 14:52:31 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: HP 9000 time sync over ISP
X-Keywords: dial [-/+]
fredbeck@ptd.net (Fred) writes:
>I'm on a quest. I'm trying to time sync all our unix boxes to a
>stratum 2 clock on the net. I now have all the unix boxes
>synchronizing to a HP9000 H50 (running 10.20) using xntp - that part
>works good. Since we don't have any other source of time except the
>internet I'm trying to dial up an ISP over a modem connected to this
>HP H50. My plan is to connect to the internet kill xnptd on my H50
>then run ntpdate on a time source site on the net.
Fred,
Why are you doing this? For roughly twice the cost of the modem
(US$300, or so) you can get a GPS radio that will give you your own
personal stratum 1 clock.
Rick
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 08 Dec 1997 14:31:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: kernel pll on Linux: ntp_gettime
X-Keywords: adjtimex [-/+]
In article <34888EC6.2CBB3193@gondor.apana.org.au> Herbert Xu <herbert@gondor.apana.org.au> writes:
> Hi:
> I'm trying to build xntp3 with libc6 (aka glibc2) on Linux. The
> configure script thinks that kernel pll is not present because it cannot
> find the funciton __ntp_gettime. Now grepping through the source code
> seems to indicate that this function is not actually used. So why does
> its presence indicate the support for kernel pll? I'm going to hack the
> configure script so that it thinks ntp_gettime is there and see what
> happens.
For Linux up to now adjtimex() is used. Future implementations might
implement ntp_adjtime() and ntp_gettime() without the underscores. I
don't know what glibc does. Maybe adjtimex() is not present...
Ulrich
From: Peter Silva <Peter.Silva@ec.gc.ca> [-/+]
Date: Tue, 09 Dec 1997 17:57:18 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd, ntpdate and 'Daylight Savings Time' [-/+]
X-Keywords: timezone [-/+]
H. Peter Anvin wrote:
>
> Any Unix system that keeps its system clock on anything but UTC0 is
> misconfigured. The Unix timezone model -- with xntpd/ntpdate relies
> on -- is that the system clock is in UTC
I'm lucky, we're a scientific shop where UTC actually makes sense to our
users, but in the general case, "UNIX runs UTC" is something of a joke.
In practice, it's the least bad solution, but it's still less than elegant:
-- syslogd clients write times that are in the application time zone,
with no indication of what time zone it's in.
-- cron/rsh jobs do are not "login" shells, so they often do not run
anything to set the environment to the local time zone.
so log messages from a cron job will typically be in UTC, while
interactive or NQS jobs will be in the user time zone.
I've seen workstations with timezones hard coded in the shell
binaries to get around this problem (blech!) I put an
override in /etc/profile and it still doesn't work for things
that aren't login shells (so I have init processes running JST!)
-- having users schedule their jobs in UTC is a pain. overriding
cron's timezone in the appropriate file is a pain too (don't
start cron by hand!)
--
Peter.Silva@ec.gc.ca - Supercomputing, Environment Canada