From: "Maciej W. Rozycki" <macro@amg.gda.pl>
Date: Mon, 10 Nov 1997 12:19:24 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: local clock ignores NTP [-/+]
X-Keywords: calendar [-/+]
On Mon, 10 Nov 1997, Tiaan van Aardt wrote:
> I've been running NTP 3.5f for a longish period on 2 very different
> linux installations. The 1st runs an old slackware, and the second runs
> redhat 4.2. Both run fine, and have no problems. I've now installed NTP
> on a 3rd system, running redhat 4.1 (kernel 2.0.18).
>
> NTP itself runs fine, and other systems can synch to this system, only,
> the system's own local clock doesn't seem to listen to ntp's
> adjustments. Is this a problem with how the system's cmos clock
> interacts with the system clock?
Do you mean that the system time (as reported by `date') gets adjusted
and the calendar clock (as reported by `clock') does not?
If so, then you need to recompile your kernel, setting "Enhanced Real
Time Clock Support" to "yes". You should also check that you have
'/dev/rtc' with major number 10 and minor number 135.
HTH.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 11 Nov 1997 10:02:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: local clock ignores NTP [-/+]
X-Keywords: dosynctodr [-/+]
In article <wvp7mahqdkq.fsf@hobbes.dmi.min.dk> ckc@dmi.min.dk (Casper K. Clausen) writes:
> 'tickadj -s' will disable dosynctodr, which will stop your local clock
> from being modified by the CMOS clock. See the man page for tickadj;
> you might want to look into its other options.
Sorry, but it's a non-issue for Linux. Unless the original poster
gives more details, it's hard to make any valid conclusions.
Ulrich
From: j.b.swenker@ptt-telecom.nl (johan swenker) [-/+]
Date: Mon, 10 Nov 97 14:02:53 MET [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Connection Refused? [-/+]
In article <34642D61.C7D1EB2A@ucsd.edu>, drees@ucsd.edu says...
>
>I get the following error in my logs. However, xntpd seems to be
>working OK. What does that error message mean?
>
>Nov 8 00:13:47 dt6h3n26 xntpd[81]: recvfrom() fd=4: Connection refused
This indicates some kind of network problem. Probably a server to which
xntpd wants to connect does not allow such a connection. Reasons are
firewalls, filtering routers or just a system which does nit run xntpd.
If you have an other server available, xntpd works. If the only (real)
server doesn't work, xntpd doesn't (really) work.
Remark: fd=4 means filedescriptor 4. This is a tcp/ip socket to another
system. To find out more about this file descriptor, start xntpd with
strace xntpd -d 2>&1 | less
(I'm not sure about the -d, I use it to prevent xntpd to become a deamon).
Succes Johan
--
Johan Swenker Phone:+31 50 5855257 E-mail:J.B.Swenker@PTT-Telecom.nl
DISCLAIMER: This statement is not an official statement from, nor does
it represent an official position of, PTT Telecom BV.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 12 Nov 1997 07:30:54 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: server-only xntpd?
X-Keywords: minpoll [-/+] PLL [-/+] release [-/+] update [-/+]
In article <ubtzrih8p.fsf@seanet.com> Scott Blachowicz <sab@seanet.com> writes:
> Andrew Hood <ajhood@fl.net.au> writes:
>
> > ntpdate won't set the clock if xntpd is running. The normal procedure is to
> > either:1. run ntpdate at startup, then xntpd.
> > 2. periodicallly run ntpdate (eg with cron) and not use xntpd.
>
> Yes, I know - I'm trying to figure out if there is some way to do both of
> these:
>
> 1) Use xntpd (or some other NTP server process) to act as a local NTP
> server process on my home network, but without having it also act as an
> NTP client (unless there's some way to control the times it is allowed
> to connect to ITs servers). From my reading of the xntpd man page, I
> figured that using the 'enable pll' directive in the /etc/ntp.conf file
> would do the trick (i.e. keep xntpd from adjust the local clock
> itself), but it looks like ntpdate is looking for the wrong thing when
> it decided that it can't update the system clock. Ntpdate is looking
> for the existence of something listening to the NTP socket as the
> indicator (which is really an indication that the NTP protocol is being
> _served_ by the local system, not necessarily that there is some other
> process updating the local clock).
>
> 2) Use ntpdate (or some other NTP client process) to act as a local client
> on the same system. I want to be able to control the times at which
> the client reaches out over the Internet to grab reference clock times.
>
> Being an intermittantly connected, home network, I don't need precise
> syncing to external reference clocks - I just want to keep it close.
> Hmmm...I suppose I could just have my script that runs ntpdate go off an
> kill an xntpd process if it finds one, then restart it when done, but that
> seems less than graceful.
>
> Or...isn't there an xntpdc command (I forget & I'm at work & all this
> stuff is at home) - would it be possible to have a control request to get
> xntpd to
I might have a solution for your problem: If you use ntpdate to get
the time from else where you could use xntpd as well. You just don't
want a permanent connection. Why don't you add an external refclock
with minpoll 4 dynamically with xntpdc for a few minutes, and then
unconfigure it again. With some shell tricks or Perl in connection
with cron it should work. What about that idea? (You would leave PLL
enabled)
>
> 1) release (and later re-grab) the NTP socket, so ntpdate can run
> successfully, or...
>
> 2) request that NTP update the local clock according to the servers listed
> in its ntp.conf file in spite of having 'enable pll' in there.
>
> Either way I could time schedule a script to keep the clock close to
> reality.
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 13 Nov 1997 08:17:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Why are some servers insane? [-/+]
X-Keywords: auth [-/+] delay [-/+] dispersion [-/+] peer [-/+] poll [-/+] reachable [-/+] USNO [-/+]
In article <bc7cd$b296.14d@mail.five-ten-sg.com> carl@five-ten-sg.com (Carl Byington) writes:
> Sorry about the long lines. All the higher stratum servers appear
> to be insane, but if I remove the stratum 1 servers from ntp.conf and
> restart, my system happily uses them. Is this normal and/or correct?
"Insanity" is a relative property: It's relative to the majority of
servers (that is "the survivors"). If you have a stratum-1 server, and
the rest is at a higher number, it's likely that the stratum-1 server
is believed.
Besides that everything with dispersion above 1000ms is considered
"insane". That does not mean that the server is insane; most of the
time it means that the network connection is insane ;-)
In the example below, the insane group of servers is just off a bit. I
don't know why, but operators of a stratum-1 server should do their
best to calibrate local processing delays to get really close to the
true time. Maybe there are really some bad servers out there.
From my personal experience NTP clusters the servers into groups; one
group is considered valid, while other groups are insane. If the
network congestion affects one host, NTP can suddenly change the group
(because of lost majority). (This is a non-technical description)
>
> rxsh C:\>ntpq -n -c peers
> remote refid st t when poll reach delay offset disp
> ==============================================================================
> 205.147.40.63 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
> 132.239.51.18 159.83.181.41 3 u 842 1024 377 140.20 -12.973 18.28
> 207.82.210.3 204.243.141.160 3 u 583 1024 377 49.88 40.576 14.63
> 192.31.216.30 0.0.0.0 16 u - 1024 0 0.00 0.000 16000.0
> 131.216.1.101 131.216.18.4 4 u 650 1024 355 220.32 51.221 272.55
> *16.1.0.4 .GPS. 1 u 62 1024 377 59.60 7.885 12.68
> +204.123.2.72 0.0.0.0 1 u 199 1024 377 49.24 3.556 14.63
> +164.67.62.194 .USNO. 1 u 65 1024 377 49.61 -6.653 11.47
> rxsh C:\>
> rxsh C:\>ntpq -n -c lassoc
> ind assID status conf reach auth condition last_event cnt
> ===========================================================
> 1 36524 8000 yes no
> 2 36525 9014 yes yes none insane reachable 1
> 3 36526 9014 yes yes none insane reachable 1
> 4 36527 8000 yes no
> 5 36528 9014 yes yes none insane reachable 1
> 6 36529 9614 yes yes none sys.peer reachable 1
> 7 36530 9414 yes yes none synchr. reachable 1
> 8 36531 9414 yes yes none synchr. reachable 1
> rxsh C:\>
> rxsh C:\>ntpq -n -c readv
> status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg
> system="WINDOWS/NT", leap=00, stratum=2, rootdelay=59.60,
> rootdispersion=31.43, peer=36529, refid=16.1.0.4,
> reftime=b814817a.b0f76000 Wed, Nov 12 1997 11:26:50.691, poll=10,
> clock=b81481bc.9c2e5000 Wed, Nov 12 1997 11:27:56.610, phase=1.351,
> freq=1166.67, error=23.57
From: carl@five-ten-sg.com (Carl Byington) [-/+]
Date: Fri, 14 Nov 1997 16:59:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Why are some servers insane? [-/+]
X-Keywords: RFC1305 [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
Ah, I found it. RFC1305, 3.4.4 packet procedure, test 7 insures that
we don't sync with any server at a lower stratum level. This test falls
into the sanity checking, so those servers are simply declared insane,
even if they are actually working properly.
- --
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
iQCVAwUBNGyDStZjPoeWO7BhAQF3VwP/c5YUlkKaUFGpODkMcfO1VyiOHzf4hY7o
aTT2xSgIVVDINTCaLy/gB7oo8XjylLKX3DR1Aa9D2YIUONsjV7pquD+sEGFT09qY
vY336kceNklGQBblY2+NN6qLh+Fu7xpRRItGR3RLL5XOQiZt19YKeiel8bJ1Rx78
NW/AySZ2+/Q=
=PN1Z
-----END PGP SIGNATURE-----
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Date: 17 Nov 1997 11:37:50 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Discrepancy Program [-/+]
X-Keywords: resolution [-/+] UDP [-/+]
In article <64pt5v$27k7$1@emngw1.eastman.com>,
Michael H. Spence <mspence@eastman.com> wrote:
>I am looking for any example programs that can be used to measure the time
>discrepancy between systems. I am trying to put together a graph of range
>of time discrepancies that exist between systems on our corporate LAN. My
>thought is that I would select a single system as a point of reference and
>measure the difference between its internal clock and other systems out on
>the network.
> ...
`timedc`, which is associated with `timed` and part of most of the various
freeware and commercial UNIX systems can measure the difference in clocks
of a collection of systems. It uses the standard UDP time service of the
remove machines to determine their notion of the date, and then uses ICMP
stamps to determine the time skew. It has millisecond resolution.
Vernon Schryver vjs@rhyolite.com
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 17 Nov 1997 19:58:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Discrepancy Program [-/+]
X-Keywords: resolution [-/+] UDP [-/+]
In article <64q2tu$756@calcite.rhyolite.com>,
Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
>In article <64pt5v$27k7$1@emngw1.eastman.com>,
>Michael H. Spence <mspence@eastman.com> wrote:
>>I am looking for any example programs that can be used to measure the time
>>discrepancy between systems. I am trying to put together a graph of range
>>of time discrepancies that exist between systems on our corporate LAN. My
>>thought is that I would select a single system as a point of reference and
>>measure the difference between its internal clock and other systems out on
>>the network.
>> ...
>
>`timedc`, which is associated with `timed` and part of most of the various
>freeware and commercial UNIX systems can measure the difference in clocks
>of a collection of systems. It uses the standard UDP time service of the
>remove machines to determine their notion of the date, and then uses ICMP
>stamps to determine the time skew. It has millisecond resolution.
Or use msntp in its unprivileged (default) mode to any NTP server.
Anonymous FTP from oozelum.csi.cam.ac.uk in dist/msntp-1.4.tar.gz.
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: jra@scfn.thpl.lib.fl.us (Jay R. Ashworth) [-/+]
Date: 16 Nov 1997 01:05:15 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Inexpensive GPS clock for NTP? [-/+]
X-Keywords: FAQ [-/+] Mills [-/+] synchronized [-/+] WWVB [-/+]
On 10 Nov 1997 09:40:25 GMT,
Ulrich Windl <wiu09524@rrzc4> wrote:
> In article <01bced86$d52c92c0$76e1d2cc@GerardM.Foley.columbus.rr.com> "Gerard M. Foley" <gfoley@netexp.net> writes:
> > Are the radio-corrected clocks advertised by Radio Shack at under
> > $50, which use WWVB signals, any use in your application? What is
> > NTP?
>
> "What is NTP?" is possible the thing that's missing in the
> FAQ. Someone out there with a good 5 sentence summary?
When networking computers, keeping their clocks synchronized is
important for many reasons, including security tracking and system
maintenance. When using computers for scientific applications,
synchronizing them to "absolute time" becomes as important. NTP is the
name of a network protocol and software suite developed by Dr. David
Mills at the University of Delaware, with help from dozens of other
people on the net, which makes both of these tasks possible, although
not always simple. As with database design, time synchronization
system design can be more complicated than it looks, depending on what
you want to do. Far more information than you need (:-) can be found
at the NTP Home Page: http://www.eecis.udel.edu/~ntp/ -- read the whole
page; the descriptive entries are _after_ the releases.
That good enough? (Ok; I cheated with the semicolon, there...)
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby,
Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592
From: bob@hobbes.dtcc.edu (Bob Rahe) [-/+]
Date: 18 Nov 1997 15:39:54 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Discrepancy Program [-/+]
In article <64pt5v$27k7$1@emngw1.eastman.com>,
Michael H. Spence <mspence@eastman.com> wrote:
>I am looking for any example programs that can be used to measure the time
>discrepancy between systems. I am trying to put together a graph of range
>of time discrepancies that exist between systems on our corporate LAN. My
>thought is that I would select a single system as a point of reference and
>measure the difference between its internal clock and other systems out on
>the network.
I have a copy of the clockdiff program around here somewhere that uses the
ICMP timestamp packets to compare the differences in time between hosts.
It claims to have come from various BSD code. I can send you a copy
if you can't find it...
Bob
--
----------------------------------------------------------------------------
|Bob Rahe, Delaware Tech&Comm Coll. / |
|Computer Center, Dover, Delaware / |
|Internet: bob@hobbes.dtcc.edu / |
----------------------------------------------------------------------------
From: "Michael H. Spence" <mspence@eastman.com>
Date: Mon, 17 Nov 1997 12:00:06 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Time Discrepancy Program [-/+]
I am looking for any example programs that can be used to measure the time
discrepancy between systems. I am trying to put together a graph of range
of time discrepancies that exist between systems on our corporate LAN. My
thought is that I would select a single system as a point of reference and
measure the difference between its internal clock and other systems out on
the network.
Thanks in advance...
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 19 Nov 1997 08:22:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp conf file example sought
X-Keywords: FAQ [-/+] FreeBSD [-/+] release [-/+]
In article <34706D42.7DFCA598@dnai.com> Michael Sierchio <kudzu@dnai.com> writes:
> Apologies, I'm sure this is a FAQ, but I couldn't locate
> a FAQ for this group.
I have a pre-release of a new FAQ in HTML available at
pcphy4.physik.uni-regensburg.de in pub/wiu09524/NTP-FAQ-2C.tar.gz (a
bunch of HTML files). Oh, well, use the FTP protocol!
For the experts around: To build an index I'm seeking for two word
lists: One with words that are "very interesting and significant (like
`stratum')", and the other with words that are not interesting (like
"problem", "ntp", ...).
I'll try to collect any EMail responses...
>
> I am looking for examples of conf files so that I may
> use my FreeBSD box as a server for local hosts, and get
> its time corrected by a server on my ISP.
>
> Thanks,
Ulrich
From: helm@fionn.es.net (Michael Helm)
Date: 21 Nov 1997 18:35:18 GMT [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: delay [-/+] multicastclient release [-/+] resolver
[See the referenced article in its entirety in comp.unix.solaris]
In article <fi27ma3xcfw.fsf@bugmotel.i-have-a-misconfigured-system-so-shoot-me>,
Jan Brittenson <bson@eng.sun.com> wrote:
>I should point out that we did make some changes you need to be aware
>of if you install the SUNWntp* packages; this list is off the top of
>my head:
>
> - ntpdate can listen for servers as a multicastclient (-m)
> - ntpdate can wait until it manages to synchronize (-w)
ntpdate has some problems & it would be a good thing if some
other things were done to a commercialized release. Here's one
that's gotten me:
If you do the usual startup for xntpd on bootup
ntpdate
wait
xntpd
you can get your system to hang under some circumstances --
ntpdate waiting on broken / disconnected dns to resolve,
waiting for too many samples, too long an initial time out &c.
DNS is a bad one, as the timeouts there are very long. ntpdate
has command line parameters to shorten the sampling & delay
time of its requests ... but not resolver requests. I'm not
sure how your changes above may affect ntpdate's ability
to deal with delay robustly.
This may not seem like a big problem -- it's not, for a single
system on an otherwise busy LAN -- but for a system booting off (I mean
OFF, away, standalone!) the net, or the first few hosts coming up
after a power outage, it can lead to ... nothing happening ...
or help cause other deadlocks among interrelated servers.
It would be good for ntpdate to have a global delay limit (finish
in n sec or die). A host that's had a history of running xntpd
can live without it.
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 24 Nov 1997 01:14:58 GMT [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: Arbiter [-/+] reset [-/+]
[ comp.protocols.time.ntp added to Newsgroups: ]
In article
<fi27ma3xcfw.fsf@bugmotel.i-have-a-misconfigured-system-so-shoot-me>
Jan Brittenson <bson@eng.sun.com> writes:
>At least I don't trust an xntpd that hasn't been running without
>problems for at least 3-4 months and that I haven't spent a fair
>amount of effort trying to break.
Um, well, I believe 3.4y was released about two *years* ago... The
particular clock support I'd want (Arbiter) was added in June -96 and
included, if not earlier, in version 3-5.86 released in September -96.
But I can agree that in the past (like in the timeframe of 3.4y:-), the
development of xntp was a bit, er... "enthusiastic":-), and that there
has been some serious problems with some of the more recent versions too.
>Of course there will always be a group of people that want the latest
>rev; even if we shipped the latest rev you'd probably still want to
>build it from source. That's cool; just go ahead and do it. If it
>doesn't work, you'll have our build to fall back on, or at least
>regression test against.
Unfortunately the current version (3-5.91) seems to be extremely
unstable when built and run on Solaris 2.6, as my /var/adm/messages
testifies:
Nov 23 19:16:11 ballantines xntpd[5252]: time reset (step) 0.218258 s
Nov 23 19:43:32 ballantines xntpd[5252]: time reset (step) 0.178989 s
Nov 23 20:16:59 ballantines xntpd[5252]: time reset (step) 0.208115 s
Nov 23 20:47:33 ballantines xntpd[5252]: time reset (step) 0.221552 s
Nov 23 21:12:27 ballantines xntpd[5252]: time reset (step) 0.196856 s
- this just goes on and on, and xntpd reports a huge -389.284 in
ntp.drift. This on a sun4c host that was perfectly stable, with a drift
value of 61.934, with the same xntp version built and run on Solaris
2.5.1.
It appears that this is mostly due to the kernel level NTP "support" in
2.6 - the 3-5.91 version built on Solaris 2.5.1 (where it didn't find
sys/timex.h, ntp_gettime(), and ntp_adjtime()) runs reasonably well on
2.6, and the shipped 3.4y - that also doesn't use the kernel "support"
according to 'truss'! - perhaps somewhat better. Neither of them is as
stable as 3-5.91 on Solaris 2.5.1, though.
--Per Hedeland
per@erix.ericsson.se
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 24 Nov 1997 14:55:20 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How NTP really works
X-Keywords: dispersion [-/+] RFC [-/+]
wiu09524@rrzc4 (Ulrich Windl) writes:
>In article <3474D8C7.1E99@pacbell.com> jwmorr1@pacbell.com writes:
>> Does it just pick a stratum 1 and use that time all the time???
>Wouldn't that be stupid? These question could also be answered by
>reading the RFC (description of the NTP protocol)...
>>
>> Help!!!
>Yes!!! (you could omit the exclamation marks)
Now Ulrich, be nice... (Ulrich can be a bit stuffy sometimes... ;->)
In answer to your question... (The complete answer _is_ in the RFCs,
available from the Web at <http://www.eecis.udel.edu/~ntp/>. It's
more complicated than I have time for right now... The short answer
is...) Yes, there is a smart merging algorithm that takes into account
the measured dispersion of the various available time sources. It's a
very interesting algorithm from a theoretical point of view - it's
much more than just a weighted average. How well it works, in actual
practice, is an interesting question.
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 24 Nov 1997 14:32:48 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Remote system time adjustments??
X-Keywords: dial [-/+] synchronized [-/+] update [-/+]
Art,
Do the arithmetic... A cheap GPS that can be connected to a serial
port will run you between US$200 and $500. If you can live with
accuracy of a few tens of milliseconds or so (far better than you'd
get out of an occasional ntpdate via ppp) you will be looking on the
cheaper end of the scale. (Not that the internal timers in the cheap
ones are any less accurate - just that the engineers spent less effort
on accurately communicating their internal time to the outside world.)
Phone calls from the US to Nigeria (or wherever - you said "3rd
world".) will run you $3/minute or so. At one call/week you will
spend up $200 in 67 weeks, or about 1.2 years. If the expected life
of these boxes is more than 2 years, a GPS is the way to go. As far
as support is concerned, "what support?". Seriously, you'll probably
have to write a driver for the particular GPS you choose (less than a
week's work - I'd guess), but after that there's nothing to it.
Physically, the GPS will be more robust than the computer - by quite a
bit.
Enjoy!
Rick
PS - BTW - Just what application do you have in mind? Your
description is tantalizing.
Art Hurst <ae799@lafn.org> writes:
>We have our local systems synchronized via ntp to internet time
>sources. We also have remote sites that run ntp in the local mode which
>only sync to themselves. I can dial in w/PPP to a remote station and use
>ntpdate against one of our local systems, but I am searcing for a method
>to allow the remote station to home in on a relatively stable clock
>based on an occasional dial-up and ntpdate. I haven't found this issue
>discussed on the HOW-TOs of FAQs. Can anyone point me to a discussion of
>this approach?? Will the drift value update and eventually home in on a
>value based upon occasional ntpdates?? I don't expect the same accuracy
>as local systems, but could accept ~ 1 min/6 mo drift. I've ruled out
>auto dial-out to a time server since most of these remotes may be in
>other countries and quite likely 3rd world sites. Also I don't want to
>add on additional hardware for radio clock reception since support and
>cost would likely rule out their acceptance by management. We must
>occasionally dial in to the sites for software support and updates so I
>would like to find a method that could be coupled in with these calls.
>This would also give us confidence that the clocks were not
>inadvertantly misset.
>--
>Art Hurst email ae799@lafn.org
>pier to pier protocols only work between docking stations ;-)
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Tue, 25 Nov 1997 00:01:53 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd: " Previous time adjustment incomplete..." [-/+]
X-Keywords: adjustment [-/+]
In <3479F3B9.1590@linkexchange.com> David Lowe <david@linkexchange.com> writes:
> Scanning the newsgroup shows me that "synchronization lost" is nothing
> to worry about, but I haven't seen any references to the "Previous time
> adjustment incomplete" log message. Can anyone explain that one to me?
xntpd asks your kernel to slew the time for a certain period, as a way to
adjust the time. The adjtime() function being used reports the residual
from the previous call to adjtime(). In general it means xntpd repeatedly
calls adjtime() with too little time in between calls. You can tune this
behaviour by changing the value of maxslew.
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: Jeff/dev/null@Wagsky.com (Jeff Kletsky)
Date: Mon, 24 Nov 1997 19:36:15 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for linux? [-/+]
In article <34799821.2F2F@rocketmail.com>, robertson@rocketmail.com wrote:
[...]
>Will the xntpd software compile and run on linux?
[...]
>I have heard some scattered rumors that the only way to actually
>set the time on a linux box it to do it through the CMOS.
xntpd works like a charm! The Linux kernel (I've been using 2.0.29,
2.0.30, and 2.0.32) even seems to have the pll built right in, so the
kernel's clock keeps good time when it is out of contact with the
servers. Bad oscillators even seem tolerated; my ntp.drift generally
reads about -35...
I'd hit ntpdate for a rough time set in your startup scripts since it will
take a while for the standard ntp algorithm to settle (given the
assumption that Linux is not running 24 hrs/day)
--
Jeff Kletsky
San Francisco, CA
From: vincent@gypsy.cad.gatech.edu (Vincent Fox)
Date: 25 Nov 1997 10:30:52 -0500 [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: delay [-/+] release [-/+]
In <654k97$spa@overload.lbl.gov> helm@fionn.es.net (Michael Helm) writes:
*snip*
>ntpdate has some problems & it would be a good thing if some
>other things were done to a commercialized release. Here's one
>that's gotten me:
>If you do the usual startup for xntpd on bootup
> ntpdate
> wait
> xntpd
*snip*
>This may not seem like a big problem -- it's not, for a single
>system on an otherwise busy LAN -- but for a system booting off (I mean
>OFF, away, standalone!) the net, or the first few hosts coming up
>after a power outage, it can lead to ... nothing happening ...
>or help cause other deadlocks among interrelated servers.
There are solutions.
>It would be good for ntpdate to have a global delay limit (finish
>in n sec or die). A host that's had a history of running xntpd
>can live without it.
What about, before blindly running ntpdate, you stick in
a couple of checks to see if the network is up and if DNS
is resolvable?
Granted, this is not the fix you wanted, but you can do
it yourself and get the exact control you want. Also, you
might run ntpdate with an IP number instead of a host
name to deal with missing DNS servers. Or make sure that
the ntp servers are listed in /etc/hosts, and hostresorder
is "local bind".
--
"Who needs horror movies when we have Microsoft"?
-- Christine Comaford, PC Week, 27/9/95
From: Bud Rogers <budr@twocups.tanet.net>
Date: 25 Nov 1997 16:20:25 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for linux? [-/+]
X-Keywords: documentation [-/+] Slackware [-/+]
Andy Robertson <robertson@rocketmail.com> writes:
> I have looks through the various faqs available for this
> news group and am unable to find anything for Linux.
>
> Will the xntpd software compile and run on linux?
Xntpd 3.5f built out of the box on my Slackware 2.0.27 system. I have
since put it on a pair of Linux servers for our local ISP. The
documentation is very good. Do a bit of reading and you shouldn't
have any trouble.
> I have heard some scattered rumors that the only way to actually
> set the time on a linux box it to do it through the CMOS. Is this
> true?
Man clock. clock -r reads the CMOS clock, clock -w writes to it. Set
your system time with netdate or whatever, then do clock -w and you're
set.
Hope this helps.
--
Bud Rogers <budr@tanet.net>
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 25 Nov 1997 12:11:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP for linux? [-/+]
X-Keywords: bug [-/+] DST [-/+] synchronized [-/+] update [-/+]
In article <34799821.2F2F@rocketmail.com> Andy Robertson <robertson@rocketmail.com> writes:
> I have looks through the various faqs available for this
> news group and am unable to find anything for Linux.
>
> Will the xntpd software compile and run on linux?
Not only does it work, it's even included in most distributions. For
example 5-5.91 will be in S.u.S.E. Linux 5.1 (www.suse.com or
www.suse.de).
>
> If not, what will?
>
> I have heard some scattered rumors that the only way to actually
> set the time on a linux box it to do it through the CMOS. Is this
> true?
That's quite nonsense! If synchronized over the net, it will even
update your CMOS clock periodically. The only exception is a minor bug
in kernels up to 2.0.32 that might not update your CMOS clock, and
some problems when changing to and from DST (but I had heard that
Win95 switched back from 3:00 to 2:00 forever when DST ended ...).
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 25 Nov 1997 12:22:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd: " Previous time adjustment incomplete..." [-/+]
X-Keywords: adjustment [-/+] configuration [-/+] driftfile [-/+] FreeBSD [-/+] loopstats [-/+] precision [-/+] reset [-/+] stability [-/+] synchronized [-/+]
In article <3479F3B9.1590@linkexchange.com> David Lowe <david@linkexchange.com> writes:
> People -
(see below)
>
> I'm trying to set up a fairly simple NTP network using xntpd. It is a
> heterogeneous environment - the server is a FreeBSD 2.2.5 machine,
> running xntpd v3.4e. There are a few FreeBSD clients as well, all
> running 3.4e. They are all working great.
>
> The rest of the machines are BSDI 3.0 machines, running xntpd v3.5f, and
> this is where I'm running into problems. They all have the same
> configuration file:
>
> server ntp.linkexchange.com
You might add more servers for better stability.
> driftfile /etc/ntp.drift
> statsdir /etc/ntp.stats/
> statistics loopstats
>
> I get the following log messages:
>
> Nov 24 13:02:21 www2 xntpd[14936]: xntpd version=3.5f; Fri Jan 17
> 16:19:16 MST 1997 (1)
> Nov 24 13:02:21 www2 xntpd[14936]: tickadj = 25, tick = 10000,
> tvu_maxslew = 2475
> Nov 24 13:02:21 www2 xntpd[14936]: precision = 6 usec
> Nov 24 13:07:11 www2 xntpd[14936]: synchronized to 204.71.191.129,
> stratum=2
> Nov 24 13:07:11 www2 xntpd[14936]: time reset (slew) 529.623406 s
> Nov 24 13:07:11 www2 xntpd[14936]: synchronisation lost
> Nov 24 13:08:27 www2 xntpd[14936]: Previous time adjustment incomplete;
> residual 0.000025 sec
> Nov 24 13:09:15 www2 last message repeated 1 times
>
> Scanning the newsgroup shows me that "synchronization lost" is nothing
> to worry about, but I haven't seen any references to the "Previous time
Wrong: Synchronization lost is a thing to worry about, but not after
restart. In your case the clock seems to drift quite badly.
> adjustment incomplete" log message. Can anyone explain that one to me?
> Really, my biggest concern though is that it doesn't appear to be
> working at all - after watching this for awhile, the clocks still don't
> appear to be any closer together.
Your version was compiled with SLEW_ALWAYS. If you slew 530 seconds at
the reate Linux on i386 does (500us per second), it will take 2000 *
530 seconds (about 160000 seconds, or roughly 5 hours).
>
> Any clues would be much appreciated, thanks,
Either recompile with default values, or use ntpdate to set the time
properly.
>
> David Lowe
Ulrich
From: Dima Volodin <dvv@dvv.ru> [-/+]
Date: Wed, 26 Nov 1997 17:27:21 -0500 [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: Arbiter [-/+] configuration [-/+] PLL [-/+] reset [-/+]
Per Hedeland wrote:
> [ comp.protocols.time.ntp added to Newsgroups: ]
>
> In article
> ?fi27ma3xcfw.fsf@bugmotel.i-have-a-misconfigured-system-so-shoot-me?
> Jan Brittenson ?bson@eng.sun.com? writes:
> ?At least I don't trust an xntpd that hasn't been running without
> ?problems for at least 3-4 months and that I haven't spent a fair
> ?amount of effort trying to break.
>
> Um, well, I believe 3.4y was released about two *years* ago... The
> particular clock support I'd want (Arbiter) was added in June -96 and
> included, if not earlier, in version 3-5.86 released in September -96.
> But I can agree that in the past (like in the timeframe of 3.4y:-), the
> development of xntp was a bit, er... "enthusiastic":-), and that there
> has been some serious problems with some of the more recent versions too.
>
> ?Of course there will always be a group of people that want the latest
> ?rev; even if we shipped the latest rev you'd probably still want to
> ?build it from source. That's cool; just go ahead and do it. If it
> ?doesn't work, you'll have our build to fall back on, or at least
> ?regression test against.
>
> Unfortunately the current version (3-5.91) seems to be extremely
> unstable when built and run on Solaris 2.6, as my /var/adm/messages
> testifies:
>
> Nov 23 19:16:11 ballantines xntpd[5252]: time reset (step) 0.218258 s
> Nov 23 19:43:32 ballantines xntpd[5252]: time reset (step) 0.178989 s
> Nov 23 20:16:59 ballantines xntpd[5252]: time reset (step) 0.208115 s
> Nov 23 20:47:33 ballantines xntpd[5252]: time reset (step) 0.221552 s
> Nov 23 21:12:27 ballantines xntpd[5252]: time reset (step) 0.196856 s
>
> - this just goes on and on, and xntpd reports a huge -389.284 in
> ntp.drift. This on a sun4c host that was perfectly stable, with a drift
> value of 61.934, with the same xntp version built and run on Solaris
> 2.5.1.
>
> It appears that this is mostly due to the kernel level NTP "support" in
> 2.6 - the 3-5.91 version built on Solaris 2.5.1 (where it didn't find
> sys/timex.h, ntp_gettime(), and ntp_adjtime()) runs reasonably well on
> 2.6, and the shipped 3.4y - that also doesn't use the kernel "support"
> according to 'truss'! - perhaps somewhat better. Neither of them is as
> stable as 3-5.91 on Solaris 2.5.1, though.
I had equally bad experience with xntpd in 2.6 until I turned kernel PLL
support off - it looks like 2.6 and xntpd have drastically different ideas
about what it means. After that, the boxes I run xntpd on run rock solid
without any complaints. All these boxes are x86 platforms of very dirrefent
configurations - two of them are your basic PCI pcs with dual IDE and all,
the third one is an EISA/PCI SCSI-equipped combo. One note - I tried to run
xntpd (no kernel PLL support) under 2.6 beta on a box with the hard disk
drive and the CD drive on one IDE controller and IDE driver configuration
was the worst-case one (smallest possible block_factor). And it did look to
me that the system would lose timer interrupts when any disk activity
appeared.
> --Per Hedeland
Dima
From: Toralf Lund <toralf@advim.no>
Date: Mon, 01 Dec 1997 15:11:47 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp on linux
X-Keywords: documentation [-/+] driftfile [-/+] fudge [-/+] peer [-/+] synchronised [-/+] update [-/+]
Five wrote:
> =
> ok, im going round in circles with xntpd and linux (2.0.32).
> I've got 3 servers that need to sync to an external NTP time source, an=
d
> then some more servers which then need to sync to them ('coz they don't=
> directly access the internet).
> I've gone through the docs and set-up the ntp.conf file, and put in wha=
t
> would seem to be some useful information (servers and the like).
> xntpd seems to start, and I can see it go and getting time info from th=
e
> external machines, but it never seems to update the local clock, and it=
> doesn't seem to be listening on port 123 for time queries so I can sync=
> the local machines to it..
> and I don't understand why.
> anyone give some useful help?
> apart from RTFM, we've tried that, and it hasn't helped (obviously we'r=
e
> being a bit thick).
/etc/ntpd.conf file on the servers sync'ed to the external source should
probably look similar to this:
#
# Purpose: Configuration file for NTP (Network Time Protocol) on
# internal servers (i.e. the ones synchronised to the
# external world.)
# Hosts (expected to operate at stratum 2) to synchronise to
server bernina.ethz.ch
server fartein.ifi.uio.no
server ntp1.strath.ac.uk
# Ensure local masters are synchronised to each other
peer your_host1
peer your_host2
peer your_host3
# Use local clock as backup when servers can't be reached (other hosts
# would otherwise be unable to synchronise to this on that event)
server 127.127.1.0
fudge 127.127.1.0 stratum 3
driftfile /etc/ntpd.drift
And on the "slaves":
#
# Purpose: Configuration file for NTP (Network Time Protocol) on
# clients to the _INTERNAL_ NTP servers
server your_host1
server your_host2
server your_host3
driftfile /etc/ntpd.drift
(Substitute the real names of the hosts connected to the Internet for
your_host1, your_host2 and your_host3.)
Apart from that, I would advise you to start 'ntpq -n' and run the two
commands 'pe' and 'as'. The expected output is described in the
documentation. =
-- =
Toralf Lund <toralf@advim.no> \ "Ellers var der intet." \
\ Advanced Imaging AS \ \
\ Billingstad, Norway \ (Bj=F8rnstjerne Bj=F8rnson) =
\
\_Tel +47 66 98 26 55_________\____________________________________\
From: Five <five@infamous.demon.co.uk> [-/+]
Date: Sat, 22 Nov 1997 09:55:58 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: MS-DOS client
X-Keywords: update [-/+]
try at http://www.eecis.udel.edu/~ntp/software.html
they are several client software packages for DOS and various other
platforms.
Keith Dowsett wrote:
> Hi,
>
> does anyone know of an MS-DOS client which can access an NTP server
> either on a local ethernet, or the internet. We have several data
> collection stations running MS-DOS and it would be useful to
> automatically update the clock two or three times per day.
>
> Thanks,
>
> Keith.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 01 Dec 1997 14:19:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Monitoring NTP networks [-/+]
X-Keywords: dispersion [-/+] monitor [-/+] synchronized [-/+] syslog [-/+]
In article <3482B480.41C6@poboxes.com> Simon Brickle <sbrickle@poboxes.com> writes:
> 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.
You can call xntpdc or ntpq periodically to query the status,
e.g. whether the clock is synchronized, what the dispersion is, etc.
You could querey the syslog for abnormal events.
You could process the statistic files with some tools.
(I do all of the above, but mostly manually. I have a simple CGI
script for #1...)
Ulrich