From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 10 Jun 1997 01:39:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Multicasting w/xntpd
X-Keywords: auth [-/+] authentication [-/+] broadcast [-/+] delay [-/+] multicast [-/+] restrict [-/+] trustedkey [-/+]
System Administrator (SIMS) (sulis@sevilleta.unm.edu) wrote:
[asking why multicast didn't connect on sparc-Solaris 2.5]
Howdy,
Since sometime about xntp 3.5f, authentication is on
by default and the client will reject packets that don't
have a proper signature with a trusted key.
Launching with "xntpd -A ..." will disable authentication.
I have a very similar host and OS and I found I needed:
server ntp.conf added lines:
keyfile /usr/local/etc/ntp.keys # chmoded 400
trustedkey 1
enable authentication # default on since 3.5f
and the m-cast line would include a key item
broadcast 224.0.1.1 key 1
The ntp.keys file might look like:
1 M yourkey-
and I suggest using the MD5 format (which is now default in
xntpdc on-line config), but the ntp.keys needs the "M".
Since the key # is sent in the packet, everybody needs the
same key in the same keyid. I got confused when I once had
a 9 character key, so I now only use 8 chars now.
client ntp.conf added lines:
multicast client
trustedkey 1
enable authentication # default on sicne 3.5f
keyfile /usr/local/etc/ntp.keys # could be NFS shared, too
Since the client sends the server an authenticated client'ish
packet to measure multicast roundtrip delay time, the server
seems to need the trustedkey to accept the measurement packet.
The client needs it to accept the response and all the m-cast
packets.
I've tried b-cast with "disable auth" (or "xntpd -A"), and
I think it would allow m-cast to work without ntp.keys, and
trustedkeys, but I worry about letting m-cast from anywhere
control my time without ntp.keys. While the nearby routers
won't accept foreign b-cast in (at least I hope !), as the
mbone grows, I wouldn't be surprised to see alot more m-casts
and I don't want my time to set without my control. I could
also use restrict, but with multicasting with ip spoofing,
things could be weird. I suggest using authentication for
all -casts.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: bentson@grieg.bentson.aa.net (Randolph Bentson)
Date: 11 Jun 1997 15:52:18 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Delorme anticipation [-/+]
X-Keywords: Garmin [-/+] jitter [-/+] monitor [-/+] NMEA [-/+] PPS [-/+] precision [-/+]
In article
<Pine.LNX.3.96.970608043719.11666A-100000@reflections.eng.mindspring.net>,
Todd Graham Lewis <tlewis@mindspring.net> wrote:
>Anyway, my question is, does xntpd support NMEA directly? I am somewhat
>discouraged by the lack of mention of NMEA in the xntpd docs and also by
>the noticeable lack of several fields from the NMEA format, esp. leap
>second indication. Also, NMEA seems to be sort of gratuitous in its
>message generation; the docs abound with sentences such as "anywhere
>between two and eight seconds between messages" and what not.
As others have noted, there is NMEA support but the signal from low
end devices is not likely to satisfy your needs because of the jitter.
I configured my Garmin 38 as a GPS clock source. Since I already
knew that the firmware was not designed to display the time on
the tick, I set the precision to 1/4 second and the stratum to 15.
This allowed me to monitor the clock without letting it influence
my system's clock.
I have found that it reports the time approximately every
1.004 seconds. Because the NMEA code appears to assume time is
reported on the tick, the offset (between this and other clocks)
reports the slide. I've written a script which notes each time
the offset jumps from negative to positive. Over two+ days this
has ocurred nearly 500 times for an average of 470 seconds/cycle.
Unfortunately the cycle interval wanders from 200 to 800 seconds
with little clear pattern.
Pity. I'll have to buy another unit with the PPS signal. At
$180 it's almost worth it.
(I've read one report that the Garmin 12XL, version 2.42 is
better, but it's based on eyeball, not computer measurements.)
--
Randolph Bentson
bentson@grieg.seaslug.org
http://www.ssc.com/ssc/insidelinux
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 12 Jun 1997 11:55:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Solaris, nsec_per_tick and NTP
X-Keywords: bug [-/+] HP-UX [-/+] nsec_per_tick [-/+]
In article <339F66E7.2BD8@abm.com.au> Carl Brewer <carl@abm.com.au> writes:
> G'day again,
>
> As part of working out how to get xntpd 3.5.90 to work on my SPARC
> ELC (Solaris 2.x), I've sent a bugreport to Sun,
> stating that the default value of nsec_per_tick isn't allowing
> ntpd (neither the one that comes with the OS nor 3.5.90) to sync with
> some known working NTP servers. Ulrich, Harlen and
> Bruce Bartram have been very helpful with my tuning efforts, and
> it's now almost right (although the dispersions are still way too
> large, at least now it does synchronise, and if I get some more
> time, I'll play with it more and try and lock down a good value for
> nsec_per_tick)
>
> I received a reply :
> > The issue has been closed as "not a bug". This is because
> > nsec_per_tick
> > is not a kernel tunable, it reflects the number of nanseconds per
> > clock
> > tick. While changing this value may prove a work-around for your NTP
> > problem, it will cause all sorts of timing problems elsewhere - as the
> > evaluating engineer put it, 'Tuning this value would be like "tuning"
> > pi.'
If your clock is really bad _without_ NTP, simply convert your
software problem into a hardware problem! Tell them: "My system clock
is out of order". Preferrably tell them how much error it has.
Maybe tell them that HP-UX uses a very similar internal time-keeping
algorithm, but has clocks with a frequency error below 10ppm. I think
the trick is that they "calibrate" their clocks prior to shipping.
Ulrich
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 12 Jun 1997 19:27:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: bad syslog mesgs.
X-Keywords: adjtimed [-/+] HP-UX [-/+] HPUX [-/+] syslog [-/+]
cahn (cahn@att.solutions.com) wrote:
: Has anyone seen this message in their syslog before?
: Jun 11 15:38:24 nmpws105 xntpd[3879]: Can't adjust time: No such file or
: directory
: On my ntp client workstation (HP-UX 9.04), the above message repeats
: every 2 min. from the time xnptd started up. My npt.conf has in it
: "broadcastclient yes" and I have a startum-2 server up on my network.
: Any reply would be great.
: Charlie Ahn cahn@pdd.att.com
: At&T Solutions (201) 443-2838
Howdy,
This message usually seems to mean that the "adjtimed" required
by HPUX 9 versions isn't running. It might have died or wasn't
started before ntpdate and xntpd in the startup script. This
module comes in the xntpd distribution and "make" does its thing
on those systems.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
(emailed too)
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 16 Jun 1997 02:27:30 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: trying to setup ntp?
X-Keywords: configuration [-/+] controlkey [-/+] dial [-/+] dosynctodr [-/+] driftfile [-/+] fudge [-/+] NIST [-/+] requestkey [-/+] USNO [-/+]
Mike Eggleston (mikee@spindle.net) wrote:
: I'm trying to (unsuccessfully) figure out how to create a
: configuration file such that I have one server as time 'master'
: and all my other servers as time 'slaves'/clients. I don't
: care if the slaves run xntpd or if they run ntpdate
: periodically, but I want them to run *something* that sync's
: the time.
: Eventually I want to sync a host of nt boxes off the time master.
: It would be nice to sync to the internet, but that's icing
: to me. I must get the other servers sync'ing up. I have
: the master box that runs aix4-2 and has xntpd installed on it.
: For the other boxes I have the source and can compile and
: install the source.
: Can anyone give me a configuration that works? I'll supply
: the machine names (generous of me:). I am not sure what
: things to put in and leave out of /etc/ntp.conf.
: TIA
: Mike
Howdy,
I advise to start (and perhaps stay) simple. I'll use name tick
for your master (a CNAME is another nice complication) and
presume that you will manually adjust its clock or by tweaking
(see .../html/driver1.html). To make tick able to receive these
tweaks online, I need to confuse things a bit with
keys. You can ignore the lines with "key" in them at first.
tick's ntp.conf
server 127.127.1.0 # local OS clock taken as a reference
# suggested complication # 1. Show the time as poorer than default
fudge 127.127.1.0 stratum 9 # show poor quality
# suggested complication # 2. ntp.drift can be use to change the
# the clock rate to make this host keep better time. Only
# read on crank up. Written hourly by xntpd if synced to outside
# source.
driftfile /usr/local/etc/ntp.drift # or some such place
# suggested complication # 3. keys to allow online tweaking of
# the clock rate via xtnpdc's fudge command.
keyfile /usr/local/etc/ntp.keys
requestkey 1
controlkey 1
tick's ntp.keys file, NOTE: use an 8 char passwd, chmod 400 ntp.keys
1 m yourpass
Client's ntp.conf
server tick # tick's name or IP#
driftfile /usr/local/etc/ntp.drift
The drift files keep track of the difference of this host's clock
and the server's time information. Each host must have its own
driftfile, but the rest of the files can be NFS shared. ntp.drift
can be ignore, but it will take longer for the client to wake up,
and tick can't be trimmed accross a reboot, so I think you should
have ntp.drift.
While I don't understand the exact details of the WinNT xntpd,
the config file should be very similar except for filenames.
Add a line like
server <outside public stratum 2 server name>
to ntp.conf on tick to get real time it you have a network
connection and restart xntpd. You could get NIST or USNO
time via dial modem with a call per day (or so).
Start with just tick. Learn the tools
xntpdc in general
xntpdc -p to see the quick summary report
ntpq like xntpdc, but another flavor
NOTE: ntpq reports in milliseconds
all the rest are in seconds
ntpdate -d tick send 4 probes and show responses
ntptrace follow the chain of servers
Don't let multiple copies of xntpd run on a single host.
You should make a launching script that gets xntpd going
when the host boots. I'm on sparc-Solaris 2.5 and I'll
email a copy of my overly complicated /etc/init.d/xntp
script. Clients need launchers, too. There are 3 main parts:
tickadj (if needed)
ntpdate <server> (if such server is available)
xntpd -c /usr/local/etc/ntp.conf (actually do it)
In general, you need to disable "dosynctodr" if your
host/OS has this (Sun does, I don't know about others)
using the "tickadj -s" program. I think running
"tickadj" without args (as root) will tell you about
dosynctodr if you have to set it to 0 with the -s.
I also suggest considering using the -A switch to set
the "tickadj" kernel variable to the best guess value.
Running ntpdate <server> in the launcher is good if
there is a trustworthy server (or servers). In your
first step, with tick being the only server, the client's
should ntpdate tick, but tick should have this line
commented out.
I like to put a few second sleep after tickadj and
ntpdate in the launcher to make sure there is time
for the OS to respond to the changes. Look in
.../html/hints/... for specific notes about your
OS. I'm presuming you have a "recent" xntpd like
ftp://ftp.udel.edu/pub/ntp/xntp3-5.90.tar.gz
And you can surf
http://www.eecis.udel.edu/~ntp
for more background.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 17 Jun 1997 19:40:36 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Telecom Solutions [SymmetriComm] and NTP
X-Keywords: ACTS [-/+] Bancomm [-/+] CHU [-/+] Datum [-/+] DCF [-/+] DCF77 [-/+] dialup [-/+] IRIG [-/+] Meinberg [-/+] NIST [-/+] PPS [-/+] rubidium [-/+] Spectracom [-/+] Trimble [-/+] TrueTime [-/+] USNO [-/+] WWVB [-/+]
Roy Nicholl (Roy.Nicholl@ASG.unb.ca) wrote:
:> Does anyone have experience with the Telecom Solutions DCD-LPR
:>System [more specifically with the GTI-15 card, the STE2 rubidium
:>oscillator (5 MHz) and the Time of Day Kit (TOD)]?
:>Their literature claims that the above assembly can provide both PRS
:>and Time-of-day service. From what I can tell, the kit includes an
:>RS-232/422 interface at 9600bd (8N1). The time format is
:>"Year/Month/Day, hour:minute:second" with alarm fields "severity,
:>source, cause". The TPPS is given as <1 microsecond relative to UTC.
:>From a glance over the reference clock drivers, this should work with
:>NTP V3-5.90. I am looking for confirmation that someone is in fact
:>using the GPS solution and any problems, etc. that may have been
:>experienced in interfacing with the workstation chosen to act as the
:>stratum-1.
I don't think this clock will work with NTP. Which clock driver were you
thinking to use? (see list below)
When I talked to the manufacturer of this clock a few months ago they
denied all knowledge of NTP. Their product is a standalone time source,
a competitor to the clock+NTP+unix host that we are familiar with. It is
not just a clock, and it is far more expensive than most clocks.
Nonetheless, it should be possible to write an NTP clock driver to work
with the TOD feature of this beast. I just don't think it has been done
yet.
--
-> 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 (Sun & modified BSD audio driver)
127.127.7.x CHU Timecode (via normal receiver & Bell 103 modem)
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
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
127/127.15.x TrueTime GPS/TM-TMD
127.127.16.x Bancomm GPS/IRIG Ticktock
127.127.17.x Datum Programmable Time System
127.127.18.x NIST Modem Time Service
127.127.19.x Heath WWV Receiver
127.127.22.x PPS Clock Discipline
127.127.23.x PTB Modem Time Service
127.127.24.x USNO Modem Time Service
127.127.26.x Hewlett Packard 58503A GPS Receiver
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 17 Jun 1997 23:36:14 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.hardware
Subject: Re: Strange instability [-/+]
X-Keywords: Arbiter [-/+] FreeBSD [-/+] jitter [-/+] Linux [-/+] PPS [-/+] stability [-/+] synchronized [-/+]
In article <5o2638$2o1$1@palladium.transmeta.com> hpa@transmeta.com
(H. Peter Anvin) writes:
>I am seeing the following instability when running xntpd 3.5-90.1
>(with the stability patch recently posted here) on Linux 2.0.30,
>synchronized to an Arbiter GPS clock:
>
>[deleted]
>
>It appears it gains time until it loses a tick (or is it the other way
>around...), and then the cycle repeats over and over again. This does
>not seem to be the right thing to do. Is Linux 2.0.30 one of the
>kernel versions with a broken PPL, and if so, is there a version which
>is fixed?
I don't know about that, but I was seeing almost exactly the same thing
(rather shorter cycle), with the same clock, on FreeBSD 2.2.1-RELEASE -
here's a sample:
50595 7279.000 0.000092 -182.3694 6
50595 7342.998 0.001483 -182.3638 6
50595 7406.997 0.002803 -182.3531 6
50595 7470.996 0.004037 -182.3377 6
50595 7599.003 -0.003631 -182.3656 6
50595 7663.002 -0.002033 -182.3734 6
50595 7727.000 -0.000504 -182.3753 6
At least on FreeBSD, this appears to be an artifact of the scheduling of
serial input - my knowledge of current Unix kernel internals is rather
vague, but looking at the "sio" driver in FreeBSD, it seems the
interrupt handler normally calls schedsofttty() to inform the upper
layers of a received character, however if it was a "hotchar" it also
calls setsofttty().
Now, the "hotchar" is normally set to the "end of packet" character when
using SLIP or PPP, to "reduce input latency". I diddled the code a bit
to make CR (which is the "on time" character of the Arbiter as used by
xntpd) the "hotchar" otherwise (by default it was unset) - and the
short-term variations were reduced by two orders of magnitude, from +/-
4 ms to +/- 50 us (and became rather random). Perhaps something similar
can be done to the Linux driver, I'm afraid I don't have the source to
that available right now.
(As an aside, I have tried this clock also with SunOS 4 and SunOS 5, and
most of the variation was well below +/- 1 ms, with occasional jitter of
several ms (*many* ms on SunOS 5:-() - nothing like this periodicity.)
>Secondly, the newer Arbiter models have a PPS and programmable pulse
>output; one of which can be channeled to the RS-232 output. xntpd
>doesn't seem to take advantage of that. Would there be a sizable
>benefit to doing so, and if so, how hard would it be to add PPS
>functionality to the existing clock driver?
This was (almost) trivial to use on FreeBSD, due to the TIOCDCDTIMESTAMP
ioctl support present in current versions - xntpd uses this
"automagically" for *all* serial-port-connected clocks. As to the
benefit, the short-term variations went down another order of magnitude
or more, to +/- 2 us or so (and of course the "hotchar" diddling wasn't
needed in this case). Of course my Arbiter model only promises +/- 1 ms
accuracy, so I guess this isn't very useful, but it sure looks nice on a
plot.:-)
In article <5o45e5$h751@hpcc883.corp.hp.com>
dalton@cup.hp.deletethis.com (David Dalton) writes:
>For PPS you will need to build a "gadget box", described in
>.../htmp/gadget.html. It is a very simple bit of electronics, but not
>trivial. It converts the low level PPS signal to acceptable RS232 levels.
Not with the Arbiter you don't, as Peter wrote it can produce a PPS
signal on the RS-232 interface (on the DCD pin even:-) - with RS-232
levels of course, and programmable pulse width. Only problem I had was
that the polarity of the pulse was the opposite of what the FreeBSD code
(and I believe most PPS-handling code) was written for - pretty trivial
to change when you have the source (and notice that the pulse is
inverted:-), but it would be nicer if you didn't have to, of course...
--Per Hedeland
per@erix.ericsson.se
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 18 Jun 1997 17:48:44 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Fudge from system clock.
X-Keywords: configuration [-/+] dial [-/+] firewall [-/+] fudge [-/+]
Edward Strike (strikee@dkbfp.co.uk) wrote:
: Our site is currnetly ruinning Solaris 2.5. Is it possible to use the
: system clock from on of our servers to sync the clients. This would include
: NT servers and 95 clients. Do I have to get a radio clock or go out via the
: internet.
: Thanks
: strikee@dkbfp.co.uk
Howdy,
If you can get through the firewall to the internet or can buy
a radio clock, you will have "good time". This is the best
configuration. Dailing a modem time source, if possible, works
with one or several calls per day. Internet sources will likely
give leap second warnings, and some radio clocks will also.
To use the host OS time as "good time" on the host at the top
of your ntp subnet, add the following lines to its ntp.conf
server 127.127.1.0 # local refclock
fudge 127.127.1.0 stratum 9 # show poor quality
and restart xntpd.
This won't work right if you are trying to b-cast or m-cast
the time.
Since NTP is a time distribution system, you must have some
source of "good time", so you either need the internet, a radio
clock, a dial modem setup, or a local refclock.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
sent by email also
From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]
Date: Wed, 18 Jun 1997 22:05:03 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: TCP port number for NTP
X-Keywords: firewall [-/+] implementation [-/+] UDP [-/+]
Brad Skeel wrote:
>
> Hello:
>
> I have read several FAQs regarding the implementation of NTP and have not
> found any entries regarding the port number NTP uses. I need to know the
> port number NTP uses to communicate. The enviroment I will be
> impplementing NTP in is using a Sidewinder firewall and I will need to give
> that port access in order to sync with an outside time source. I would
> appreciate it someone could let me know.
123/UDP.
Run xntpd on your firewall as an application-level bridge, or
allow through UDP traffic between port 123 on internal machines
and port 123 on external machines, which is just enough to allow
normal sync, though not probing with ntpq/xntpdc.
Damon
From: rstevens@noao.edu (W. Richard Stevens)
Date: 19 Jun 1997 18:34:35 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: NTP and the MBone [-/+]
X-Keywords: configuration [-/+] driftfile [-/+] multicast [-/+] multicastclient restrict [-/+]
I run NTP on my subnet with one "master" server synchronizing with some
"outside" peers, and then redistributing the time using multicasting.
All multicast-capable hosts just have trivial configuration file:
multicastclient 224.0.1.1
driftfile /etc/ntp.drift
Those hosts that are not multicast-capable just have a "server" line
specifying my "master" server. This works fine.
When I bring up my MBone connection (I get charged by usage on my
frame relay Internet connection, so I only turn on mrouted when
necessary) I notice the multicast clients have about a dozen hosts
that they are receiving multicasts from, some from Europe. Watching
the network with tcpdump shows lots of NTP traffic to these sites,
even after I bring my MBone link down. About an hour I after the
link is down I see the reachability go to 0 but there is still NTP
traffic to these sites.
I notice that when my "master" multicasts on the local subnet, the TTL
is 1, as I would expect, so I would guess these other sites have set
the TTL way up in their configuration file.
My feeling is that no site should be sending NTP *multicasts* outside
their "site" ("link-local", "site-local", or "organization-local"
should be the limits for the scope, in IPv6 multicasting-speak, but
never "global"). Is this reasonable? Or should stratum 1 servers
multicast to the world? (I notice only one of these sites is a
stratum 1 server in the list that's going across the MBone today.)
I would guess the only way around this is to add some "restrict" lines
to my multicast client's configuration files, to ignore anyone not on
the local subnet? Or should NTP default to only accept multicasts
from hosts on the local net?
Rich Stevens
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 20 Jun 1997 09:50:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp logging query
X-Keywords: monitor [-/+]
In article <EBzJL1.Io1@gpu.utcc.utoronto.ca> russ@doghaus.uucp (Russell Sutherland) writes:
> I am attempting to log all ntp transactions from other machines which
> have mine configured as a "server". At present my logging only keeps
> track of "peers".
With "enable monitor" and "monlist" in xntpdc you get some
information, but not all...
Ulrich
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 20 Jun 1997 18:57:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: invalid packet header
X-Keywords: authentication [-/+] dispersion [-/+] FAQ [-/+] fudge [-/+] LCL peer [-/+]
Falko Poiker (fpoiker@starvision.com) wrote:
: I have a rather simple setup that doesn't work. At this point I have 3
: workstations that I'm trying to sync up using NTP. Once that works, I
: plan on sync'ing it with the outside world...
: Anyway, I have 1 workstation running as a server and the other two
: running as clients. Everything seems to work fine except for the fact
: that no clock adjustments are taking place. The debug option of xntpd
: indicates that the clients are receiving "invalid packet header"s from
: the server. I've checked the docs and the FAQ, but I can't seem to find
: that particular error anywhere. Has anyone run into this problem
: before?
: Please email me your responses, I don't check this newsgroup all that
: often.
: Thanks!
: Falko Poiker
: fpoiker@starvision.com
Howdy,
Does your master (which I'll call "tick") have a refclock ?
NTP is a time distribution system and it must have a refclock
somewhere. The crude way of using tick's own OS clock as a
reference is to add
server 127.127.1.0 # local refclock fallback
fudge 127.127.1.0 stratum 9 # show poor quality
to tick's ntp.conf, then kill and restart xntpd on tick.
Tick will now answer clients. Try "ntptrace" on tick to
see if tick is at stratum 10 with reference "LCL".
The debug lines tend to require looking at the source code.
To find your report I did
cd xntpd
grep "invalid packet" *.c
to find the error message is from ntp.proto.c. Looking
at the line lead me to .../include/ntp.h section on flash code
#define TEST5 0x10 /* peer authentication failed */
#define TEST6 0x20 /* peer clock unsynchronized */
#define TEST7 0x40 /* peer stratum out of bounds */
#define TEST8 0x80 /* root delay/dispersion bounds check */
so I think you probably got the TEST6 with code 0x20.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
email sent also
From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]
Date: Fri, 20 Jun 1997 12:03:01 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP and the MBone [-/+]
X-Keywords: configuration [-/+] delay [-/+] multicast [-/+] restrict [-/+]
W. Richard Stevens wrote:
>
> I run NTP on my subnet with one "master" server synchronizing with some
> "outside" peers, and then redistributing the time using multicasting.
...
> I notice that when my "master" multicasts on the local subnet, the TTL
> is 1, as I would expect, so I would guess these other sites have set
> the TTL way up in their configuration file.
>
> My feeling is that no site should be sending NTP *multicasts* outside
> their "site" ("link-local", "site-local", or "organization-local"
> should be the limits for the scope, in IPv6 multicasting-speak, but
> never "global"). Is this reasonable? Or should stratum 1 servers
I think that is reasonable...
> multicast to the world? (I notice only one of these sites is a
I think that that would also be reasonable, though possibly with
a hop count of (say) 10 to avoid really distant hosts getting
poor time over long-delay paths...
> stratum 1 server in the list that's going across the MBone today.)
>
> I would guess the only way around this is to add some "restrict" lines
> to my multicast client's configuration files, to ignore anyone not on
> the local subnet? Or should NTP default to only accept multicasts
> from hosts on the local net?
I *always* use restrict to minimise spoofing dangers...
Damon
From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]
Date: Fri, 20 Jun 1997 16:09:16 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Software for Solaris
Antonio J. Diaz Chinea wrote:
>
> Hi,
>
> i'm trying that the xntp read a GPS signal by a serial port on a sun
> machine with Solaris 2.5.1. All references are for SunOS 4.x, I'm
> attempting with the driver 8, but the xntp give somes errors:
> PARSE receiver #0: stream_init: ioctl(fd, I_PUSH, "parse"): Invalid
> argument
Just means you have not built and installed the PARSE driver.
xntpd should work without, though may be less accurate.
Damon
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 24 Jun 1997 10:32:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: more on xntpd delay
X-Keywords: poll [-/+] synchronized [-/+]
In article <01bc8021$d3be2020$ed9392c0@nt-bxh> "bjoern" <bxh@dsc.com> writes:
> I run xntp3-5.90, as a local time server on an NT-machine, and a client on
> Solaris. If I have the daemons running on both sides even for hours, a
> manual change on either clock (5 minutes) will take 5-10 for the client to
> resynchronize.
>
> I thought that should have been done within 64 seconds (I didn't change the
> default polling interval)?
xntp polls reference clocks at 64 seconds minimum (by default) or at a
longer interval. At each poll data is accumulated to build an estimate
of the true time. With 64 seconds this takes typically 5 minutes until
xntpd synchronizes.
NTP does not expect the true time to change other than estimated. If
you set your reference clock manually, xntpd will typically lose
synchronization after about 5 minutes. After another 5 minutes it will
synchronize again, typically stepping time, and thus losing
synchronization again. After still another 5 minutes xntpd will have
synchronized.
>
> Does anybody know why it takes longer than it should?
>
>
> Thanks, Bjoern
>
> bxh@dsc.com
From: Damon at play <dhd@-exnet.com> [-/+]
Date: Mon, 23 Jun 1997 09:34:35 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: signal sources [-/+]
X-Keywords: authentication [-/+]
ZWORF wrote:
>
> Is anyone else out there concerned that they might be running their
> corporate network time services off of an Internet signal?
Slightly.
> I don't have problems with compiling/firewalling/installation or syncing,
> just the idea that our business "might" be susceptible to a signal source
> of dubious origin, aka a time server of stratum 1.
> There's probably some authentication built-in to the signalling mechanism.
> Am I too worried, and should I just forget about it and install and use
I think you are right to worry, though if you take time
from several sources you will reduce the risk of accidental
calamity, and if you use the restriction and authentication
mechanisms you will reduce the chance of deliberate harm
almost out of sight.
Further, you can buy a cheap radio clock as your preferred
source of time. Eg look at my page:
http://www2.exnet.com/NTP/ARC/ARC.html
for a clock for about GBP100 within +/- 10ms of true atomic
time and with full support now included in xntpd 3-5.90.1 B^>
Just have the net sources validate your local source of time,
and you can probably rest quite easily if you have taken the
other steps above.
Regards,
Damon
--
Damon s0dhd@exnet.com, d@hd.org
REMOVE `-' FROM RETURN ADDRESS TO REMOVE ANTI-SPAM FEATURE
http://www2.exnet.com/ http://www.exnet.com/CV/DHDCV.html
Public NTP time server: http://www2.exnet.com/NTP.html
From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 18 Jun 1997 02:41:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.hardware
Subject: Re: Strange instability [-/+]
X-Keywords: antenna [-/+] Arbiter [-/+] FreeBSD [-/+] Linux [-/+] PPS [-/+] precision [-/+] release [-/+]
Followup to: <5o771e$dlc$1@news.du.etx.ericsson.se>
By author: per@erix.ericsson.se (Per Hedeland)
In newsgroup: comp.protocols.time.ntp
> >
> >It appears it gains time until it loses a tick (or is it the other way
> >around...), and then the cycle repeats over and over again. This does
> >not seem to be the right thing to do. Is Linux 2.0.30 one of the
> >kernel versions with a broken PPL, and if so, is there a version which
> >is fixed?
>
Okay, it seems to happen with just about every Linux release. A guess
is that it might have been a problem with the fast Pentium timer;
we'll see...
> >Secondly, the newer Arbiter models have a PPS and programmable pulse
> >output; one of which can be channeled to the RS-232 output. xntpd
> >doesn't seem to take advantage of that. Would there be a sizable
> >benefit to doing so, and if so, how hard would it be to add PPS
> >functionality to the existing clock driver?
>
> This was (almost) trivial to use on FreeBSD, due to the TIOCDCDTIMESTAMP
> ioctl support present in current versions - xntpd uses this
> "automagically" for *all* serial-port-connected clocks. As to the
> benefit, the short-term variations went down another order of magnitude
> or more, to +/- 2 us or so (and of course the "hotchar" diddling wasn't
> needed in this case). Of course my Arbiter model only promises +/- 1 ms
> accuracy, so I guess this isn't very useful, but it sure looks nice on a
> plot.:-)
Okay; I got some patches from Ulrich Windl that implements PPS support
in Linux; the error remains (it loses exacly one tick every 400 or 416
seconds) although the PPS input helped the kernel recover sooner.
> Not with the Arbiter you don't, as Peter wrote it can produce a PPS
> signal on the RS-232 interface (on the DCD pin even:-) - with RS-232
> levels of course, and programmable pulse width. Only problem I had was
> that the polarity of the pulse was the opposite of what the FreeBSD code
> (and I believe most PPS-handling code) was written for - pretty trivial
> to change when you have the source (and notice that the pulse is
> inverted:-), but it would be nicer if you didn't have to, of course...
Actually on the DSR pin, which connects to DCD when you connect it to
the computer via a standard null modem. Overall I have to say the
Arbiter unit is very nice -- for another few hundred US$ you can get
an add-on module with RAIM that increases precision to 1 µs; with
that, the antenna gear and the backup battery it still came to under
US$1,200 which is quite acceptable...
-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: "Greg" <schueman@ix.netcom.com> [-/+]
Date: 21 Jun 1997 04:38:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: WinNT NTP and Time Zone?
X-Keywords: configuration [-/+]
Brian,
Grab the latest version XNTP 3-5.90.1b from ftp.drcoffsite.com and let
me
know whether the problem still exists. The _ftime() function was causing
Day Light Savings time problems, and I wonder whether it might have other
problems related to time zones.
Send email to <access@drcoffsite.com> for access to the site.
The latest NT for Intel binaries are there.
-Greg
Brian L. Bowers <bowers@mtm.syr.lmco.com> wrote in article
<33ABBE7A.469C@mtm.syr.lmco.com>...
> I am having difficulty trying to establish NTP time distribution for a
> system being installed in Singapore, Time Zone (GMT+8:00)Hong Kong,
> Perth, Singapore, Taipei. I am using the WinNT version 3.87 port of
> NTP, and utilizing the Local Clock driver on the WinNT NTP server. When
> the WinNT NTP server PC is set with the Singapore time zone, the time
> being served to the rest of the NTP clients is 15 hours off.
>
> In fact, while recreating the problem here, back on the East coast USA,
> it appears that a server with a time zone outside of the continental US
> causes similar problems. The simple test can be run to see if any one
> else is seeing this problem.
>
> Take two 2 WinNT PCs with the 3.87 WinNT port of NTP installed.
> Set the two PC’s time zones to Eastern Time.
> Start one of the PC daemons with the ntp.conf file containing the
> following line:
> server 127.127.1.0
> wait for the NTP to claim synchronization to Local Clock.
> Go to the second PC and use a Command Prompt window to perform an
> ntpdate to synch from the first PC.
> Things should look fine.
>
> If you set the second PC to use the Time zone to (GMT+8:00)Hong Kong,
> Perth, Singapore, Taipei and do an ntpdate to the first PC, which is
> still EST, things still look fine.
>
> Now try it after setting the Time Zone on the server to (GMT+8:00)Hong
> Kong, Perth, Singapore, Taipei, or even Hawaii. Restart the server
> daemon. Now when you use ntpdate to the first PC it doesn’t work, the
> two PC are not showing the same time, local or GMT.
>
> 1) Does anyone else see this occurrence?
> 2) Is there a configuration parameter that I am missing?
> 3) Why does NTP know anything at all about time zone, or is it just the
> Local Clock driver.
> 4) Why do I get the error “time error -53999.973000 is way too large
> (set clock manually)” if I try to synch a Singapore Time zoned PC to a
> Eastern Time zoned PC?
>
>
> Brian Bowers bowers@mtm.syr.lmco.com
> Lockheed Martin (315) 456 - 1036
> Syracuse NY 13090 (315) 456 - 1207 fax
>
From: edesio@acm.org [-/+]
Date: Wed, 25 Jun 1997 14:12:54 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: TAPR TAC-2 (Totally Accurate Clock) [-/+]
TAPR TAC-2 (Totally Accurate Clock) is now available!
Take a look at http://www.tapr.org/tapr/html/tac2.html
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 23 Jun 1997 23:32:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: signal sources [-/+]
X-Keywords: antenna [-/+] Arbiter [-/+] authentication [-/+] Linux [-/+] PPS [-/+] release [-/+] stability [-/+]
Followup to: <33AE432B.201F@-exnet.com>
By author: Damon at play <dhd@-exnet.com>
In newsgroup: comp.protocols.time.ntp
>
> I think you are right to worry, though if you take time
> from several sources you will reduce the risk of accidental
> calamity, and if you use the restriction and authentication
> mechanisms you will reduce the chance of deliberate harm
> almost out of sight.
>
> Further, you can buy a cheap radio clock as your preferred
> source of time. Eg look at my page:
>
> http://www2.exnet.com/NTP/ARC/ARC.html
>
> for a clock for about GBP100 within +/- 10ms of true atomic
> time and with full support now included in xntpd 3-5.90.1 B^>
>
> Just have the net sources validate your local source of time,
> and you can probably rest quite easily if you have taken the
> other steps above.
>
Be careful with stability; however -- xntp seems to go quite ballistic
when the stability of the source isn't good, even if it stays within a
moderately tight range around the proper value.
A somewhat more pricey clock, but one which we have just gotten
working and which seems to be really good is the Arbiter series of GPS
clocks. The one we have is the 1092A tabletop model with the RAIM
module; claimed accuracy 1 µs. It has RS-232 output which includes
programmable pulse (can be used for PPS) on the DSR line (which
becomes DCD when connecting via a standard null modem.)
With all the antenna gear and battery backup it ended up around US$
1,100.
This clock is good enough to use as a primary receiver. We are
getting accuracies in the microsecond range using a Linux box with a
somewhat patched kernel as the xntpd host; I'm planning to finish the
patches for release pretty soon.
-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: edesio@acm.org [-/+]
Date: Wed, 25 Jun 1997 14:12:54 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: TAPR TAC-2 (Totally Accurate Clock) [-/+]
TAPR TAC-2 (Totally Accurate Clock) is now available!
Take a look at http://www.tapr.org/tapr/html/tac2.html
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 26 Jun 1997 20:48:15 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Linux timekeeping patch
X-Keywords: Arbiter [-/+] Linux [-/+] PPS [-/+]
I have integrated Ulrich Windl's PPS patch for Linux with support for
BSD-style TIOCDCDTIMESTAMP serial ioctl(). A preliminary patch
against 2.1.44-pre3 is available at:
ftp://ftp.kernel.org/pub/linux/kernel/hpa/timekeep-2.1.44-pre3.tar.gz
It includes a program to enable and set the polarity of the PPS
discipline (the latter was an addition of mine after finding out the
polarity of my radio clock was the opposite of what you would expect.)
Note that this patch is only useful if you have a hardware time source
connected via the serial port; network NTP is not affected.
I have used an Arbiter 1092A radio clock with RAIM as the test device;
the claimed accuracy of the device is =B11 =B5s. Preliminary results are
very good. I would very much like to know from other people what
their results are.
NOTE: you must recompile xntp after installing these kernel sources in
order to take advantage the changes! I highly recommend getting the
latest version of xntp (3-5.90.1) from ftp.udel.edu.
Most of the work on this patch was done by Ulrich; I merely ported his
code to 2.1.44-pre3, added TIOCDCDTIMESTAMP and tidied up the integration.
-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: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 03 Jul 1997 09:38:53 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Authenticated ntpq commands cause core-dump in xntpd
X-Keywords: DCF77 [-/+]
In article <5pbus9$fuu@gsms01.alcatel.com.au> jeremyp@gsms01.alcatel.com.au (Peter Jeremy) writes:
> (*) I hadn't seen any incoming leap warning from any upstream feeds by
> a couple of hours before 0000UT and thought they had all forgotten.
DCF77 just announces a leap second one hour before it happens. with
1024s of polling interval it would only get 3 hops along. With 4096
seconds it won't be recognized at all. I don't know where other leap
second announces can come from, but that is definitely a problem for
DCF77.
From: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 30 Jun 1997 12:32:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Inexpensize Radios?
X-Keywords: NMEA [-/+] resolution [-/+]
In article <Pine.LNX.3.96.970630071104.10645R-100000@reflections.eng.mindspring.net>, Todd Graham Lewis <tlewis@mindspring.net> writes:
: On Mon, 30 Jun 1997, W. H. Gilmore wrote:
:
: > I have heard though I don't believe it
: > that there are "good" devices to be had in the $200 range. Please
: > wake me up if I'm in a dream.
:
: My Delorme Tripmate has been very picky about receiving GPS signal, to the
: point of being bothersome. However, at $150, it was a steal. It
: generates NMEA, so the accuracy leaves something to be desired, but it's
: GPS.
Off the shelf handheld GPS receivers aren't worth considering as NTP
Stratum 1 references. The NMEA output has no timing reference information,
so, although it tells you time of last fix, you have no idea when that
happened relative to the output of the message. If you use GPS, then
you need access to the 1 pulse-per-second output. Even then, some
receivers do/did not output the pulse 'on the mark'. Part of the message
output was an offset within the second of the pulse time from UTC, and
the resolution of this offset field was limited to about 1 millisecond.
It is possible to get low-cost GPS engines, but not down in the $200
range when you include all the interfacing. Try
http://www.tapr.org/tapr/html/tac2.html for one possible solution.
J
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 7 Jul 1997 11:04:50 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: time zone names
In article <01bc8903$759f1b80$0605eecd@edsawick>,
Ed Sawicki <ed@alcpress.com> wrote:
> This rather complex system of timekeeping is what results when
> governments dictate the rules for time rather than the scientific
> community. If it were up to me, there would be no Daylight Savings
> Time and no time zones. The entire planet should simply use UTC.
>
> UTC is "Universal Coordinated Time" (in English) and for most
> purposes is the same as Greenwich Mean Time (GMT).
GMT is ambiguous and obsolete, and should be avoided. Today, GMT
is usually used to mean UTC. Earlier, GMT was used to mean UT2.
Please stick to the precisely defined terms UTC, UT0, UT1 and UT2.
If an accuracy better than one second is not needed, one need not
distinguish between them; then one can say GMT, or why not simply UT?
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch@saaf.se paul.schlyter@ausys.se paul@inorbit.com
WWW: http://spitfire.ausys.se/psr -- updated daily!
From: "Greg" <schueman@ix.netcom.com> [-/+]
Date: 8 Jul 1997 05:47:31 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS Time Sync for Windows NT
X-Keywords: Datum [-/+] Windows [-/+]
Look at one of the vendors who has a network attached GPS receiver, such as
True Time,
Datum, et al... Then grab the latest XNTP for NT binaries from
ftp.drcoffsite.com
and off you go. Send email to <access@drcoffsite.com> to get instructions
how to login
to the site.
-Greg
Martin Marshall <marshalm@ebrd.com> wrote in article
<5pqfja$slf$1@ldn2mx1.ebrd.com>...
> Hi,
>
> I require to install some time scyn servers in our Restident offices
(Based
> in Europe), can anyone recommend a GPS attachment and software for a
> Windows NT Server.
>
> It has to be a near zero admin as possible.
>
> Thanks in advance,
> Martin Marshall
>
>
>