Previous part

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>


Main part