From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 23 Sep 1997 23:34:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How does symmetric active mode operate?
X-Keywords: peer [-/+]
In article <m2afh3bytm.fsf@curnow.demon.co.uk>,
Richard Curnow <richard@curnow.demon.co.uk> wrote:
>
>I've been studying RFC1305 and the source code to xntpd and I'm a bit
>stuck with understanding this.
As I understand it, the main difference between symmetric modes active
and passive is whether the server is processing a transaction started
by itself or by the far end. I.e.:
Machine A is in symmetric active mode and contacts machine B.
Machine B then flips into symmetric passive and responds to A.
So it isn't so much a state of the server as a state of the transaction.
Alternatively, you can regard a 'peer' server as having both active and
passive components, the first of which originates requests and the second
responds to requests.
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: 25 Sep 1997 20:03:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NTP over variable-latency network routes [-/+]
X-Keywords: PLL [-/+]
In article <342AB6E6.74F2@hda.hydro.com>,
Terje Mathisen <Terje.Mathisen@hda.hydro.com> wrote:
>Richard Curnow wrote:
>
>[snipped discussion about ntp PLL vs. regression-based averaging]
>
>> The regression-based averaging envisaged for dial-up systems and the
>> like obviously assumes averaging over periods of the order of days (or
>> at least many hours). Suppose we think instead in terms of an
>> adaptive regression approach, where we can tailor how many old samples
>> are retained in the data-set based on how good the tracking of recent
>> changes is. Then we could have an algorithm which behaves somewhat
>> like the way xntpd varies its loop bandwidth depending on how stable
>> the frequency trend has been. Such a regression algorithm may be
>> suitable both as a functional replacement for xntpd and as a client
>> for dial-up systems; hopefully it could adapt itself automatically to
>> either environment, or failing that it could be parametrised in a
>> suitable way.
>
>I would like to see a system like this, or at least a way to effectively
>let my top-level ntp servers 'coast' along during daytime, when the
>roundtrip delays to our external reference servers are both very
>variable, and quite non-symmetrical.
Yes, I agree. But this would involve scrapping the NTP model, and using
a different one. It is effectively what my code does, though it does
not have any logic for selecting when to take a timestamp based on the
quality of the result. On the other hand, this would be a DISASTER for
any system with a mains clock - but do any still exist?
>My internal clocks would very probably stay closer to 'true' time if
>they didn't try to track what's really bogus steps in the clock updates
>it gets across the (heavily loaded) wire.
My experience is that the majority of problems my code has had are due
to precisely this effect. I have several times to wind down the
consistency checking, because of the erratic nature of the low stratum
servers. And investigations indicate that network problems on the
servers' feeds are usually the cause of the servers wobbling.
The problem is that I don't see any way of reconciling the NTP model with
these requirements - they address different problem domains, and their
constraints are incompatible.
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: 22 Sep 1997 13:53:21 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What does xntpd when summertime goes ? [-/+]
X-Keywords: AIX [-/+] daylight [-/+] synchronised [-/+] timezone [-/+]
In article <605ri2$hjg$2@pheidippides.axion.bt.co.uk>, jcs@zoo.bt.co.ukmapson (John Sager) writes:
|>
|> Erm. Unix systems, of which AIX is an example, carry their system time
|> as UT approximately, and apply timezone and daylight saving (summer) time
|> corrections when time is requested. xntpd just ensures that the system clock
|> is synchronised to UTC within a small error. The summertime correction will
|> happen just as before. Therefore each machine needs to be set up to be
|> in the correct timezone. I don't know how this is done on AIX. Most unices
|> have a zoneinfo directory somewhere that contains appropriate rules that
|> the library routines for local time interpret.
Two minor niggles:
1) CORRECTLY set up Unix systems behave as above, but there are
some around that have been set to use local time. That is usually
the administrator's mistake, and should be corrected in any case.
2) Most Unices that have a zoneinfo directory or similar databases
have INAPPROPRIATE rules! It doesn't help that the UK's rules are
bizarre beyond the power of Unix to support :-(
However, I quite agree with your main points. Resolving the summer
time problem and using NTP should be entirely separate matters, on
any system that is Unix-like. If they aren't, fix that problem first,
and then worry about the two issues separately.
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: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 22 Sep 1997 18:16:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What does xntpd when summertime goes ? [-/+]
X-Keywords: Linux [-/+]
Followup to: <605t8h$er$1@lyra.csx.cam.ac.uk>
By author: nmm1@cus.cam.ac.uk (Nick Maclaren)
In newsgroup: comp.protocols.time.ntp
>
> 1) CORRECTLY set up Unix systems behave as above, but there are
> some around that have been set to use local time. That is usually
> the administrator's mistake, and should be corrected in any case.
>
> 2) Most Unices that have a zoneinfo directory or similar databases
> have INAPPROPRIATE rules! It doesn't help that the UK's rules are
> bizarre beyond the power of Unix to support :-(
>
Well, at least the zoneinfo database can be updated easily (it's
available via FTP...) whereas trying to find a TZ variable setting
won't even get the historical stuff right...
-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
Always looking for a few good BOsFH. ** Linux - the OS of global cooperation
I am Baha'i -- ask me about it or see http://www.bahai.org/
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 22 Sep 1997 21:57:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What does xntpd when summertime goes ? [-/+]
In article <606lmd$875$1@shade.twinsun.com>,
Paul Eggert <eggert@twinsun.com> wrote:
>nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>
>> It doesn't help that the UK's rules are
>> bizarre beyond the power of Unix to support :-(
>
>zoneinfo can handle not only the UK's current rules, but all the UK
>rules back to the introduction of daylight-saving time on May 21, 1916
>at 02:00 GMT (and here it's actually correct to say `GMT' instead of `UTC' :-).
When I last asked one of the UK's experts (a couple of months back), the
current rules apply to the forthcoming change (October 1997), but there
were no defined rules for 1998. The Powers That Be may have actually
taken a decision in the interim, I suppose - this has been known. For
the relevant past, the government has decided the rules a short while
in advance - in 1994, they took the radical step of fixing the rules
for the next 3 years.
I didn't know that zoneinfo handles double changes (i.e. 4 changes in a
year), which the UK has had, but there is no way that it can predict
the future. Which, I am afraid, is the game we are in.
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: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 23 Sep 1997 06:34:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What does xntpd when summertime goes ? [-/+]
X-Keywords: daylight [-/+] DCF77 [-/+] DST [-/+]
Note: While German "Sommerzeit" translates easily to "summertime", the
correct term is "daylight saving time".
I guess you are referring to a cheap DCF77 receiver. DCF77 features
"local time" while UNIX runs UTC. Fortunately DCF77 also broadcasts a
DST flag. If you are using Frank Kardel's parse driver (e.g. RAWDCF)
you will have no problems (because the clock driver converts the time
to UTC, and UTC won't jump).
Have you ever tried ntpq's "cl" command?
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: Tom Lane <tgl@netcom.com> [-/+]
Date: Fri, 26 Sep 1997 05:57:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What's the worst drift you've ever seen? [-/+]
Mike Pelletier <mikep@comshare.com> writes:
> I just got done adjusting my little 486DX4/100 system that I recently
> installed UNIX on, and had to set the tickadj to -t 9993 in order to get
> the drift down to under 100ppm.
> What's the worst clock drift you've ever seen?
I think I have you beat by 100ppm: I have an el cheapo 486/66 box
that needs tickadj 10008 to keep more-or-less-reasonable time.
(I haven't bothered to try to get xntpd going on it... this is
just from long-term wristwatch measurements.)
I doubt my box is anywhere near the worst around, either :-(.
Mass-market PCs are not designed to be sterling timepieces.
regards, tom lane
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 26 Sep 1997 08:05:57 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What's the worst drift you've ever seen? [-/+]
In article <uo9zpp0r509.fsf@netcom5.netcom.com>,
Tom Lane <tgl@netcom.com> wrote:
>I doubt my box is anywhere near the worst around, either :-(.
>Mass-market PCs are not designed to be sterling timepieces.
This used to be an excuse, way back when. But, when it is normal for a
REALLY cheap watch to be below 10 ppm, there is no justification for
drifts of above 100 ppm.
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: 26 Sep 1997 10:34:53 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What's the worst drift you've ever seen? [-/+]
X-Keywords: stability [-/+]
In article <86sous2x97.fsf@athene.nhh.no>, Tom I Helbekkmo <tih@nhh.no> writes:
|> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|>
|> > This used to be an excuse, way back when. But, when it is normal for a
|> > REALLY cheap watch to be below 10 ppm, there is no justification for
|> > drifts of above 100 ppm.
|>
|> I'm on thin ice here, but it seems to me that a wristwatch is kept at
|> a quite carefully controlled temperature, which should help stability
|> quite a bit.
You are definitely on thin ice! Not merely does their temperature
vary far more than you might think, the same applies to the really
cheap alarm clocks. And they have a very similar environment to
most personal computers.
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: Casper.Dik@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 26 Sep 1997 10:40:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Enterprise [-/+]
[[ Reply by email or post, don't do both ]]
hjj@news1.tele.dk (Hans J Jakobsen) writes:
>There is a package SUNWxntp on one of the Solaris 2.5.1 CD-roms.
>It looks as an old version of xntp (version 3.2?).
>Is there a good reason to use this package on an Enterprise 4000?
It's not supported on any platform other than the Starfire (E10000).
>Otherwise I would take a xntpd 3.90.4 compiled on an Ultra-1 and move that to
>the Enterprise 4000.
That should work.
>By the way is there kernel support for external clocks in the ntp that is
>delivered with Solaris 2.6 (both Sparc and x86)?
Don't think so.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 26 Sep 1997 14:00:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Enterprise [-/+]
X-Keywords: Mills [-/+]
In article <60g0n6$4lu@news1.tele.dk> hjj@news1.tele.dk (Hans J Jakobsen) writes:
> By the way is there kernel support for external clocks in the ntp that is
> delivered with Solaris 2.6 (both Sparc and x86)?
Dave Mills was heard to say so...
Ulrich
From: Tom Lane <tgl@netcom.com> [-/+]
Date: Sat, 27 Sep 1997 03:45:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP generates time jumps. Is this normal ? [-/+]
Mats Weber <Mats.Weber@elca-matrix.ch> writes:
> [ xntpd corrected a one-minute error via a clock step ]
> I thought NTP was supposed to never make abrupt jumps like this, or at least
> make sure that the machine will never go through the same time twice.
No. xntpd will correct errors exceeding one second via a clock step.
It figures that one second is so horribly off that it just wants to
get somewhere in the vicinity of the right time before it starts to
apply a real timekeeping algorithm ;-)
You can't realistically expect that a time server will guarantee
*never* to step the clock. If you boot up one day and find your
clock chip has gone nuts and is forty years in the future, do you
want it to be corrected via a step, or do you want system time to
advance at some near-zero rate for the next forty-plus years?
Putting the "ridiculously large error" threshold at one second is
maybe a tad over-the-top, but any reasonable design will have some
threshold at which it decides that a step is the best thing to do.
regards, tom lane
From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]
Date: 17 Sep 1997 20:27:01 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp for nt... nay or yeah ? [-/+]
>Netdate doesn't run as a service, if not mistaken. So the user is going to
>have to have privs. to change the time. Is there any other clients (other
>than Time Service) that run as a service?
My program will run as a service, source and binaries available free from
http://home.att.net/~Tom.Horsley/ntptime.html
(also pointers to other win32 versions).
--
>>==>> 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: Raju Varghese <raju.varghese@ubs.com> [-/+]
Date: Thu, 18 Sep 1997 07:37:30 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp for nt... nay or yeah ? [-/+]
X-Keywords: adjustment [-/+]
Check out my program at http://www.intsoft.com/timesync.html.
It not only runs as a service but also does time adjustment
and NT's (actually, Lan Manager) native time protocol.
Raju
Gregory Goldstein wrote:
>
> Netdate doesn't run as a service, if not mistaken. So the user is going to
> have to have privs. to change the time. Is there any other clients (other
> than Time Service) that run as a service?
From: QDon.PayetteQ@Qunisys.comQ (Don Payette) [-/+]
Date: Fri, 19 Sep 1997 19:27:19 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP server for Netware [-/+]
X-Keywords: Novell [-/+] poll [-/+] SNTP [-/+] stability [-/+] TCP [-/+] timezone [-/+] UDP [-/+] update [-/+]
nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>There is definitely some terminological confusion here! rdate is also
>a Unix facility, that long predates NTP. But let us assume that we are
>talking about a NTP client.
>
Since the subject line of this thread refers to Netware, I feel certain
he is referring to the Netware client RDATE.NLM. This (as far as I can
tell) is not even an NTP client, but a time protocol client (I've included
the readme below). Possibly there is another RDATE for NetWare of which
I'm unaware.
>The NTP design is a fiendishly complex piece of control engineering that
>assumes all participating nodes are running the same algorithm (or one
>functionally equivalent, in a sense I will not define!) In particular,
>it assumes that any system running both as a client and server uses a
>full NTP client-server program, and NOT two separate programs.
>
>A full NTP network is assumed to have lots of loops, which helps to give
>stability, but it is absolutely critical that those loops are pure NTP.
>If you get into a position where you have such a system, but the majority
>of loops have at least one non-NTP node masquerading as NTP client-server,
>all bets are off.
>
>There are lots of other assumptions, but let's ignore them for the moment.
>If your time tree is actually a directed acyclic graph, then you can use
>what is often called SNTP (but which is much older). Frankly, that is a
>much better scenario for the 1990s, but that is another story ....
>
Apparently the problem you refer to only exists if the NetWare box
pretends to be an NTP server without doing the whole protocol. I don't
believe this is happening. It's purely a client getting a time from
a un*x box with the NetWare server disseminating the time with it's own
protocol. Not likely to cause NTP any problems.
>
>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
The ftp site for the following file is ftp.murkworks.com.
Readme.txt file that comes with RDATE.NLM:
This package contains an RDATE NLM for Novell Netware 386 (tm)
+-------------------------------------------------------------------+
|Permission is hereby granted for this archive to be distributed via|
|BBS, Compuserve, Anonymous FTP and any other means so long as no |
|fee is charged for distribution and all components of this archive |
|remain together. |
+-------------------------------------------------------------------+
The RDATE NLM is Copyright (c) 1992,93 MurkWorks, Inc. All Rights Reserved.
RDATE.NLM - 11/23/93
** This is free software **
MurkWorks, Inc has provided this NLM to the Novell user community at no charge.
Purpose:
The RDATE NLM allows the supervisor to synchronize the time
of a Novell NW386 file server with the time of a nearby
Unix host (or any other host which supports the time protocol).
Usage:
load rdate [/c] [/p nn] [/u] [/v nn] [/q] servername ...
Where Means
/c Just check the time and report the difference
Does not set the file server time.
/p nn Continually poll the server every nn minutes
and update the server time accordingly.
The nlm may be unloaded with the UNLOAD
command.
/v nn Don't change the server time unless the
time difference is more than nn seconds.
/m nn Don't change the server time if the time
difference is greater than nn seconds.
(default is 3660 seconds).
/q Don't report when the time has been changed
on the server.
servername The IP name or IP address of the host(s)
running the time server, you may specify
multiple servers.
If the /p option is not used, the NLM unloads itself when it
is done.
Example:
load rdate /p 60 /q /v 1 timeserver1.domain.com timeserver2.domain.com
The RDATE NLM will poll the timeserver once every hour and
update the time if the server is off by more than 1 second.
A message will not appear on the screen when the time has
changed. (this example only) If timeserver1 is unavailable
the NLM will ask timeserver2
NOTE:
You MUST set the timezone on the server BEFORE CLIB.LIB
is loaded:
set timezone EST5EDT
See the System Administration Manual for more
information. If you do not set the timezone, the RDATE NLM
will set your server time incorrectly.
When using the TCP method of obtaining the time (default), the
TCP connection takes a LONG time to timeout if the remote host
is down (more than 15 minutes and still counting) This appears
to be a problem with the TCPIP.NLM, since TCP connections should
timeout quicker than that. If you expect your host(s) to be down
at intervals, use UDP mode instead of TCP mode and specify
multiple servers on the command line. UDP times out in
a few seconds and moves onto the next server in the list to
get the time.
*---------------------- end of manual ----------------------------------*
MurkWorks, Inc. develops and markets TCP/IP related NLMs for Novell Netware
386. You may contact us at
info@MurkWorks.com
MurkWorks, Inc.
PO Box 631
Potsdam, NY 13676-0631
315-265-4717
315-268-9812 Fax
Write or call for the latest product information.
Check out our FTP archive on
ftp.msen.com:pub/vendor/murkworks
QDon.PayetteQ@Qunisys.comQ
I speak only for myself; not my employer
To reply via email, remove the Q's from my address.
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 29 Sep 1997 20:48:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP generates time jumps. Is this normal ? [-/+]
X-Keywords: adjustment [-/+] AIX [-/+] delay [-/+] dispersion [-/+] implementation [-/+] minpoll [-/+] poll [-/+] prefer [-/+] synchronized [-/+] syslog [-/+] WWVB [-/+]
Mats Weber (Mats.Weber@elca-matrix.ch) wrote:
:>after a few minutes (the time needed to get enough samples), the time abruplty
:>jumped back one minute.
:>I thought NTP was supposed to never make abrupt jumps like this, or at least
:>make sure that the machine will never go through the same time twice. I would
:>have expected NTP to slow down the clock until the synchronisation was
:>reached. Am I wrong ? Is the AIX implementation at fault ?
There seems to be quite a bit of speculation and misinformation floating
around on this question....
The daemon "xntpd" is intended to work within a window of plus or minus 128
milliseconds. Within that window it will smoothly adjust the time (known
as "slewing"), which seems to be the behavior you expect. If you are
outside the window, the daemon considers you to be WAY OFF and corrects
with an immediate step of the required size, followed by loss of
synchronization (by definition) and then an attempt to re-synchronize and
settle down inside the normal operating range.
Obviously these kinds of jumps are disturbing, and you don't want them
happening frequently. They are usually associated with startup behavior,
because your battery-backed clock will have drifted while the daemon was
not running and 128ms isn't very far to drift. The accepted solution is
to run "ntpdate" immediately before starting the daemon. "ntpdate" is a
one-shot adjuster that will step your clock into close agreement with your
time sources so that the daemon can be started up and get underway
smoothly.
A more drastic solution is compile the daemon (and the libraries) with the
flag -DSLEWALWAYS. This removes the 128ms window and causes the time to
always be adjusted with the slewing behavior, no matter how far off you
are. The actual slew rate is limited (on my own workstation it is
about 40 milliseconds per second), so it could be a long time before you
achieve anything like the correct time.
This slewing behavior is desired by some users who are allergic to the steps
(usually allergic to backwards) and are willing to accept the increased
variability and slower convergence that go with the slew. This is fine if
your accuracy needs are 500ms, but will not work at all if you need 1ms.
One area where you can get easily exceed the 128ms window is when your
dispersion statistics are poor. If you are having network congestion or
other problems between yourself and your time sources it will show up in
the dispersion statistics. This is reported by ntpq or xntpdc with their
"peers" command. If your dispersion ever exceeds the 128ms window then you
will probably be making some step adjustments. There is nothing wrong with
NTP here, but it is exquisitely sensitive to the arrival time of of
packets. The query programs report this so the sysadmin can be alerted of
external problems that have to be tracked down by a higher power.
--
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
HP NTP Network
--------------
Here is sample output from "ntpq" running on my own cluster server in
Cupertino. NTP had been running for less than 24 hours, and stabilized very
nicely. This machine has ethernet connection all over Cupertino site, and
the routers have some sort of high-speed telephone line connection to other
HP sites. Notice that some of the other machines being polled are 5000km
away, but with offset less than 5 milliseconds and dispersion very low as
well.
ntpq> peers
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 124 64 377 0.00 -0.234 2.01
relay.hp.com listo.hp.com 2 u 875 1024 377 13.84 4.912 4.88
cosl4.cup.hp.co listo.hp.com 2 u 876 1024 377 4.38 -4.468 3.95
paloalto.cns.hp listo.hp.com 2 u 885 1024 377 5.84 0.762 2.18
chelmsford.cns. listo.hp.com 2 u 883 1024 377 89.45 2.160 11.40
atlanta.cns.hp. listo.hp.com 2 u 881 1024 377 63.20 -2.545 0.99
colorado.cns.hp listo.hp.com 2 u 883 1024 377 38.71 -1.110 2.01
boise.cns.hp.co listo.hp.com 2 u 875 1024 377 32.88 -2.015 2.23
suspect NTP Network
---------------
Here is sample output from "ntpq" running on a suspect system. This machine
has X25 connection (19200 baud) to the NTP server, but I'm not sure of the
distance in km. The "delay", "offset" and "disp" numbers are all very high.
I am especially worried about the dispersion.
ntpq> peers
remote refid st t when poll reach delay offset disp
==============================================================================
big_server 10.8.1.7 2 u 3 512 17 312.87 -249.15 1960.85
Now let's go over the meaning of each of the column headings and the
measurements that go with them. Keep in mind that the most important columns
are the last two, "offset" and "dispersion". "dispersion" reveals the
quality of the network service (which the time service depends on very heavily).
remote
------
This is the name of the NTP server. It is usually another UNIX
machine (could be HP, DEC, SUN, anything), but could also be an
external reference clock like HPGPS or WWVB radio clock.
A * in the first column indicates which server has been selected for
synchronization. Only one server is selected at a time; the rest are
held in reserve and their performance is monitored.
refid REFERENCE IDENTIFICATION
-----
Usually the IP address of the server or the name of the external
clock, but can also be a router between the client and server.
Not important for our purposes.
st STRATUM
--
This is a measure of distance to the true source of time. The HPGPS
clock is stratum=0, and HGME13 is considered stratum=2 by all of it's
clients. Not really important for our purposes.
t ??
-
I don't know exactly what this means. Not important for our purposes.
when
----
How long ago (in seconds) was the last query to this server?
Not very important.
poll POLL PERIOD
----
How often (in seconds) are we making a query to this server??
512 seconds (~8 minutes) and 1024 seconds (~17 minutes) are very
popular for network connections, but a machine with an external clock
(like GPS) should poll it every 64 seconds or less.
This number can be specified with the "minpoll" directive, but it is
better to let the daemon adjust it as needed. After stabilizing at
startup this number will move automatically to 1024 for network
servers and 64 for external reference clocks.
reach REACHABILITY larger is better
-----
Notice that my servers all say 377, but the big_server is only 17.
delay ROUND TRIP TIME smaller is better
-----
How long (in milliseconds) did it take for the reply packet to come
back when we sent a query to the server?
offset TIME DIFFERENCE smaller is better
------
How far apart (in milliseconds) are the server's clock and the
client's clock? This is the principal measure that the customer is
interested in. When this number exceeds 128 then NTP makes a big
adjustment (and the message "synchronization lost" appears in the
logfile).
disp DISPERSION smaller is better
----
How repeatable is the "delay" measurement? This is very similar to
the standard deviation of many "delay" measurements in a row. When
this number exceeds 100 (milliseconds) it is very difficult for the
daemon to keep the clock synchronized.
This "dispersion" number is a primary measure of network service
quality. A slow X25 network not only has a sizeable round trip time,
but the round trip time varies a lot from one query to the next.
This is very bad for timekeeping purposes, because it makes the
"offset" very hard to calculate. The real job of NTP is to manage
the "offset" value and minimize it.
=============================================================================
Below is some ntpq data from my own NTP test machine, beginning at daemon
startup and continuing for about 24 hours. The first several examples
are less than 5 minutes between each one. You could gather some
excellent data like this from your system with a cronjob that runs every 5
or 10 minutes that executes this command: ntpq -p >> /tmp/ntpq_data
You can see that the dispersion starts out artificially high and then
quickly drops as real data is accumulated. On the third measurement the
daemon has declared the radio clock to be stable and repeatable enough to
be the selected server, and the * appears next to the WWVP_SPEC name.
This is also when the syslog message "synchronized to 15.13.108.1" appears.
The radio clock is selected because I use the "prefer" directive in
/etc/ntp.conf.
Notice that the "poll" figures adjust automatically, rising from 64 to
1024 seconds for the network time servers. The radio clock "poll" stays at
64 seconds because the cost of polling the dedicated hardware is very low.
ntpq> peers
remote refid st t when poll reach delay offset disp
==============================================================================
WWVB_SPEC(1) .WWVB. 0 l 100 64 3 0.00 7.828 7886.32
relay.hp.com listo.hp.com 2 u 3 64 7 9.77 7.507 3890.03
cosl4.cup.hp.co listo.hp.com 2 u 3 64 7 3.48 16.229 3884.57
paloalto.cns.hp listo.hp.com 2 u 3 64 7 5.08 21.023 3883.29
chelmsford.cns. listo.hp.com 2 u 3 64 7 87.81 20.565 3882.32
atlanta.cns.hp. listo.hp.com 2 u 3 64 7 63.78 19.660 3896.33
colorado.cns.hp listo.hp.com 2 u 3 64 7 41.53 19.945 3882.54
boise.cns.hp.co listo.hp.com 2 u 3 64 7 34.52 12.610 3885.73
remote refid st t when poll reach delay offset disp
==============================================================================
WWVB_SPEC(1) .WWVB. 0 l 109 64 3 0.00 7.828 7886.32
relay.hp.com listo.hp.com 2 u 12 64 7 9.77 7.507 3890.03
cosl4.cup.hp.co listo.hp.com 2 u 12 64 7 3.48 16.229 3884.57
paloalto.cns.hp listo.hp.com 2 u 12 64 7 5.08 21.023 3883.29
chelmsford.cns. listo.hp.com 2 u 12 64 7 87.81 20.565 3882.32
atlanta.cns.hp. listo.hp.com 2 u 12 64 7 63.78 19.660 3896.33
colorado.cns.hp listo.hp.com 2 u 12 64 7 41.53 19.945 3882.54
boise.cns.hp.co listo.hp.com 2 u 12 64 7 34.52 12.610 3885.73
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 65 64 377 0.00 4.115 20.22
relay.hp.com listo.hp.com 2 u 32 64 377 12.53 10.927 8.62
cosl4.cup.hp.co listo.hp.com 2 u 32 64 377 3.43 3.377 7.13
paloalto.cns.hp listo.hp.com 2 u 32 64 377 5.34 7.733 7.68
chelmsford.cns. listo.hp.com 2 u 32 64 377 85.97 7.086 13.73
atlanta.cns.hp. listo.hp.com 2 u 32 64 377 63.83 6.719 7.87
colorado.cns.hp listo.hp.com 2 u 32 64 377 41.18 6.390 9.02
boise.cns.hp.co listo.hp.com 2 u 32 64 377 34.53 2.931 15.61
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 114 64 377 0.00 37.623 12.77
relay.hp.com listo.hp.com 2 u 225 512 377 6.93 34.052 10.79
cosl4.cup.hp.co listo.hp.com 2 u 226 512 377 4.18 29.385 13.21
paloalto.cns.hp listo.hp.com 2 u 235 512 377 9.80 33.487 11.61
chelmsford.cns. listo.hp.com 2 u 233 512 377 88.79 30.462 9.66
atlanta.cns.hp. listo.hp.com 2 u 231 512 377 67.44 32.909 12.86
colorado.cns.hp listo.hp.com 2 u 233 512 377 43.70 30.077 18.63
boise.cns.hp.co listo.hp.com 2 u 224 512 377 33.42 31.682 8.54
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 96 64 377 0.00 41.279 4.29
relay.hp.com listo.hp.com 2 u 207 1024 377 38.88 56.319 27.47
cosl4.cup.hp.co listo.hp.com 2 u 208 1024 377 6.36 35.910 13.03
paloalto.cns.hp listo.hp.com 2 u 217 1024 377 5.80 40.161 12.37
chelmsford.cns. listo.hp.com 2 u 215 1024 377 90.36 38.449 12.68
atlanta.cns.hp. listo.hp.com 2 u 213 1024 377 64.09 37.787 11.25
colorado.cns.hp listo.hp.com 2 u 215 1024 377 44.07 38.568 17.72
boise.cns.hp.co listo.hp.com 2 u 206 1024 377 67.37 54.712 26.61
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 87 64 377 0.00 39.299 3.69
relay.hp.com listo.hp.com 2 u 6 1024 377 65.48 67.331 24.52
cosl4.cup.hp.co listo.hp.com 2 u 7 1024 377 4.32 35.311 6.41
paloalto.cns.hp listo.hp.com 2 u 16 1024 377 80.37 1.781 32.01
chelmsford.cns. listo.hp.com 2 u 14 1024 377 88.87 34.785 6.35
atlanta.cns.hp. listo.hp.com 2 u 12 1024 377 63.16 36.973 5.52
colorado.cns.hp listo.hp.com 2 u 14 1024 377 42.08 37.187 8.74
boise.cns.hp.co listo.hp.com 2 u 5 1024 377 36.00 38.077 13.23
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 118 64 377 0.00 29.347 3.07
relay.hp.com listo.hp.com 2 u 869 1024 377 65.48 67.331 24.52
cosl4.cup.hp.co listo.hp.com 2 u 870 1024 377 4.32 35.311 6.41
paloalto.cns.hp listo.hp.com 2 u 879 1024 377 80.37 1.781 32.01
chelmsford.cns. listo.hp.com 2 u 877 1024 377 88.87 34.785 6.35
atlanta.cns.hp. listo.hp.com 2 u 875 1024 377 63.16 36.973 5.52
colorado.cns.hp listo.hp.com 2 u 877 1024 377 42.08 37.187 8.74
boise.cns.hp.co listo.hp.com 2 u 868 1024 377 36.00 38.077 13.23
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 122 64 377 0.00 23.105 2.35
relay.hp.com listo.hp.com 2 u 425 1024 377 7.80 25.924 29.69
cosl4.cup.hp.co listo.hp.com 2 u 426 1024 377 4.96 23.267 10.71
paloalto.cns.hp listo.hp.com 2 u 435 1024 377 8.15 25.546 16.92
chelmsford.cns. listo.hp.com 2 u 433 1024 377 93.98 25.996 8.64
atlanta.cns.hp. listo.hp.com 2 u 431 1024 377 64.48 24.259 11.31
colorado.cns.hp listo.hp.com 2 u 433 1024 377 42.33 24.952 11.75
boise.cns.hp.co listo.hp.com 2 u 424 1024 377 51.56 28.568 12.30
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 109 64 377 0.00 17.206 3.51
relay.hp.com listo.hp.com 2 u 988 1024 377 7.80 25.924 29.69
cosl4.cup.hp.co listo.hp.com 2 u 989 1024 377 4.96 23.267 10.71
paloalto.cns.hp listo.hp.com 2 u 998 1024 377 8.15 25.546 16.92
chelmsford.cns. listo.hp.com 2 u 996 1024 377 93.98 25.996 8.64
atlanta.cns.hp. listo.hp.com 2 u 994 1024 377 64.48 24.259 11.31
colorado.cns.hp listo.hp.com 2 u 996 1024 377 42.33 24.952 11.75
boise.cns.hp.co listo.hp.com 2 u 987 1024 377 51.56 28.568 12.30
THE NEXT DAY
============
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 77 64 377 0.00 -0.428 1.94
relay.hp.com listo.hp.com 2 u 764 1024 377 17.11 -6.332 5.20
cosl4.cup.hp.co listo.hp.com 2 u 765 1024 377 5.08 -4.378 0.49
paloalto.cns.hp listo.hp.com 2 u 774 1024 377 7.80 -2.625 2.29
chelmsford.cns. listo.hp.com 2 u 777 1024 377 91.67 -2.011 5.66
atlanta.cns.hp. listo.hp.com 2 u 775 1024 377 64.39 -2.457 87.01
colorado.cns.hp listo.hp.com 2 u 783 1024 377 43.12 -0.855 3.22
boise.cns.hp.co listo.hp.com 2 u 774 1024 377 42.60 1.471 5.58
THE NEXT DAY
============
remote refid st t when poll reach delay offset disp
==============================================================================
*WWVB_SPEC(1) .WWVB. 0 l 99 64 377 0.00 0.137 1.95
relay.hp.com listo.hp.com 2 u 658 1024 377 16.05 3.133 11.35
cosl4.cup.hp.co listo.hp.com 2 u 659 1024 377 4.10 -4.988 0.72
paloalto.cns.hp listo.hp.com 2 u 668 1024 377 5.87 6.015 0.84
chelmsford.cns. listo.hp.com 2 u 666 1024 377 88.30 1.554 3.52
atlanta.cns.hp. listo.hp.com 2 u 664 1024 377 70.31 -3.034 3.75
colorado.cns.hp listo.hp.com 2 u 666 1024 377 40.82 -1.843 5.81
boise.cns.hp.co listo.hp.com 2 u 657 1024 377 41.24 0.141 9.90
From: shields@crosslink.net (Michael Shields) [-/+]
Date: 30 Sep 1997 19:49:17 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP generates time jumps. Is this normal ? [-/+]
In article <uo9n2kzv2q4.fsf@netcom18.netcom.com>,
Tom Lane <tgl@netcom.com> wrote:
> You can't realistically expect that a time server will guarantee
> *never* to step the clock. If you boot up one day and find your
> clock chip has gone nuts and is forty years in the future, do you
> want it to be corrected via a step, or do you want system time to
> advance at some near-zero rate for the next forty-plus years?
Well, xntpd thinks you would want it corrected by hand. Which is
sensible. Maximum step is 1024 s.
--
Shields, CrossLink.
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 30 Sep 1997 00:01:01 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Fudging localclock driver.
X-Keywords: fudge [-/+] synchronized [-/+]
Casper K. Clausen (ckc@dmi.min.dk) wrote:
:>In the process of setting up an NTP subnet, I have encountered a small
:>problem. We have two Suns which are synchronized by a serial signal
:>chiming every minute, originating from a radioclock. Thus, these two Suns
:>can be expected to have extremely precise local clocks.
:>I have set these up along the lines of
:>server 127.127.1.1
:>fudge 127.127.1.1 stratum 1
:>disable pll
:>Now, what I'd like to know is this: Is the fudging too heavy? Should the
:>radio-disciplined local clocks only be set to stratum two or three? I find
:>the time of these servers to vary a maximum of .08 seconds from outside
:>sources.
I think that 80 milliseconds of inaccuracy is large, and advertising
yourself as a stratum-1 server with that kind of statistic is extremely
misleading. A stratum-1 server should be a lot closer to 80 microseconds.
But your choice of what stratum to advertise yourself as is pretty much
your own. Who will be paying attention? Who are you serving? Who are
your peers?
For a machine with no true source of time, I recommend stratum=10.
The maximum is stratum 16 "unsynchronized", and that is what the local
clock driver reports by default.
--
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: "Doug Hogarth" <DougHo@niceties.com> [-/+]
Date: 30 Sep 1997 22:11:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Follow-up to xntp and WinNT 3.51
X-Keywords: timezone [-/+]
If you have the WinNT Resource Kit, there is a program TZEDIT which will
allow you to edit the MET changeover date information for your WinNT
computer. You might be running an older version or maybe the info didn't
get updated during an upgrade.
Thomas Kernen <tkernen@deckpoint.ch> wrote in article
<342FAEDF.207DD3F9@deckpoint.ch>...
> Updated:
>
> It seems that the problem comes from my timezone on xntpd server, the
> timezone changed -1 hour (MET). I suppose the timezone file is out of
> date. Where can I get a new version? I'm running Digital Unix 3.2c
>
> TIA
> Thomas Kernen
>
From: QDon.PayetteQ@Qunisys.comQ (Don Payette) [-/+]
Date: Tue, 30 Sep 1997 22:24:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What's the worst drift you've ever seen? [-/+]
X-Keywords: adjustment [-/+] NIST [-/+] stability [-/+]
I don't know about un*x, but on DOS/Windows95 machines
the crystal clock (CMOS clock) is only checked at boot time.
After that, the time is kept by counting timer interrupts;
a very unreliable technique.
A TSR called RIGHTIME can be used to condition a PC clock.
On my system, it stays accurate to about a tenth of a
second per week. This is with modem queries to NIST about
once every two weeks.
One of the things RIGHTTIME does is use the stability of the
CMOS clock together with drift adjustment.
Don't know what NT does, though (WRT the CMOS clock).
Bottom line, it's not the computer makers (hardware) but the
software that's falling down.
Matthew.Healy@yale.edu (Matthew D. Healy) wrote:
> . . . I can
>only conclude that a lot of computer makers simply do not care about
>timekeeping accuracy.
>--------
>Matthew.Healy@yale.edu http://ycmi.med.yale.edu/~healy/
>As of 9 Sep 1997, only 843 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 :-(
QDon.PayetteQ@Qunisys.comQ
I speak only for myself; not my employer
To reply via email, remove the Q's from my address.
From: "Marc Brett" <Marc.Brett@waii.com> [-/+]
Date: 1 Oct 1997 10:43:04 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: OMEGA shut down
X-Keywords: precision [-/+] TrueTime [-/+]
I found this announcement of the death of OMEGA over in
sci.geo.satellite-nav. OMEGA was used for precision timing,
so this has implications for NTP and telecoms as well as
navigation.
The clock1.txt document advertises a public stratum 1 server operated
by the CSIRO Marine Laboratories in Hobart, Tasmania Australia
(ntp.ml.csiro.au) which had a TrueTime OM-DC OMEGA receiver.
Presumably, this has been upgraded to GPS, or is now operating at a
higher stratum. [I have no Net access, so cannot check.]
Were there many OMEGA users caught by surprise by this announcement?
----------------- snip ------------------
>Omega Shut down. For those who do not know OMEGA, it is a VLF system
>transmitting at 10.2Khz that originally had 8 stations worldwide to
>provide navigation for aircraft, ships and submarines. The Omega
>signals can be received up to 20 meters below sea surface.Omega has
>long been used as the navigation system in weather balloons.
>Omega: Today the lights go out on the International Omega
>Navigation system based upon the United States Department of
>Transportation's (DOT) assessment that continued funding for the
>system was unjustifiable.
>
>For the World Weather Watch and the data collection of upper air
>winds for weather prediction and modeling this is a sad day,
>particularly in the Southern Hemisphere. Others will be affected
>also.
>
>Comment: The economic and impact analysis of the decision to
>prematurely close the system that cost the United States $5 million
>a year is nowhere to be found suggesting that future termination of
>U.S. terrestrial systems by DOT may go the same way with little or
>no oversight.
>JB 970930
----------------- snip ------------------
--
Marc Brett +44 181 560 3160 Western Atlas
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB England
From: "Phil Biggs" <[phil_biggs@hp.com]>
Date: 9 Oct 1997 09:44:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time sync problems with xntp and WinNT 3.51 & Win95
> >Ulrich Windl wrote:
> >> They say I'll have to patch the registry. Plug-and-Play?
> >>
Get the Time Zone Editor from the Microsoft Kernel Toys. Much easier than
patching the registry
Phil
From: "Fred R. Beck" <beck@denver.sgi.com>
Date: Thu, 09 Oct 1997 18:19:00 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: NTP Master for private n/w [-/+]
I'm trying to get a NTP master set up for a small private
network and am having some problems.
I have written a tool to read a seral port that has a UTC
character string coming in. Periodically, this tool sets the
system clock with the value from the clock source. While this
isn't a very inacurate method, it is the best source that I have.
I would like to make this server believe that he is a suitable
time master so that the ntp clients can sync to his clock. I
care more that the clocks on the network are in lockstep rather
than accuracy to UTC.
Since this is a private network, there are no peers to provide
additional checks.
If someone has done something similar, I'd appreciate getting
a look at the ntp.conf files for the master.
Thanx!
-- fred
========================================================================
Fred R. Beck
Government Systems - Systems Engineer
Silcon Graphics, Inc.
Englewood, Colorado 80111 beck@denver.sgi.com
"As my pappy always said, 'Only fools are sure!'"
========================================================================
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 10 Oct 1997 06:20:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Master for private n/w [-/+]
Try "disable pll" and synchronize xntpd to local clock.
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de.NOSPAM>
From: ckc@dmi.min.dk (Casper K. Clausen)
Date: 10 Oct 1997 10:14:07 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Master for private n/w [-/+]
X-Keywords: auth [-/+] driftfile [-/+] prefer [-/+]
>>>>> "Fred" == Fred R Beck <beck@denver.sgi.com> writes:
Fred> I would like to make this server believe that he is a suitable
Fred> time master so that the ntp clients can sync to his clock. I
Fred> care more that the clocks on the network are in lockstep rather
Fred> than accuracy to UTC.
Depending on what you mean by 'suitable time master', I have done
something very similar (although I only use those servers as
fallbacks, preferring one which synchronizes to outside sources). I've
set up those machines using the LOCALCLOCK reference driver. The
ntp.conf on the machines simply reads:
server 127.127.1.1 prefer
disable pll auth
driftfile /data/ntp/ntp.drift
That's it. This'll have the servers operating at stratum 4.
Regards,
Kvan.
--
-------Casper Kvan Clausen------ | 'Ah, Warmark, everything that passes
----------<ckc@dmi.dk>---------- | unattempted is impossible.'
Lokal 544 |
I do not speak for DMI, just me. | - Lord Mhoram, Son of Variol.
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 9 Oct 1997 18:18:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Using an external time source on HP-UX 10.20 [-/+]
X-Keywords: ACTS [-/+] antenna [-/+] ATOM Bancomm [-/+] broadcast [-/+] CHU [-/+] Datum [-/+] DCF [-/+] DCF77 [-/+] dialup [-/+] HP-UX [-/+] IRIG [-/+] Meinberg [-/+] NIST [-/+] NMEA [-/+] PPS [-/+] Spectracom [-/+] Trimble [-/+] TrueTime [-/+] USNO [-/+] WWVB [-/+]
Rob van der Krogt (rob@nerdnet.nl) wrote:
:>We want to synchronize the time on our servers to the 'real time' as
:>provided by a radio receiver through a serial port. The standard time
:>daemon on HP-UX provides this facility, but I don't know what hardware
:>to buy. Can anybody help me?
If you install the latest patch PHNE_11019 then many different receivers
are possible. Of course we recommend the HP58503 GPS receiver. This and
the Spectracom Netclock/2 (WWVB) are the only ones we officially support
right now, due to testing considerations. But many others should work, and
I have customers happily using "Meinberg DCF U/A 31" and several others
that use the PARSE driver #8.
Besides the ability to work with NTP, cost is usually a major consideration
in buying a radio receiver. They are mostly in the range of US$1k to
US$10k, although installation of the antenna and cabling can add
significantly more. It is also important to get a receiver for a signal
that is available in your area. This is what is so great about GPS, it
works anywhere in the world. You appear to be in Niederlande, so perhaps
the DCF77 signal broadcast by the Deutsche government would be appropriate
for you.
The MSF signal broadcast from London does not work with HP-UX right now.
The WWV family of signals only work in North America and Hawaii.
There are certain clock drivers which are not able to work with HP-UX right
now due to lack of kernel and/or hardware support:
IRIG #6
CHU #7
MX4200 #9
MSFEES #14
HEATH #19
GPSVME #21
ATOM #22
--
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
ACTS - use NIST dialup clock as reference
AS2201 - Austron 2200A or 2201A GPS receiver
DATUM - use Datum Programmable Time System
HEATH - HeathKit GC-1000 Most Accurate Clock
HPGPS - HP 58503A GPS Time & Frequency receiver
LEITCH - Leitch CSD 5300 Master Clock System Driver
LOCAL_CLOCK - use local clock as reference
MOTO - Motorola GPS clock
PARSE - GENERIC refence clock driver
DCF77:
Meinberg DCF U/A 31, PZF 535
Schmid DCF77 receiver
ELV DCF7000
Raw DCF77 signal (100/200ms pulses)
HOPF 6021
GPS:
Meinberg GPS 166
Trimble GPS (TAIP Protocol)
Trimble GPS (TSIP Protocol)
[no kernel support yet]
MSF:
Radio Clock RCC8000 MSF Receiver
PST - PST/Traconex 1020 WWV/H receiver
PTBACTS - use PTB dialup clock as reference
TRAK - TRAK 8810 GPS station clock
TRUETIME - Kinemetrics/TrueTime (generic) receiver
WWVB - Spectracom 8170 or Netclock/2 WWVB receiver
This is a short overview for the reference clocks currently supported
by xntp V3. (Ultimate wisdom can be obtained from xntpd/refclock_*.c
this file was derived from that information - unfortunately some comments
in the files tend to get stale - so use with caution)
Refclock address Type
127.127.0.x no clock (fails to configure)
127.127.1.x local clock - use local clock as reference
127.127.2.x no clock (fails to configure)
127.127.3.x PSTI 1010/1020 WWV Clock
127.127.4.x SPECTRACOM WWVB receiver 8170 and Netclock/2
127.127.5.x Kinimetric Truetime 468-DC GOES receiver
127.127.6.x IRIG audio decode (not on HP-UX)
127.127.7.x CHU Timecode (not on HP-UX)
127.127.8.x PARSE (generic driver for a bunch of DCF/GPS clocks
can be extended for other clocks too)
8.0-3 Meinberg PZF535/TCXO
8.4-7 Meinberg PZF535/OCXO
8.8-11 Meinberg DCF U/A 31
8.12-15 ELV DCF7000
8.16-19 Walter Schmid DCF receiver (Kit)
8.20-23 Conrad DCF77 receiver module + level converter (Kit)
8.24-27 TimeBrick (limited availability ask
time@informatik.uni-erlangen.de)
8.28-31 Meinberg GPS166
8.32-35 Trimble SV6 GPS receiver
127.127.9.x MX4200 GPS receiver (not on HP-UX)
127.127.10.x Austron 2201A GPS Timing Receiver
127.127.11.x Kinemetrics Truetime OM-DC OMEGA Receiver
127.127.12.x KSI/Odetecs TPRO-S IRIG-B / TPRO-SAT GPS
127.127.13.x Leitch: CSD 5300 Master Clock System Driver
127.127.14.x MSFEES (not on HP-UX)
127.127.15.x TrueTime GPS/TM-TMD (aliased to #5)
127.127.16.x Bancomm GPS/IRIG Ticktock
127.127.17.x Datum Programmable Time System
127.127.18.x NIST Modem Time Service (not on HP-UX 9.x)
127.127.19.x Heath WWV Receiver (not on HP-UX)
127.127.20.x NMEA (GPS?) Receiver
127.127.21.x VME GPS Receiver (not on HP-UX)
127.127.22.x PPS Clock Discipline (not on HP-UX)
127.127.23.x PTB Modem Time Service
127.127.24.x USNO Modem Time Service
127.127.25.x aliased to #5 TrueTime
127.127.26.x Hewlett Packard 58503A GPS Receiver