From: jcs@zoo.bt.co.uk (John C Sager) [-/+]
Subject: Re: It's Official: GPS Anti-spoofing Is Now on Continuously
Date: 17 Feb 94 09:48:23 GMT [-/+]
Organization: BT Laboratories, Martlesham, Ipswich, UK
X-Keywords: FAQ [-/+]
In article <Feb.16.18.37.00.1994.4838@athos.rutgers.edu>, rbthomas@athos.rutgers.edu (Rick Thomas) writes:
> > 1. CONDITION: A/S WAS ACTIVATED ON DAY 031 (JAN 31 94) AT 0000 UTC.
> > DUE TO THE 8 DEC 93 DECLARATION OF INITAL OPERATIONAL CAPABILITY
> > (IOC) THE P-CODE WILL NOT NORMALLY BE AVAILABLE TO USERS WHO DO NOT
> > HAVE VALID CRYPTOGRAPHIC KEYS (IAW FEDERAL RADIONAVIGATION PLAN 1992).
>
> Can somebody who knows tell us all what this means to us?
> If I get a good answer, I'll put it in the FAQ.
>
GPS signals carry two sets of codes, the C/A code, with a chip rate of
1.023 MHz, which is the one used by civilians, and also helps the
military receivers to lock on quickly. The other code is the P/Y code,
with a chip rate of 10.23 MHz. This is used by military receivers
and is capable of higher location accuracy. The P code is published,
and was in use hitherto. The Y code is an encrypted version of the
P code, and is now used instead. To use it you need a P-code receiver
with a decrypter, and a source of keys from the DoD (I assume they are
security-conscious enough to change them periodically!). The term
'anti-spoofing' is used because it is now all but impossible for anyone
to create false GPS signals which could fool a military receiver.
This is probably of little consequence to most NTPers, as we all use
C/A code GPS receivers, ie they only use the civilian code. (Anyone want to
own up to using a P/Y code receiver for timekeeping?).
John C Sager Mail: B67 G18, BT Labs
Email: jcs@zoo.bt.co.uk Martlesham Heath
Tel: +44 473 642623 IPSWICH IP5 7RE
Fax: +44 473 637614 England
Disclaimer: This is me, not BT.
============================================================================
From: Unknown Author <none> (auto-inserted) [-/+]
Date: Fri, 4 Mar 94 14:11:13 EST [-/+]
Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu [-/+]
Organization: University of Kentucky, Dept. of Math Sciences
The two entries that mention "-t 9999" on suns could be more clear
that this is only right for the sun4 (i.e., sparc) architecture. The
standard tick value on sun3's is 20,000 so -t 9999 makes it run at
just about half speed (which is so terrible that xntp 3 gives up :-)
============================================================================
From: dupuy@cs.columbia.edu (Alexander Dupuy)
Subject: Re: NTP in demand dialup network
Date: 4 Mar 94 00:25:16 GMT [-/+]
Organization: Columbia University Department of Computer Science
X-Keywords: dial peer [-/+] synchronized [-/+]
I posted a somewhat longish message a month or so ago about running
NTP over demand-dialup IP. You can check the ppp-users archive at
ftp.morningstar.com, or the NTP mailing list archive (is there one?).
The brief summary is that you should use xntpdc, not ntpdate,
synchronized with a few secondaries (if you can teach your demand dial
software not to bring up the link just because there's an NTP packet
which wants to go out). Set up a local clock "peer" at stratum 5 or
6, so that xntpdc will stay synchronized when the link is down. Link
up times of only slightly more than 5 minutes appear to be sufficient
to keep my IPX within 50 msec of our secondaries, once the drift rate
is accurately calculated (this may take a day or two).
============================================================================
From: jcs@zoo.bt.co.uk (John C Sager) [-/+]
Subject: Re: DST switching
Date: 10 Mar 94 09:08:57 GMT [-/+]
Organization: BT Laboratories, Martlesham, Ipswich, UK
X-Keywords: DST [-/+] timezone [-/+]
ks0102@cetrel.lu (KESSELER GEORGES) writes:
> Hi,
>
> how does an unix machine decide when it has to change to DST? As I understand xntp does not provide
> this information to unix as it works in UTC. Is there an algorithm or a table in unix for DST?
As you say, the system clock keeps UTC time (on a correctly configured
system). The kernel & library routines which provide timezone and
DST information refer to one of a set of files in a directory
somewhere. On Sun systems this is /usr/share/lib/zoneinfo, but it may
be elsewhere on other systems, eg /etc/zoneinfo. The method of
selecting the file differs. On BSD-type systems a hard link is made
between the particliar zone info file and a filename 'localtime' in the
zoneinfo directory. On SVR4-type systems, an environment variable, TZ, is
set to the name of the file to be used. The file contains information about
the zone offset from UTC, and the dates of DST changes. Look at the man pages
for zic(8), zdump(8), & tzfile(5) for more info.
============================================================================
From: J.vanOuwerkerk@delftgeot.nl (Hans van Ouwerkerk)
Subject: PC sync solutions needed (Reply) [-/+]
Date: 23 Mar 94 11:52:47 GMT [-/+]
X-Keywords: synchronised
Norman H. Chang from Hewlett-Packard Laboratories asked:
>
> We would like to sync PCs running MS-DOS and Windows3.1 to 0.1 sec
> across LAN/WANs.
> What solutions exist out there?
>
Up to now I saw no answer to this question.
We use LAN Manager, sold to us by Hewlett-Packard :-)
The server runs xntp and when people login to the fileserver for LM
(HP 9000/817) the PC is synchronised with the server. I suppose this
is accurate to 0.1 sec, but of course the clock of the PC will drift
away in the course of the day.
Maybe this can help Norman if he uses LAN Manager.
============================================================================
From: slade@wrc.xerox.com (Mike Slade)
Subject: Re: PC sync solutions needed (Reply) [-/+]
Date: 23 Mar 94 14:36:26 GMT [-/+]
A similar solution exists if you are running PCNFS. As part of the bootup sequence and after PCNFS is started, do an 'rdate' command to your favorite NTP machine. Once again, the pc will drift away from the correct time.
============================================================================
From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) [-/+]
Subject: Re: please answer: slewing the time on a "local clock" master server. [-/+]
Date: 26 Mar 94 10:29:27 GMT [-/+]
Organization: CSD., University of Erlangen
X-Keywords: adjustment [-/+] configuration [-/+] fudge [-/+] resolution [-/+] SLEWALWAYS
duanev@mpd.tandem.com (Duane Voth) writes:
>In article <199403151940.OAA01649@marlins.ctron.com>, hendrick@marlins.ctron.com (James R. Hendrick) writes:
>>
>> Hi,
>> Pardon me if this is a trivial question. I have a machine running
>> xntp that runs a bit fast. Recently, someone "pointed out" that my servers
>> clocks were all 5-10 minutes fast. I have looked and cannot seem to find a way
>> to do the equivalent of: "date -a -600". I tried this first, and it seems
>> that xntp won't let this adjustment occur (maybe it is due to date's use of
>> adjtime??) I am running "tickadj -A -s" on boot time before starting xntp.
The local clock driver uses only the fudge time1 parameter.
This parameter provides read and write access to the local
clock drift compensation register. This value, which actu-
ally provides a fine resolution speed adjustment for the
local clock, is settable but will remain unchanged from any
set value when the clock is free running without external
synchronization. The fudge time1 parameter thus provides a
way to manually adjust the speed of the clock to maintain
reasonable synchronization with, say, a voice time announce-
ment. It is actually more useful to manipulate this value
with the xntpdc(8) program.
Thus you can use the "fudge 127.127.1.x time1 x.xxx" command to change
the speed of your clock to gradually get in sync with reality.
(You must have configured keys and passwords in order to be able to
use remote configuration from xntpdc. If you didn't do that you have
to re-start xntp anyway with a new config file.)
There is another parameter which will set the total offset of the
ntp clock (time2). This will allow to correct for the absolute error.
The comment in the code indicates that this method works best if the
daemon was compiled with SLEWALWAYS.
By looking at the code I got an initial impression that it might even
work without SLEWALWAYS compiles in, but no guarantees here.
So to sum up:
- You must have configured xntpd for remote configuration if
you want to avoid re-starting it.
- xntpdc: fudge 127.127.1.x time1 x.xxx
will modify the drift rate of the local clock and thus allow
you to gradually get in sync with reality (semiautomatic
process - you have to figure out the intrinsic drift of your
system)
- xntpdc: fudge 127.127.1.x time2 x.xxx
will (hopefully) change the system time to match reality.
You still have to figure out the intrinsic drift.
This is not tested and might not do what you and i expect.
- get a real reference clock and forget the problem above
(sorry - but I had to mention that 8-)
Frank Kardel (time@informatik.uni-erlangen.de)
============================================================================
From: kardel@immd4.informatik.uni-erlangen.de (Frank Kardel) [-/+]
Subject: Re: lower stratum host is terminated [-/+]
Date: 25 Mar 94 21:00:41 GMT [-/+]
Organization: CSD., University of Erlangen
X-Keywords: broadcast [-/+] CLOCK_WAYTOOBIG [-/+] configuration [-/+] peer [-/+]
tommy@crd.yokogawa.co.jp (Tomi Masahiko) writes:
>Running xntpd in these environment, strange behaviour was observed.
>Problem was that when offset exceeded approximately 1000 seconds,
>xntpd of host_B (stratum 2) was terminated, and never recovered.
>(Actually this is not confined to broadcast mode, it also occurs
>in both client/server and peer mode.)
>We would like to know
>
> (1)if this matter is specified,
Yes, its the CLOCK_WAYTOOBIG define in include/ntp.h.
> (2)if so, whether it is possible to change the "critical offset value
> (this time 1000s)" and it is unique to hp-ux.
No it is common for all normal xntp configurations on all platforms.
You can change it if you want (you have the source). An error of
more than 1000 secs is very unusual so exiting is a valid option
on such misconfigured systems (initial time zone configuration errors or
wacky hardware clocks or long downtimes).
There is a compile time option to avoid the exiting of the daemon when
the time exceeds CLOCK_WAYTOOBIG.
Define BIGTIMESTEP to keep xntp running even if the local clock is off by
more than CLOCK_WAYTOOBIG seconds.
============================================================================
From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) [-/+]
Subject: Re: NTP client?
Date: 26 Mar 94 09:51:58 GMT [-/+]
Organization: CSD., University of Erlangen
victor@mickey.cc.utexas.edu (V Menayang) writes:
>Frank Kardel <kardel@nessy.informatik.uni-erlangen.de> wrote:
>>
>>Well, then use ntpdate from the xntp distribution and throw the rest
>>away.
>>
>Thanks, to you and others who responded to my query.
>I finally decided to get the whole xntp package and compile
>the ntpdate utility. BTW, perhaps because how I configure
>the compile, I can only query NTP V3 servers. Is this an expected
>behavior of the ntpdate V3?
Yes, unless you specify "-o <version>" on the command line. Version
3 is the default. If you want to query version 2 servers just
do a "ntpdate -o 2 <hosts>".
============================================================================
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: NTP internet survey
Date: 14 Mar 94 15:50:34 GMT [-/+]
Organization: CSD., University of Erlangen
X-Keywords: reachable
Here are the results of the latest NTP network survey.
The NTP synchronisation network was scanned via NTP control messages.
This survey just shows the ntp hosts reachable from the
University of Erlangen in the time frame below.
NTP synchronisation net statistics
==================================
Information reflects the state of the net
as reachable from
University of Erlangen-Nuernberg, Germany.
It is based on information collected
from Thu Mar 3 10:39:22 GMT 1994
to Mon Mar 14 15:15:02 GMT 1994
The most recent NTP host was discovered
Mon Mar 14 15:15:02 GMT 1994
The database reaches back to
Thu Mar 3 10:39:22 GMT 1994
Number of hosts: 6774 OK out of 21148 queried
Strati: S-1: 73, S-2: 1867, S-3: 4834, (higher strati have not been considered)
Versions: v3: 4516, v2: 2258,
Bad hosts:
Timeout on connect: 11565
Protocol error : 9
Hosts at Stratum 1: v3: 64, v2: 9,
Hosts at Stratum 2: v3: 1288, v2: 579,
Hosts at Stratum 3: v3: 3164, v2: 1670,
Analysis per toplevel domains:
Stratum 1 Stratum 2 Stratum 3 Bad Hosts
Domain Total v3 v2 | Total v3 v2 | Total v3 v2 | Timeout Protoco
---------------------------------------------------------------------------------------
ARPA : 0 0 0 | 1 0 1 | 3 2 1 | 0 0
AT : 1 1 0 | 15 15 0 | 3 2 1 | 37 0
AU : 2 2 0 | 43 32 11 | 112 29 83 | 363 0
BE : 0 0 0 | 8 7 1 | 28 28 0 | 6 0
CA : 3 3 0 | 63 40 23 | 229 156 73 | 314 0
CH : 2 1 1 | 123 46 77 | 186 82 104 | 835 1
CL : 0 0 0 | 3 2 1 | 1 1 0 | 2 0
COM : 8 7 1 | 246 187 59 | 292 169 123 | 1402 2
DE : 14 14 0 | 233 142 91 | 738 364 374 | 674 0
DK : 0 0 0 | 8 6 2 | 29 24 5 | 108 0
EDU : 10 6 4 | 433 286 147 | 1902 1399 503 | 3039 0
ES : 0 0 0 | 7 6 1 | 44 44 0 | 8 0
FI : 0 0 0 | 2 2 0 | 15 14 1 | 32 3
FR : 1 1 0 | 15 13 2 | 39 30 9 | 104 0
GB : 0 0 0 | 1 1 0 | 0 0 0 | 0 0
GOV : 9 8 1 | 151 69 82 | 144 117 27 | 512 0
IE : 0 0 0 | 5 5 0 | 7 7 0 | 42 0
IL : 1 1 0 | 1 1 0 | 5 5 0 | 17 0
IS : 0 0 0 | 4 0 4 | 0 0 0 | 0 0
IT : 0 0 0 | 3 2 1 | 12 11 1 | 26 0
JP : 1 1 0 | 37 27 10 | 125 64 61 | 101 0
LU : 0 0 0 | 1 1 0 | 0 0 0 | 2 0
MIL : 0 0 0 | 26 21 5 | 64 48 16 | 215 0
MX : 0 0 0 | 2 2 0 | 3 3 0 | 7 0
MY : 0 0 0 | 2 2 0 | 3 3 0 | 3 0
NET : 7 7 0 | 70 54 16 | 85 81 4 | 96 0
NL : 1 1 0 | 47 40 7 | 120 51 69 | 257 0
NO : 0 0 0 | 9 9 0 | 253 121 132 | 209 0
NZ : 0 0 0 | 3 2 1 | 0 0 0 | 1 0
ORG : 2 0 2 | 16 13 3 | 11 8 3 | 226 0
PL : 0 0 0 | 2 2 0 | 1 1 0 | 4 0
PT : 0 0 0 | 4 4 0 | 5 4 1 | 9 0
SE : 1 1 0 | 22 19 3 | 18 13 5 | 55 0
SI : 0 0 0 | 3 3 0 | 1 1 0 | 4 0
SU : 0 0 0 | 3 2 1 | 0 0 0 | 2 0
UK : 9 9 0 | 223 205 18 | 283 244 39 | 791 2
US : 0 0 0 | 1 1 0 | 0 0 0 | 7 0
ZA : 0 0 0 | 0 0 0 | 1 0 1 | 4 0
[UNRESOLVED] : 1 1 0 | 31 19 12 | 71 38 33 | 2036 1
seahawks : 0 0 0 | 0 0 0 | 1 0 1 | 0 0
---------------------------------------------------------------------------------------
*TOTAL* : 73 64 9 | 1867 1288 579 | 4834 3164 1670 | 11565 9
Following domains only had not responding hosts:
BG, CZ, HR, SG, TH, lepton, pentium, righton.
The "top level domains" seahawks, lepton, pentium an righton are a
result of misconfigured reverse address translation information.
Frank Kardel & Rainer Pruy
============================================================================
From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) [-/+]
Subject: Re: DST switch time
Date: 21 Mar 94 20:01:06 GMT [-/+]
X-Keywords: AIX [-/+] configuration [-/+] DST [-/+] HP-UX [-/+] SCO [-/+] timezone [-/+]
ks0102@cetrel.lu (KESSELER GEORGES) writes:
>Hello,
>I have the following machines syched via ntp: ultrix, AIX, HP-UX, SCO, TandemUX
>The big question is now: will they all switch to DST at the correct time?
Ok, frustrating answer time:
Ask your vendor whether their timezone library works correctly
and how it is configured correctly.
The DST switch is not a matter of NTP. Its a matter of
the timezone code in the library anf its configuration.
This question is the yearly fun part. Which vendors/sysadmins did it
right this year in the current OS version ?
Actually I don't know which OS will do it right in what configuration.
One thing is sure - NTP does not have anything to do with it 8-). NTP
just chews on UTC. The only problem UTC introduces is the leap seconds.
So June 30th will be the time where we all sit and watch the leap
second and what it will do to our receivers an the leap second code in
xntp 8-).
============================================================================
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Subject: Re: please answer: slewing the time on a "local clock" master server. [-/+]
Date: 29 Mar 94 22:25:20 GMT [-/+]
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
X-Keywords: fudge [-/+] VAX [-/+]
In article <2n12q7Elio@uni-erlangen.de> kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) writes:
[ lots of good stuff about how to tweak xntpd to keep better
time when synced only to the local clock ]
>Thus you can use the "fudge 127.127.1.x time1 x.xxx" command to change
>the speed of your clock to gradually get in sync with reality.
Back before we had Internet access, I used this technique with very good
results - of course, to avoid having to do a lot of boring measurements
and calculations, I made a little script 'xntpdadj' to do them for me:
"Xntpdadj will, given an observed deviation from real time, and
knowledge ... about the time elapsed since the last time of agreement
with real time, a) adjust the clock (slowly) to agreement with real
time, and b) set a new time1 value that should keep the clock in better
agreement in the future."
I have put this script along with some info etc up for anon ftp in
euagate.eua.ericsson.se:/pub/unix/networking/xntpdadj.shar - note
however that it was written for, and has only been tested with, V2 xntp
- it should be possible to modify it for V3 though (it *does* need to be
modified).
I also eventually combined this script with a program that dialed up one
of those time-via-modem places to get a good offset from real time, and
ran it from cron every 6 hours, feeding the offset into xntpdadj if it
was > 50 ms - which it actually rarely was after a while (this was with
the clock of a good old VAX 11/750, sitting in a cooled computer room,
though...).
--Per Hedeland
per@erix.ericsson.se or
per%erix.ericsson.se@sunic.sunet.se or
...uunet!erix.ericsson.se!per
============================================================================
From: kardel@nessy.informatik.uni-erlangen.de (Frank Kardel) [-/+]
Subject: Re: lower stratum host is terminated [-/+]
Date: 30 Mar 94 12:09:33 GMT [-/+]
Organization: CSD., University of Erlangen
X-Keywords: CLOCK_WAYTOOBIG [-/+] configuration [-/+]
tommy@crd.yokogawa.co.jp (Tomi Masahiko) writes:
>In such cases that the host whose local clock was without
>battery is booted (which means there is no guarantee that
>offset is under 1000s),
> (1) do we need to adjust the local clock manually?
> (I mean, the only way to avoid the problem mentioned
> before is to insert "ntpdate" in the /etc/rc.local
> start up script?)
This is one solution which might fail if ntpdate doesn't find
any hosts suitable for synchronisation. In that case it will
not correct the clock and the daemon would still give up.
> (2) Otherwise, xntpd has a drive doing it automatically?
> if yes, I would like to know how to configure.
It would if the offset is less than CLOCK_WAYTOOBIG. There is, however,
a compilation option where xntp will not give up on large offsets.
Compile xntpd with -DBIGTIMESTEP and xntp will set the local clock
to whatever time it finds via the NTP protocol. This may or may
not be a good idea to do. Most offsets > CLOCK_WAYTOOBIG stem from
misconfigured time zone information (leading to a wrong utc time
in the kernel although date seems to show the correct time) and
thus should be corrected before xntp is brought into operation.
If you can trust your synchronisation network and the system configuration
the BIGTIMESTEP option can be used to force xntp to set the time to
network time even when the offsets exceeds CLOCK_WAYTOOBIG.
Frank Kardel (time@informatik.uni-erlangen.de)
============================================================================
From: ken@sdd.hp.com (Ken Stone) [-/+]
Subject: Re: when is drift value used
Date: 14 Apr 94 23:03:46 GMT [-/+]
Organization: Hewlett Packard, San Diego Division
X-Keywords: adjtimed [-/+] HP-UX [-/+]
> (1)I'd like to know how and when adjtimed uses "skew" and "drift",
> which are first and second derivative of offset with time
> respectively. This drift value is updated every polling?
It doesn't ... all adjtimed does is talk to code in xntpd and emulate the
BSD adjtime(2) system call.
> (2)The other is about "tick" and "tickadj". I don't understand
> what these variables(tick and tickadj) originally mean.
> I mean how these variables are estimated and how will be used.
> And are these variables only for adjtime()? Not used by "adjtimed"?
tick and tickadj are meaningless (more or less on HP-UX right now.
> (3)It is said drift balue is specific to the computer xntp runs
> on(parameter of the computers oscillator).
> Is there any relation between drift value and these
> variables(tick and tickadj)?
Not on HP-UX ... at least yet anyway :-)
HP-UX 9.03 for the s300's is shipping now and while it does not have xntpd
shipped with it (and probably never will ?) ... it does have the adjtime(2)
system call !! Look for NTP support and adjtime(2) on s700/s800 at 10.0.
-- Ken
============================================================================
From: brett@airgun.wg.waii.com (Marc Brett)
Subject: Re: HELP WITH CONFIG (Your opinions)
Date: 14 Apr 94 11:09:24 GMT [-/+]
Organization: Western Geophysical, Div. of Western Atlas Int'l, Houston, TX
X-Keywords: peer [-/+]
Dave Zarnoch (davez@ibx.com) wrote:
: A. Is my definition of a "peer" correct for the slaves?
Looks OK to me.
: B. In my definition for the clients, will they always
: try to sync with the first server line or will they
: take an average of the two servers and sync to this?
: (I really don't want to overload one slave if they
: will only read the first line only)
Each machine looks at all of the servers and peers in its ntp.conf file
and syncs to the "best" one. As the clocks stabilize, the total
network load decreases, but all the servers and peers are sampled
periodically (about every 1-17 minutes).
: C. If my timeserver goes down or reboots, will the network
: try to "keep up" until the timeserver comes back up?
As you have set it up, if the timeserver goes down, then all the slaves
and clients will be running free on their own clocks. Not good. To
keep them all in sync, the slaves should have a "server 127.127.1.x"
line, where x is greater than the timeserver's level. To avoid
contention, the values of x should be different on the two peered
slaves, say 127.127.1.5 on slv07_A and 127.127.1.6 on slv07_B,
127.127.1.5 on slv09_A and 127.127.1.6 on slv09_B (assuming that the A
slaves have the better clocks). If both A and B slaves are at the same
stratum, then the two slaves' clocks will drift apart and the clients
will "clock hop" between the two.
: D. Are these stratum levels correct?
Free-running time servers probably should be at stratum 10. If the
clients are nested deeply, then this could be raised so that no
client tries to exceed stratum 16.
: E. Is it necessary to add "ntpdate <internet address>" to
: my rc.local file also?
No, but it is a very good idea. Why boot a machine with an inaccurate
clock? All of our Suns have this in rc.local before the calls to
tickadj and xntpd.
if [ -f /usr/local/bin/ntpdate ]; then
/usr/local/bin/ntpdate -b <NTP_servers ...> <NTP_slaves ...>
fi
--
Marc Brett Marc.Brett@london.waii.com
Western Geophysical Tel: +44 81 560 3160
============================================================================
From: ken@sdd.hp.com (Ken Stone) [-/+]
Subject: Re: xntpd on HP
Date: 14 Apr 94 23:06:41 GMT [-/+]
Organization: Hewlett Packard, San Diego Division
X-Keywords: HP-UX [-/+]
>I have gotten xntpd version 3.3q which I plan to implement on an HP700 series
>running HP-UX version 9. Is it true that this version has eliminated the time-
>warping problem? Someone please let me know if this is so. I would also like
>to know where the problem existed and how it was fixed.
I have verified that it is gone at p ... so I would hope that anything after
that is OK also ... the problem was in the handling of adjtime() failing.
Just happens that on most machines, its pretty hard for a simple system
call to fail ... whereas on HP's, adjtime() is anything but a simple system
call :-(
-- Ken
============================================================================
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: Re: ntp for dummies ...
Date: 4 May 1995 18:15:27 GMT [-/+]
Organization: St. Louis Users' Groups
X-Keywords: ACTS adjtimed [-/+] Bancomm [-/+] broadcast [-/+] clockstats configuration [-/+] delay [-/+] DES [-/+] dispersion [-/+] driftfile [-/+] filegen HP-UX [-/+] IERS implementation [-/+] loopstats Mills [-/+] multicast [-/+] NIST [-/+] peer [-/+] peerstats poll precision [-/+] release [-/+] reset [-/+] resolution [-/+] restrict RFC-1305 specification [-/+] stability synchronized [-/+] syslog [-/+] USNO [-/+]
Introduction to Network Time Synchronization with NTP
Richard E. Schmidt
Directorate of Time
U. S. Naval Observatory
3450 Massachusetts Ave,
NW Washington, DC
20392-5420 (202)653-0487 res@tuttle.usno.navy.mil
NTP, the Network Time Protocol [DARPA Network Working Group
Report RFC-1305], is a powerful utility for the synchronization
of system clocks over TCP/IP networks. It can provide a precise
time base for networked workstations and servers.
At the root of an international timekeeping network are
primary NTP time servers, those with atomic clocks, GPS or radio
timing receivers. NTP provides a "software-only" solution for
obtaining timing information from the servers over network
connections, and optionally supports selected timing devices.
The latest source code version with drivers for popular hardware
clocks is also available via anonymous ftp from louie.udel.edu,
in /pub/ntp.
Because packet-switched network paths are largely non-
deterministic, NTP provides the ability to accurately gauge
roundtrip delays and local clock offsets from servers. Clock
synchronization at the 10-millisecond level over long distance
(2000 km) WANs, and at the 1-milllisecond level for LANs, is
routinely achieved.
Why synchronize system times?
In "enterprise computing," "client/server computing", DCE--
or however one describes current computing systems--the isolated
standalone processor is becoming increasingly uncommon.
Simplified networking and the economies of small processors have
spurred the growth of distributed processing systems that share
common databases. Coordinated transaction processing and time-
stamping of instrumental data are but two examples of the need
for agreement about the time-of- day among involved processors.
Use of the "make" facility over NFS mounts is another.
System calls return clock time with microsecond resolution,
but the uncompensated crystal oscillators in HP 9000 SPU's show
typical drifts of 0.1 to 10 seconds per day - about 100 parts per
million. Fortunately, the UNIX system clock can be controlled by
software, and can be synchronized to an external source of time
to a stability of milliseconds per day or better without any
special hardware, and to microseconds per day with add-on
hardware timing sources.
NTP is a system of "architectures, algorithms, entities,
and protocols"[1] for the synchronization of UNIX and non-UNIX
hosts over local and wide area networks and (optionally) over
local buses. Dennis Ferguson, Advanced Network Systems, is the
original author of NTP. David Mills, University of Delaware, is
the author of Network Working Group RFC-1305, the complete
specification of the NTP implementation.
An NTP synchronization subnet consists of a number of hosts
that query time from remote networked time servers (peers), and
that may or may not redistribute time to hosts at lower levels
(strata) in the hierarchy of timekeepers. Typically, the top
stratum (stratum 1, or primary servers) is populated with hosts
with bus or serial interfaces to reliable sources of time, such
as radio clocks, GPS satellite timing receivers, or atomic
clocks. Stratum 2 servers might be company or campus servers
that obtain time from some number of primary servers over
Internet paths, and provide time to many local clients. The
stratum 2 servers may be configured to peer with each other,
comparing clocks and coming to a consensus on a synchronized time
value.
NTP operates well over the non-deterministic path lengths of
packet-switched networks, because it makes robust estimates of
three key variables in the relationship between a client host and
a timeserver: network delay, dispersion of time packet
exchanges, a measure of maximum clock error between the two
hosts, and clock offset, the correction that should be applied
to a client's clock to synchronize it.
The standard NTP distribution includes configuration
support and NTP drivers for a large number of timing receivers,
including GPS satellite receivers, WWV radio timecode receivers,
IRIG-b interfaces, and others that can be compiled into xntpd,
the NTP daemon. There are even drivers for the NIST ACTS and
Naval Observatory modem time services. Included in the standard
distribution are the control and inquiry programs xntpdc and
ntpq, a traceroute-like utility, ntptrace and an rdate-like
utility, ntpdate, useful for resetting the system clock at
bootup.
Controlling the UNIX clock
The generic UNIX system clock consists of an oscillator or
frequency generator and a hardware counter which keeps track of
the number of cycles and fractions of cycles since the clock was
last initialized to some value. Typically overflow of the
hardware counter triggers an interrupt to the system, about 100
times per second, and increments a software clock counter by a
kernel variable called tick, which typically has the value 1/100
second, or 10,000 microseconds. In free-running mode the UNIX
clock increments by one tick every 1/100th second. When
corrections to the clock are to be made, it is desirable to
change time smoothly rather than in jumps, and to avoid jumping
backward in time. A second kernel variable, tickadj, allows one
to run the UNIX clock at two more rates, by incrementing the soft
clock by tick + tickadj microseconds per interval (to speed up
the clock), or tick - tickadj microseconds per interval (to slow
down the clock). A typical value for tickadj is 5
microseconds.
Kernel tweaks to the UNIX clock are made accessible to
privileged users via the adjtime(2) system call. The argument to
the adjtime call is a signed timeval structure of seconds and
microseconds of time to be added to the current system time. The
time correction ë is not instantaneous. It is achieved over an
interval t = ë(tick/tickadj), i.e., taking 2,000 times the size
of the requested correction to be applied by smooth rate
variations. The standard NTP distribution for HP-UX uses an
adjtimed daemon written by Tai Jin of Hewlett-Packard.
Obtaining and compiling NTP
You can obtain a compressed tar file of the latest NTP
release via anonymous ftp from louie.udel.edu in the /pub/ntp
directory. As of April, 1995 xntpd3.4n.tar.Z was the latest
release. The makefile is quite clever in poking around and
determining what release of HP-UX you are running and whether to
include its own adjtime code. The default "make" with no options
builds an NTP suite for a host with no external reference clock.
It will run off the local system clock if operating as a time
server. Root can install the binaries with the "make install"
command.
Configuring NTP
Before running NTP, let's configure a host as a client for a
remote network time server. We are running HP-UX 9.03 on an
HP9000//715 workstation. First we must create a config file
/etc/ntp.conf. Here is a simple example that requests time from
two high-stratum servers at the U. S. Naval Observatory:
#/etc/ntp.conf for a machine in CLIENT MODE
#
#path to a place to record the clock frequency
driftfile /etc/ntp.drift
#
# The server statement causes polling to be done in client mode
# Here are two nearby time sources I can use:
server 192.5.41.40 # tick.usno.navy.mil at USNO
server 192.5.41.41 # tock.usno.navy.mil at USNO
#
# optional restrictions: (uncomment if needed)
# restrict 192.5.41.40
# restrict 192.5.41.41
#here are some optional logging commands (uncomment if needed)
#statsdir /usr/adm/
#statistics loopstats clockstats peerstats
#filegen peerstats file peerstats type day enable
#filegen loopstats file loopstats type day enable
#filegen clockstats file
clockstats type day enable
#End of /etc/ntp.conf
This is a minimal config file which specifies the IP addresses of
two known time servers. The file /pub/ntp/doc/clock.txt on
louie.udel.edu lists high-stratum time servers and their access
restrictions. If you are adding a local hardware clock device,
its driver is identified here by a directive like: server
127.127.XX.0 where 127.127 alerts NTP that this is a local rather
than a remote network peer, and XX is a clocktype described in
the NTP distribution. The restrict directive in this config file
specifies that this host will only talk to the two IP addresses
specified; it won't trust anyone else, and it won't serve time
to anyone else. There are many restriction options documented in
the distribution. For example, this host could be configured as
a time server with the line:
restrict default notrust nomodify which says that it
will server time packets on request but will not sync to other
peers.
The statistics and filegen facility of NTP allows me to log
records of my NTP performance. For example, the records in
/usr/adm/peerstats have the format:
MJD Second Peer IP Stat Offset Delay Dispersion
49815 60424.676 192.5.41.40 9614 -0.000040 0.00169 0.00793
This entry on Modified Julian Date 49815, at 60424.676 seconds
since the beginning of the UT day, shows that compared to the
time server at address 192.5.41.40 my clock was offset by -
0.000040 seconds. The network delay between us was computed as
0.00169 second (its actually only in the next room!), and the
dispersion of a sample of delay estimates was 0.00793 seconds.
The Stat field gives ntp status flags as detailed in the RFC-1305
document. The public NTP release includes utilities in the
scripts/stats directory for summarizing these log files.
Among other configuration options worth exploring are:
broadcast mode, useful for synchronizing LANs with many nodes,
and incorporation of the DES encryption algorithm for
implementing "trusted" associations.
Firing up NTP
Next we create the (empty) file /etc/ntp.drift so that NTP
can keep a record of its clock frequency updates. Now it is time
to start up the external adjtimed daemon (Hewlett-Packard
machines, pre-10.0/9.10 only), and secondly the NTP daemon.
These commands can be put in /etc/rc :
[ HP systems pre 9.10 need this: /usr/local/bin/adjtimed ]
/usr/local/bin/xntpd
You can verify NTP's operation by looking at the records it
records in /usr/adm/syslog:
Apr 8 16:07:46 tuttle xntpd[9892]: xntpd version=3.4n (beta
multicast); Sat Apr 8 16:04:59 UTC 1995 (1)
Apr 8 16:07:46 tuttle xntpd[9892]: tickadj = 5, tick = 10000,
tvu_maxslew = 495
Apr 8 16:07:46 tuttle xntpd[9892]: precision = 23 usec
Apr 8 16:07:46 tuttle xntpd[9892]: system event 1 status c010
Apr 8 16:07:47 tuttle xntpd[9892]: peer 192.5.41.40
event 84 status 9014
Apr 8 16:07:48 tuttle xntpd[9892]: peer 192.5.41.41 event 84
status 9014
Apr 8 16:12:03 tuttle xntpd[9892]: system event 4 status c621
Apr 8 16:12:03 tuttle xntpd[9892]: system event 3 status 634
Apr 8 16:12:03 tuttle xntpd[9892]: system event 4 status 643
Apr 8 17:07:46 tuttle xntpd[9892]: offset -0.000057 freq 11.108 poll 10
The status codes are defined in the RFC-1305 available via ftp.
The offset and polls shown here are not representative of fresh
installs. If your system clock time is very wrong, NTP will not
trust external time sources for the first 15 minutes, during
which you will see a number of lines saying something like:
xntpd[163]: clock correction 100.516493 too large (ignored)
followed after 15 minutes by the entry:
xntpd[163]: clock reset (step) 100.516441
NTP will step initial clock offsets rather than attempt to slew
the clock freqency. You will see messages such as:
reset (step) -11.598845
This too is normal.
How well does NTP work?
An instant report on how well you are synched to your peers
of choice can be obtained with the xntpdc utility included in
the public distribution. The command xntpdc -c peers returns
results as:
remote local st poll reach delay offset
disp
=================================================================
=tock.usno.navy. 192.5.41.43 1 1024 377 0.00172 -0.000155 0.00786
*tick.usno.navy. 192.5.41.43 1 1024 377 0.00194 -0.000123 0.00787
NTP has been running for over a year on a local 802.3 LAN
at the Naval Observatory in Washington, DC. Two HP9000/747i
workstations have Datum/Bancomm bc635vme VMEbus interfaces to an
IRIG-b source of timing from the USNO Master Clock #2 Sigma Tau
hydrogen maser[2]. Following the example drivers for other
hardware devices, an NTP driver for the Bancomm VME card was
written and compiled as an NTP refclock. This application uses a
Bancomm HP- UX kernel driver that fetches time from bus registers
in a few tens of microseconds.
[ Figures not included -Ed. ]
Figure 1 shows a histogram of several months of comparisons
of the UNIX system clock vs. the VMEbus clock, which is kept to
within 125 microseconds of UTC(USNO).
Figure 2 shows the system clock offset of a local HP9000/715
system peering to the two local time servers. Sub-millisecond
synchronization is routinely achieved.
Figure 3 shows an HP9000/425t system located in Miami, FL.
To peer with the Washington servers it links through two 56kb
lines and six or seven intermediate NASA routers. Even though
pings can take up to a few seconds in heavy traffic periods, the
system clock offset has been kept below 10 ms over many months.
Figure 4 shows an experimental NTP time synchronization
between Washington and Miami over 2B+D ISDN. HP ISDN BRI links on
an HP9000/I60 and an HP9000/715 carried the NTP packets
transparently, and millisecond synchronization--comparable to LAN
offsets--is achieved.
References
[1] Mills, D. L., Network Time Protocol (Version 3)
specification, implementation, and analysis. DARPA Network
Working Group Report RFC-1305, University of Delaware, March 1992
[2] Schmidt, R. E. , Network Time Synchronization Servers at
the U.S. Naval Observatory, Proceedings of the 26th Precise Time
and Time Interval Applications and Planning Meeting, Dec. 1994,
in press.
ermkesj@su.ericsson.se (Kent Sjolund) writes:
>I wonder what time is delivered in the GPS signal. I have heard that it is GMT?
GPS delivers a time that is relative to UTC(USNO) better than 340 ns in
90% of all measurements.
>And if so, what is the difference between GMT and UTC?
GMT is a historic term which is today obsolete. It is today called
Universal Time (UT). Universal time is the local time on the zero
meridian which goes through the old observatory in Greenwich, London, UK.
If you are interested in time more precisely than 1 s, then you have to make
a difference between the following versions of universal time:
UT0 is the precise siderial local time on the zero meridian.
UT1 is UT0 corrected by a number of periodic effects (UT0 has different
"speeds" at different times of the year).
UTC is a time defined not by the movement of the earth, but by a collection
of atomic clocks all over the world. When UTC and UT1 drift apart
for more than 0.9 s, then a leap second will be inserted into
UTC to correct this. The next leap second will be 1995-12-31 23:59:60 UTC,
so watch you GPS receiver if it can really handle leap seconds.
The C in UTC stands for "coordinated".
UT2 is an even better corrected version of UT0 which is used in
astronomy.
GMT is a term that has been used before time was defined internationally
by an atomic time reference in the late 1950s. People who talk
today about UTC (e.g. BBC still uses this abbreviation for patriotic
reasons ;-) really mean UT or more precisely UTC.
TIA (fr. temps internationale atomique) is also a clock identical to
UTC with the only exception that TIA has never any leap seconds,
i.e., TIA is now 29 s ahead of UTC and will be 30 s ahead of
UTC next January. TIA and UTC have been identical in the late 1950s,
when atomic time was introduced.
DUT1 is the difference between UTC and UT1 published by USNO rounded to
0.1 s each week. This results in the UT1 which is used e.g. for
space navigation.
If you are interested in UTC more precisely than a microsecond, then
you also have to make the following difference:
The abbreviation UTC can also be followed by an abbreviation of the
organization who published this time reference signal. E.g. UTC(USNO)
is the US reference time published by the US Naval Observatory,
UTC(PTB) is the official German reference time signal published by the
Physikalisch Technische Bundesanstalt in Braunschweig and UTC(BIPM)
is the most official time published by a buero in Paris, however UTC(BIPM)
is only a filtered paper clock published each year that is used by the other
time maintainers to resynchronize their clocks against each other. All
these UTC versions do not differ by more than a few nanoseconds. And there
is of course also UTC(GPS).
Information about the world time standard UTC (e.g. when will the
next leap second be inserted in time, etc.) is available from the
'International Earth Rotation Service' (IERS) with anonymous
ftp from mesiom.obspm.circe.fr. Also <http://www.eecis.udel.edu/~ntp/>
is a good start if you want to learn more about time and the
USNO has also a good time web site, however I don't remember the
URL.
Markus
---
Markus Kuhn, Computer Science student -- University of Erlangen,
Internet Mail: <mskuhn@cip.informatik.uni-erlangen.de> - Germany
WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>