From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 22 Jan 1998 11:08:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature. [-/+]
X-Keywords: bug [-/+] FAQ [-/+] FLL [-/+] loopfilter [-/+] Mills [-/+] PLL [-/+] poll [-/+]
In article <JUHA.98Jan21160841@samuraj.c3l.tyreso.se> juha@c3l.tyreso.se (Juha Sarlin) writes:
> Juha> You can't use the kernel pll in Linux 2.0.33 with ntp 4.0.71,
> Juha> because it needs quite different loopfilter weights.
>
> >>>>> "Ulrich" == Ulrich Windl <wiu09524@rrzc4> writes:
>
> Ulrich> Never heard of that before! In one document about NTPv4 RFC-1589 is
> Ulrich> still mentioned. Also it would not explain why the kernel PLL works
> Ulrich> for a while and then goes crazy, i.e. seems no longer updated.
>
> It "goes crazy" mostly because the poll interval is reduced only when
> offset > 5 * sqrt(error), the xntp3-5.91 limit is offset > error.
>
> So, if your frequency changes more than what can be handled at the max
> poll interval, the offset will not get very close to zero.
>
> ntp 4.0.71 works fine for me on Linux, when not using kernel pll.
Before it's getting a real FAQ, I'd like to quote Dave Mills here
(from a private message). He said he did disable the FLL mode because
of a bug in Solaris 2.6. Now xntpd 4.0.71 is broken, because instead
of turning on the FLL it does nothing.
He explicitly said that the current (old) kernel clock dicipline is
fine for NTPv4.
Hope this helps a bit.
Ulrich
P.S. It seems Linux is a better choice than Solaris right now 8-))
From: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 22 Jan 1998 09:35:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS? [-/+]
X-Keywords: broadcast [-/+] configuration [-/+] Mills [-/+] precision [-/+] RFC [-/+] WWVB [-/+]
RFC 957 (Experiments in Network Clock Synchronization, D.L. Mills,
September 1985) has a section on synchronizing to power line frequency.
Parts of it are quoted below:
--- snip ---
4.3.1. On Power-Grid Clocks
Telephone interviews with operators and supervisors of the Potomac
Electric Power Company (PEPCO), the electric utility serving the
Washington, DC, area, indicate that there are three major operating
regions or grids, one east of the Rockies, a second west of the
Rockies and a third in parts of Texas. The member electric utilities
in each grid operate on a synchronous basis, so that clocks anywhere
within the grid should keep identical time. However, in the rare
case when a utility drops off the grid, no attempt is made to
re-establish correct time upon rejoining the grrd. In the much more
common case when areas within the grid are isolated due to local
thunderstorms, for example, clock synchronization is also disrupted.
The experiments provided an opportunity to measure with exquisite
precision the offset between a clock connected to the eastern grid
(DCN3) and the NBS clocks. The results, confirmed by the telephone
interviews, show a gradual gain in time of between four and six
seconds during the interval from about 1700 local time to 0800 the
next morning, followed by a more rapid loss in time between 0800 and
1700. If the time was slewed uniformly throughout these extremes,
the rate would be about 100 ppm.
The actual slewing rates depend on the demand, which itself is a
function of weather, day of the week and season of the year. Similar
effects occur in the western and Texas grids, with more extreme
variations in the Texas grid due to the smaller inertia of the
system, and less extreme variations in the western grid, due to
smaller extremes in temperature, less total industrial demand and a
larger fraction of hydro-electric generation.
The uilities consider timekeeping a non-tariffed service provided as
a convenience to the customer. In the eastern grid a control station
in Ohio manually establishes the baseline system output, which
indirectly affects the clock offset and slewing rate. The local time
is determined at the control station with respect to a WWVB radio
clock. The maximum slewing rate is specified as .025 Hz (about 400
ppm), which is consistent with the maximum rates observed. In the
western grid the baseline system output is adjusted automatically
using a servomechanism driven by measured offsets from the NBS
clocks.
Given the considerations above, it would seem feasable for hosts to
synchronize logical clocks to a particular power grid, but only if
corrections were transmitted often enough to maintain the required
accuracy and these corrections were delivered to the hosts
essentially at the same time. Assuming a worst-case 400-ppm slewing
rate and one minute between correction broadcasts, for example, it
would in principle be possible to achieve accuracies in the 20-ms
range. There are a number of prediction and smoothing techniques
that could be used to inhance accuracy and reduce the overhead of the
broadcasts.
Host DCN3, which uses a line-frequency clock interface, was unlocked
during the experiment period so that the offset between the PEPCO
clock, which is locked to the eastern power grid, could be measured
with respect to the reference host DCN1. Host DCN7, which uses the
same interface, remained locked to DCN1. In spite of the previously
noted instability of the power grid, DCN7 remained typically within
30 ms of DCN1 and only infrequently exceeded 100 ms in the vicinity
of large changes in system load that occured near 0800 and 1700 local
time. Over the seven-day period from 2 July through 8 July the mean
offset was less than a millisecond with standard deviation about 24
ms, while the maximum was 79 ms and minimum -116 ms.
Experiments were also carried out using ICMP Timestamp messages with
hosts known to use line-frequency clock interfaces in California,
Norway and Germany. The results indicated that the western power
grid is rather more stable than the eastern grid and that the
overseas grids are rather less stable. In the Oslo, Munich and
Stuttgart areas, for example, the diurnal variation was observed to
exceed ten seconds.
...
5. Summary and Conclusions
...
3. A synchronization scenario where the clocks in all hosts are
locked to the line frequency and corrections are broadcast
from a central time standard will work only if all hosts are
on the same power grid, which is unlikely in the present
Internet configuration, but may be appropriate for some
applications.
4. In spite of the eastern power grid wandering over as much as
six seconds in a day, it is possible to achieve accuracies in
the 30-ms range using line-frequency interface clocks and
corrections broadcast on the local net.
--- snip ---
--
Marc Brett +44 181 560 3160 Western Geophysical
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK
From: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 22 Jan 1998 09:35:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Use Power line frequency with PPS? [-/+]
X-Keywords: broadcast [-/+] configuration [-/+] Mills [-/+] precision [-/+] RFC [-/+] WWVB [-/+]
RFC 957 (Experiments in Network Clock Synchronization, D.L. Mills,
September 1985) has a section on synchronizing to power line frequency.
Parts of it are quoted below:
--- snip ---
4.3.1. On Power-Grid Clocks
Telephone interviews with operators and supervisors of the Potomac
Electric Power Company (PEPCO), the electric utility serving the
Washington, DC, area, indicate that there are three major operating
regions or grids, one east of the Rockies, a second west of the
Rockies and a third in parts of Texas. The member electric utilities
in each grid operate on a synchronous basis, so that clocks anywhere
within the grid should keep identical time. However, in the rare
case when a utility drops off the grid, no attempt is made to
re-establish correct time upon rejoining the grrd. In the much more
common case when areas within the grid are isolated due to local
thunderstorms, for example, clock synchronization is also disrupted.
The experiments provided an opportunity to measure with exquisite
precision the offset between a clock connected to the eastern grid
(DCN3) and the NBS clocks. The results, confirmed by the telephone
interviews, show a gradual gain in time of between four and six
seconds during the interval from about 1700 local time to 0800 the
next morning, followed by a more rapid loss in time between 0800 and
1700. If the time was slewed uniformly throughout these extremes,
the rate would be about 100 ppm.
The actual slewing rates depend on the demand, which itself is a
function of weather, day of the week and season of the year. Similar
effects occur in the western and Texas grids, with more extreme
variations in the Texas grid due to the smaller inertia of the
system, and less extreme variations in the western grid, due to
smaller extremes in temperature, less total industrial demand and a
larger fraction of hydro-electric generation.
The uilities consider timekeeping a non-tariffed service provided as
a convenience to the customer. In the eastern grid a control station
in Ohio manually establishes the baseline system output, which
indirectly affects the clock offset and slewing rate. The local time
is determined at the control station with respect to a WWVB radio
clock. The maximum slewing rate is specified as .025 Hz (about 400
ppm), which is consistent with the maximum rates observed. In the
western grid the baseline system output is adjusted automatically
using a servomechanism driven by measured offsets from the NBS
clocks.
Given the considerations above, it would seem feasable for hosts to
synchronize logical clocks to a particular power grid, but only if
corrections were transmitted often enough to maintain the required
accuracy and these corrections were delivered to the hosts
essentially at the same time. Assuming a worst-case 400-ppm slewing
rate and one minute between correction broadcasts, for example, it
would in principle be possible to achieve accuracies in the 20-ms
range. There are a number of prediction and smoothing techniques
that could be used to inhance accuracy and reduce the overhead of the
broadcasts.
Host DCN3, which uses a line-frequency clock interface, was unlocked
during the experiment period so that the offset between the PEPCO
clock, which is locked to the eastern power grid, could be measured
with respect to the reference host DCN1. Host DCN7, which uses the
same interface, remained locked to DCN1. In spite of the previously
noted instability of the power grid, DCN7 remained typically within
30 ms of DCN1 and only infrequently exceeded 100 ms in the vicinity
of large changes in system load that occured near 0800 and 1700 local
time. Over the seven-day period from 2 July through 8 July the mean
offset was less than a millisecond with standard deviation about 24
ms, while the maximum was 79 ms and minimum -116 ms.
Experiments were also carried out using ICMP Timestamp messages with
hosts known to use line-frequency clock interfaces in California,
Norway and Germany. The results indicated that the western power
grid is rather more stable than the eastern grid and that the
overseas grids are rather less stable. In the Oslo, Munich and
Stuttgart areas, for example, the diurnal variation was observed to
exceed ten seconds.
...
5. Summary and Conclusions
...
3. A synchronization scenario where the clocks in all hosts are
locked to the line frequency and corrections are broadcast
from a central time standard will work only if all hosts are
on the same power grid, which is unlikely in the present
Internet configuration, but may be appropriate for some
applications.
4. In spite of the eastern power grid wandering over as much as
six seconds in a day, it is possible to achieve accuracies in
the 30-ms range using line-frequency interface clocks and
corrections broadcast on the local net.
--- snip ---
--
Marc Brett +44 181 560 3160 Western Geophysical
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 23 Jan 1998 07:46:01 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Correct time on a web page???
X-Keywords: peer [-/+] poll [-/+]
In article <34C82924.5BDE@p3b.com> Joseph Maas <paragon3@p3b.com> writes:
> I am stumped as to how to set up a web page to poll an sntp server and
> display the correct time. I know html and javascript and can do a
> correct offset and dynamically display a time figure,, and all of that.
> But the mechanism with which to capture ntp data eludes me. I also know
> enough perl to be able to implement a cgi, admittedly however, I know
> nothing about JAVA and I have seen a couple of JAVA/web based clocks,
> but alas, no source-code to even try to understand.
>
> Can anyone steer me in the right direction here?
Use "ntpq -c rl host | grep '^clock=' | awk '{ print $2, $3, $4, $5, $6}'"
as a starting point.
Example:
wiu09524@pc3103:/home/wiu09524 > ntpq -c rl pcphy4
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg
system="Linux", leap=00, stratum=3, rootdelay=104.97,
rootdispersion=16.95, peer=64927, refid=rockall.cc.strath.ac.uk,
reftime=b872c82f.46452000 Fri, Jan 23 1998 8:41:35.274, poll=6,
clock=b872c86c.c8f4e000 Fri, Jan 23 1998 8:42:36.784, phase=1.395,
freq=26531.59, error=8.88
wiu09524@pc3103:/home/wiu09524 > ntpq -c rl pcphy4 | grep '^clock=' | awk '{ print $2, $3, $4, $5, $6}'
Fri, Jan 23 1998 8:44:54.515,
Ulrich
From: Matuscak@Rohrer.com (Joe Matuscak) [-/+]
Date: Fri, 23 Jan 1998 20:24:15 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch Unix system to NT running Tardis? [-/+]
X-Keywords: SNTP [-/+] Tardis [-/+]
In article <885583173.580386825@dejanews.com>, gilgongo@phreak.co.uk wrote:
>That's odd - I've just had an email from the author saying the following:
>
>>Tardis is an SNTP (simple NTP) server NOT a full NTP server so you will not
>>be able to use Tardis as a server for an xntp client.
>
>Did he say there was a workaround? In particular, is there an SNTP client
>for UNIX?
Yes, there is a sntp client (and server for that matter) for Unix. Its called
msntp by Nick Maclaren (nmm1@cam.ac.uk). It is available for anonymous ftp
on oozelum.csi.cam.ac.uk as dist/msntp*
Joe Matuscak
Rohrer Corporation
717 Seville Road
Wadsworth OH 44281
330-335-1541
matuscak@rohrer.com
From: j.b.swenker@ptt-telecom.nl (johan swenker) [-/+]
Date: Mon, 26 Jan 98 16:55:03 MET [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch Unix system to NT running Tardis? [-/+]
In article <885672932.1688797192@dejanews.com>, gilgongo@phreak.co.uk
says...
Change the Makefile: uncomment one of the lines
# LIBS = -lm
>Make stops with:
>main.o(.text+0x15cf): undefined reference to 'sqrt'
Succes, Johan
--
Johan Swenker Phone:+31 50 5855257 E-mail:J.B.Swenker@PTT-Telecom.nl
DISCLAIMER: This statement is not an official statement from, nor does
it represent an official position of, PTT Telecom BV.
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 26 Jan 1998 19:32:36 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNTP Client For UNIX?
X-Keywords: SNTP [-/+]
In article <885583336.572915723@dejanews.com>, <gilgongo@phreak.co.uk> wrote:
>Does anybody know if there is an SNTP (i.e. NOT an SNP) client for UNIX?
Yes - mine.
Anonymous FTP from oozelum.csi.cam.ac.uk in dist/dist/msntp-1.5.tar.gz.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 27 Jan 1998 12:42:41 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NT xntp - synchronisation lost [-/+]
X-Keywords: delay [-/+] dialup [-/+] firewall [-/+] NIST [-/+] poll [-/+] precision [-/+] USNO [-/+] WWVB [-/+]
Brett Kettering <brettk@llnl.gov> writes:
>I see the same thing my NT machine's event log. I ran the ntpq program
>as suggested above and got the following information:
>remote refid st t when poll reach delay offset disp
>==========================================================
>*128.115.14.97 .WWVB. 1 u 12 64 377 -0.14 52.705 15.87
>What should I tweak to get rid of the synchronisation lost message?
Well... The first thing I see here is that your "reachability" is full
(377, or all one-bits), saying that you are communicating just fine
with your server (128.115.14.97, whoever that is) but "delay" is
negative, indicating something is badly screwed up in that
communication.
My guess is that you are connecting to your server over a very busy -
and highly congested - serial line (possibly a dialup?) and NTP
packets are getting dropped and/or duplicated by a router or firewall
somewhere. (UPD, which is the transport protocol that NTP uses, isn't
_supposed_ to duplicate packets, but...)
If that analysis is correct, there is no simple cost-free software
fix for your problem. So your course of action depends on how much
precision you want and how much money you are willing to spend on the
project. Here are some possibilities:
1) get a bigger pipe to your server - big enough to eliminate the
congestion -- change your dialup to a T1, for example. (expensive)
2) get a dedicated low-bandwidth connection to a server -- for
example, use the NIST or USNO dialup servers via a modem. (fairly
cheap, but a continuing expense paying for all those long-distance
phone calls to Boulder CO. You can trade-off expense for precision
by controlling the number of times per day/week/etc you poll the
server.)
3) Buy a GPS radio, hook it up to your machine, and become your own
server. (a moderate one-time expense - between $500 and $3000. It
will require some hardware work to hook it up, and some programming)
I'm sure this isn't what you wanted to hear, but such is life...
Enjoy!
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 30 Jan 1998 14:08:58 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd config [-/+]
X-Keywords: release [-/+]
amitai.schlair@usa.net (Amitai Schlair) writes:
>I'm trying to get xntpd working on my NetBSD/mac68k system, which loses
>quite a bit of time as it goes along (in the vicinity of an hour or two
>per day!). NTP is integrated into NetBSD as of the 1.3 release, so I'm
>using the ntpdate, xntpd and xntpdc that came with the system. However,
>time loss occurs at the usual rate _with xntpd running_.
With an ultra-large intrinsic drift like that, what's probably
happening is that the 5 minutes or so that it takes xntpd to get an
estimate of the offset is long enough for the drift to invalidate the
estimate.
Also possible is that the kernel is syncing to the CMOS clock, which
is way out of kilter.
Read up on the man page for the "tickadj" program. The fixes for both
of these problems are in the "-t" option and the "-s" option
respectively.
Rick
From: Richard Hill <rahill@enterprise.net>
Date: Fri, 30 Jan 1998 18:58:03 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: IRIG B to LTC or VITC [-/+]
X-Keywords: Datum [-/+] documentation [-/+] IRIG [-/+]
What about connecting the IRIG B output to a spare audio channel on the
video ?
When you play the video back, connect the audio output to the IRIG
input, I've tried this with a Datum GPS receiver before and it works,
the only problem is it only decodes during full playback...
Hope this helps,
Richard Hill
John Collyer wrote:
> Does any one know of a product that will take a IRIG B output from a
> time server and convert it to SMPTE time code for video studio
> applications. I need to lay NTP information into video tapes for
> testing and documentation. If you know of a company making such
> products please send me some information.
>
> -J
From: marka@syd.dms.CSIRO.AU (Mark Andrews)
Date: Sat, 31 Jan 1998 14:15:03 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,aus.general
Subject: NTP services on AARNet (Automatic monthy posting)
X-Keywords: broadcast [-/+] SGI [-/+]
******* NOTICE *******
******* SWIFTY.DAP.CSIRO.AU (130.155.98.13) IS NO LONGER A STRATUM *******
******* ONE SERVER. *******
Last Updated: 13 March 1995
AARNet sponsor a stratum 1 server in Sydney.
Machine: tictoc.dap.CSIRO.AU
CNAME: ntp.syd.dms.CSIRO.AU
IP: 130.155.98.1
Service Area: AARNet
Access:
All Affiliated networks to AARNet are permitted to
access this machine. It is requested that that only 2 / 3
machines per net reference this (and other statum 1's). If
you reference this machine you are willing to have your
machine listed as a Stratum 2 in this document
Details of other ntp servers can be found on
dmssyd.syd.dms.csiro.au in the anonymous ftp area.
dmssyd.syd.dms.csiro.au:/CLOCKS.TXT
It is requested that if you connect your net to these machines
that you make available one of your machines as a ntp server and
inform clockmaster@syd.dms.csiro.au so that you can be added to
CLOCKS.TXT.
What are ntp servers?
=====================
A NTP server is a machine configured to provide accurate time
stamps. This is done by talking to a number of other higher
level servers and computing the drift and offset of the local
hardware clock and correcting. This computation filters out
obviously badd clocks.
Stratum 1 servers are connected directly to a reliable source of
UTC time. This could be a GPS reciever an ATOMIC clock or one of
a number of radio clocks around the world providing broadcast
time.
Nifty.dap.CSIRO.AU is a SGI wired to a cesium clock.
From: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 18 Jan 1998 14:17:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Let me show my ignorance
X-Keywords: FAQ [-/+] fudge [-/+] release [-/+]
Thomas Hluchnik <hluchnik@fossi.uni-weimar.de> wrote:
> Michael B. Gilliam wrote:
> >
> > I am setting up a network that does not have access to the Internet,
> > but I need to have all the clocks in sync. For the reason my ntp.conf
> > file has:
> >
> > server 127.127.1.4
> > fudge 127.127.1.4 stratum 4
> >
> I had the same problem with my SUN-Sparc. After trying a lot, I fount
> that I have to use
> server 127.127.1.3
This is a FAQ.
The answer depends on which version of xntpd you have. The syntax of
the server command has changed. I'm not sure exactly when the syntax
changed, but it was sometime between 3.4y and 3-5.89.
"Old" syntax:
server 127.127.1.<stratum> # Where stratum is 0-15
"New" syntax
server 127.127.1.<clocknum> # Where clocknum is 0-3
fudge 127.127.1.<clocknum> stratum <stratum>
If you have a newer xntp release, the clock number of 4 will not work.
Try server 127.127.1.0 instead.
Also, for an undisciplined clock a stratum of 10 is more appropriate
than 4 because it better reflects its true accuracy. If you connect to
an Internet time source in the future, it easily could be stratum 3 or
a even little higher, making your server stratum 4 (or higher), which
would unfairly compete with the poorer-quality local stratum 4 clock.
Check the version of xntp before coding the server command.
--
Marc Brett +44 181 560 3160 Western Geophysical
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 19 Jan 1998 09:20:04 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help with a dialup network!
X-Keywords: password [-/+]
In article <slrn6c4bt2.vs1.ivy@ale.columbus.oh.us> ivy@ale.columbus.oh.us (Mike Iverson) writes:
> Someone has suggested that I "unconfigure" the servers while the link is down.
> However, I cannot figure out how to do this, because xntpdc insists on
> having me enter the MD5 key on the terminal.
I've verified that: The key id and the password are read from the tty
it seems. We should have an alternative here!
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 20 Jan 1998 15:09:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: passwd & minpoll (was: Re: Help with a dialup network! [-/+]
X-Keywords: delay [-/+] FAQ [-/+] minpoll [-/+] password [-/+] poll [-/+] prefer [-/+]
In article <slrn6c6soi.m5r.ivy@frith.acs.ohio-state.edu> ivy@frith.acs.ohio-state.edu (Michael Iverson) writes:
[...]
> Now back to the original problem. Now that I know how to send a
> noninteractive password, I'm having problems setting the "minpoll"
> argument via xntpdc. The html page seems to indicate that it can't be
> done, but the "help" line from xntpdc says something to this effect:
>
> addserver host [minpoll | prefer]
>
> I tried "addserver 128.146.1.7 minpoll 4" and "addserver 128.146.1.7 4".
> the first generated an error, and the second did nothing to the minpoll value.
>
> Any ideas?
xntpdc> he addser
function: configure a new server
usage: addserver addr [ keyid ] [ version ] [ minpoll|prefer ]
### Try "addserver 128.146.1.7 0 3 4"
### Even if the syntax might indicate optional arguments, only the last
### arguments may be omitted, and none between .
BTW: It worked for me:
xntpdc> pe
remote local st poll reach delay offset disp
=======================================================================
=cismsun.univ-ly 132.199.169.222 2 64 363 0.06448 0.006221 0.13503
+pcphy4.physik.u 132.199.169.222 3 64 377 0.00281 -0.000175 0.00053
=ns1.net.ohio-st 5.0.0.0 16 16 0 0.00000 0.000000 16.0000
...
.ns1.net.ohio-st 132.199.169.222 3 16 37 0.15784 -0.068760 0.88271
Regards,
Ulrich
P.S: Another FAQ candidate?
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 03 Feb 1998 09:56:53 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: ntp-drift
X-Keywords: adjustment [-/+] bug [-/+] driftfile [-/+] prefer [-/+]
Myles wrote:
>
> I am just starting to use ntp-4.0.71a on my Linux system.
> I have three simple lines in my ntp.conf file:
> server io.net.hawaii.edu prefer
> server ntp.hawaii.edu
> driftfile /var/run/ntp.drift
>
> No driftfile existed during the first run.
> The second time I went online and spawned ntpd,
> it read -500.00 from /var/run/ntp.drift
Oops!
AFAIK aA drift rate of 500 is the absolute maximum that ntp (.71 or
otherwise) can handle.
>
> What kind of drift should I be expecting? I get the feeling that
> my drift might be even worse than -500.00.
Yes. If this is the true drift rate, and not due to some bug, you'll
have to adjust your clock tick rate manually (check out the adjtime*
calls!) to get it approximately right, before ntp can take over.
I would try to use ntpdate over a 24-hour or longer time span, noting
the ending adjustment, and calculate the drift rate from that.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 04 Feb 1998 22:28:33 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: xntpd year 2000 compliance? [-/+]
X-Keywords: glitch update [-/+]
Matthew Ayres wrote:
>
> James Kirkpatrick wrote:
> >
> > Peter Anderson wrote:
> > >
> > > Does anyone out there know how xntpd is going to handle year 2000?
> > >
> > STUFF ABOUT GPS etc...
> >
> > I don't believe NTP has any problem with year 2000.
>
> Does anybody have any informationw hich is more authoratative
> than this?
> e.g which version are/will be complient?
Simple answer: NTP will survive perfectly well at least until 2036, when
the 64-bit (fixed point 32:32) timestamps wraps around to 1900-01-01.
At this time, you might get a small glitch from some implementations, if
you happen to do an update which spans the wrap-around time, but inside
the (x)ntpd deamon itself, all times are relative, so even this doesn't
really matter.
Anyway, this is easy to verify: Just download the freely available
source code and check it yourself! (It makes for interesting reading)
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: ivy@frith.acs.ohio-state.edu (Michael Iverson)
Date: 19 Jan 1998 15:36:50 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: passwd & minpoll (was: Re: Help with a dialup network! [-/+]
X-Keywords: minpoll [-/+] password [-/+] prefer [-/+]
After a bit of source code reading, I've discovered and verifed that
you can give the password on the command line using the "-c" option.
For example
xntpdc -c "keyid 20" -c "passwd foo" -c "unconfig foobar"
However, this seems to be a bit of a security flaw, since the password
can be read by anyone using "ps".
It would be better to allow passwd to accept an argument in interactive
sessions as well. Thus, instead of the above command, you could do this:
xntpdc < /etc/ntp.bar
where /etc/ntp.bar is:
keyid 20
passwd foo
unconfig foobar
However, as Ulrich and I have found, the second example will do something
like this:
xntpdc < /etc/ntp.bar
MD5 Password:
producing a password prompt on the tty.
Now back to the original problem. Now that I know how to send a
noninteractive password, I'm having problems setting the "minpoll"
argument via xntpdc. The html page seems to indicate that it can't be
done, but the "help" line from xntpdc says something to this effect:
addserver host [minpoll | prefer]
I tried "addserver 128.146.1.7 minpoll 4" and "addserver 128.146.1.7 4".
the first generated an error, and the second did nothing to the minpoll value.
Any ideas?
Mike
In article <WIU09524.98Jan19102004@rrzc4>, Ulrich Windl wrote:
>In article <slrn6c4bt2.vs1.ivy@ale.columbus.oh.us> ivy@ale.columbus.oh.us (Mike Iverson) writes:
>
>> Someone has suggested that I "unconfigure" the servers while the link is down.
>> However, I cannot figure out how to do this, because xntpdc insists on
>> having me enter the MD5 key on the terminal.
>
>I've verified that: The key id and the password are read from the tty
>it seems. We should have an alternative here!
>
>Ulrich
--
| Michael Iverson (Iverson.8@osu.edu) |
| University Technology Services and |
| the Department of Electrical Engineering |
| The Ohio State University |
From: juha@c3l.tyreso.se (Juha Sarlin) [-/+]
Date: 20 Jan 1998 14:09:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature. [-/+]
X-Keywords: KERNEL_PLL [-/+] loopfilter [-/+] precision [-/+]
>>>>> "ktk" == Kristofer T Karas <ktk@ktk.bidmc.harvard.edu> writes:
ktk> Not only was my desktop PC (running 4.0.71) off by at least 62
ktk> milliseconds, but the two local servers (also running 4.0.71) were
ktk> also quite insane.
You can't use the kernel pll in Linux 2.0.33 with ntp 4.0.71,
because it needs quite different loopfilter weights.
The easy fix is to not use kernel pll:
*** config.h.orig Sun Jan 11 11:24:24 1998
--- config.h Sun Jan 11 11:36:49 1998
***************
***************
*** 281,284 ****
/* does the kernel support precision time discipline? */
! #define KERNEL_PLL 1
--- 281,284 ----
/* does the kernel support precision time discipline? */
! /* #define KERNEL_PLL 1 */
From: juha@c3l.tyreso.se (Juha Sarlin) [-/+]
Date: 21 Jan 1998 15:08:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature. [-/+]
X-Keywords: loopfilter [-/+] PLL [-/+] poll [-/+]
Juha> You can't use the kernel pll in Linux 2.0.33 with ntp 4.0.71,
Juha> because it needs quite different loopfilter weights.
>>>>> "Ulrich" == Ulrich Windl <wiu09524@rrzc4> writes:
Ulrich> Never heard of that before! In one document about NTPv4 RFC-1589 is
Ulrich> still mentioned. Also it would not explain why the kernel PLL works
Ulrich> for a while and then goes crazy, i.e. seems no longer updated.
It "goes crazy" mostly because the poll interval is reduced only when
offset > 5 * sqrt(error), the xntp3-5.91 limit is offset > error.
So, if your frequency changes more than what can be handled at the max
poll interval, the offset will not get very close to zero.
ntp 4.0.71 works fine for me on Linux, when not using kernel pll.
From: Matuscak@Rohrer.com (Joe Matuscak) [-/+]
Date: Fri, 23 Jan 1998 20:24:15 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch Unix system to NT running Tardis? [-/+]
X-Keywords: SNTP [-/+] Tardis [-/+]
In article <885583173.580386825@dejanews.com>, gilgongo@phreak.co.uk wrote:
>That's odd - I've just had an email from the author saying the following:
>
>>Tardis is an SNTP (simple NTP) server NOT a full NTP server so you will not
>>be able to use Tardis as a server for an xntp client.
>
>Did he say there was a workaround? In particular, is there an SNTP client
>for UNIX?
Yes, there is a sntp client (and server for that matter) for Unix. Its called
msntp by Nick Maclaren (nmm1@cam.ac.uk). It is available for anonymous ftp
on oozelum.csi.cam.ac.uk as dist/msntp*
Joe Matuscak
Rohrer Corporation
717 Seville Road
Wadsworth OH 44281
330-335-1541
matuscak@rohrer.com
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 11 Feb 1998 09:28:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch. lost and scheduler problems? [-/+]
X-Keywords: documentation [-/+] FAQ [-/+] precision [-/+] reset [-/+] sched_setscheduler [-/+] Stenn synchronized [-/+]
In article <34E02529.F8128DF9@eiscathq.irf.se> Ingvar Keskitalo <Ingvar.Keskitalo@eiscathq.irf.se> writes:
> I'm running xntpd 3-5.92 on Solaris 2.5 and a SUN Ultra 1 140.
>
> I get the following in my log file for this machine:
> 10 Feb 08:40:54 xntpd[21967]: logging to file
> /opt/local/xntp/log/golan.log
> 10 Feb 08:40:54 xntpd[21967]: xntpd 3-5.92 Fri Feb 6 09:50:50 GMT 1998
> (1)
> 10 Feb 08:40:54 xntpd[21967]: sched_setscheduler(): Operation not
> applicable
See Harlan Stenn's animalic comment in the Chnagelog about Solaris and
POSIX.4...
> 10 Feb 08:40:54 xntpd[21967]: tickadj = 5, tick = 10000, tvu_maxslew =
> 495, est. hz = 100
> 10 Feb 08:40:54 xntpd[21967]: precision = 17 usec
> 10 Feb 08:40:54 xntpd[21967]: read drift of 0 from /etc/ntp.drift
> 10 Feb 08:45:11 xntpd[21967]: synchronized to nnn.nnn.nnn.nnn, stratum=4
>
> 10 Feb 09:11:52 xntpd[21967]: time reset (step) 0.326881 s
> 10 Feb 09:11:52 xntpd[21967]: synchronisation lost
> 10 Feb 09:17:11 xntpd[21967]: synchronized to nnn.nnn.nnn.nnn, stratum=4
You just started up it seems. The very fist time step is quite
usual. Further time steps should be rare.
Please everybody: Wait more than 5 or 10 minutes before posting NTP
problems. Use the time to browse the documentation or FAQ instead.
Ulrich
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 27 Jan 1998 23:17:25 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: NT xntp - synchronisation lost [-/+]
X-Keywords: delay [-/+] dialup [-/+] firewall [-/+] poll [-/+] resolution [-/+] WWVB [-/+]
Rick Thomas wrote:
>
> Brett Kettering <brettk@llnl.gov> writes:
>
> >I see the same thing my NT machine's event log. I ran the ntpq program
> >as suggested above and got the following information:
>
> >remote refid st t when poll reach delay offset disp
> >==========================================================
> >*128.115.14.97 .WWVB. 1 u 12 64 377 -0.14 52.705 15.87
>
> >What should I tweak to get rid of the synchronisation lost message?
>
> Well... The first thing I see here is that your "reachability" is full
> (377, or all one-bits), saying that you are communicating just fine
> with your server (128.115.14.97, whoever that is) but "delay" is
> negative, indicating something is badly screwed up in that
> communication.
>
> My guess is that you are connecting to your server over a very busy -
> and highly congested - serial line (possibly a dialup?) and NTP
> packets are getting dropped and/or duplicated by a router or firewall
> somewhere. (UPD, which is the transport protocol that NTP uses, isn't
> _supposed_ to duplicate packets, but...)
No, I think the answer is much simpler:
NT has awful low-level timing resolution, when starting up the xntpd
deamon will make entries in your application log, stating that the
resolution is something like 15 ms.
With a 15ms timing step, it is _very_ easy to send an ntp request
packet, get some processing time at the other end (0.14 ms in this
case), and the get the reply, while still staying inside the same 15 ms
timer tick.
Since the local delta seems to be zero, and the remote delta is
positive, the difference becomes negative.
This should not be a problem though, as long as NTP knows that all local
times are suspect, on the order of +-8 ms.
It does mean that you'll never be able to lock an NT machine to
sub-millisecond absolute UTC offsets, something which my ancient 486-66
Linux test machine does easily, talking to a GPS reference clock on the
other side of a main router.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Wed, 11 Feb 1998 20:31:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SCO clock ticks vanish !! [-/+]
X-Keywords: SCO [-/+] synchronized [-/+]
In <6bsj38$kjv@newsops.execpc.com> manning@execpc.com (Steve Manning) writes:
> When you disable this behavior, how does SCO act then? Is there a
> down-side to this change?
I don't know what the effects are in the long run if the system isn't
synchronized from the outside. I *think* your clock will loose time,
depending on the load of the system and the number of hardware interrupts
per second. My only experience is with systems that run NTP. Then the
effects are quite obvious: running with track_rtc=1 makes the clock jump
irratically, running with track_rtc=0 keeps the clock under control of
NTP. If you want to run NTP on SCO, dig up the article I posted to this
group in april '97. (I can email it if you want).
--
Kees Hendrikse | email: kees@echelon.nl
| web: www.echelon.nl
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: James Kirkpatrick <jimkirk@uwyo.edu> [-/+]
Date: Wed, 28 Jan 1998 17:15:36 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd year 2000 compliance? [-/+]
X-Keywords: Arbiter [-/+] broadcast [-/+] reset [-/+]
Peter Anderson wrote:
>
> Does anyone out there know how xntpd is going to handle year 2000?
>
> Most GPS clocks only supply a 2 digit year in the broadcast ASCII string (we
> have an Arbiter 1092B GPS clock which definitely doesn't).
>
> - Is it being worked on by the NTP developers?
> - Is it up to the GPS clock manuafacturers?
> - Does it handle it now by just assuming year "00" is actually 2000?
> - Does NTP protocol work backwards from 2036?
>
> It's a bit difficult to simulate a year 2000 test. You can certainly
> disconnect the GPS antennae, set the GPC clock to 23:58 31/12/99 and let it
> tick over to year 2000, BUT, because its not tracking satellites, the time
> quality code makes NTP ignore the time strings being broadcast.
>
> refclock_arbiter.c is a bit weird in that it turns broadcast on (B5) , gets a
> time string then turns broadcast off (B0). A quick fix would be to send a
> "DU" command which displays the UTC date in the form ddmmmyyyy (eg 01JAN2000 )
> prior to doing the B5.
>
> Peter Anderson
> Senior Communications Analyst
> Westpac banking Corporation, Australia
> panderson@westpac.com.au
> 02 9902 5938
First, remember that GPS and NTP are completely unrelated. If GPS has a
problem, that's GPS' problem and not NTP's, and vice-versa.
A particular receiver could have a problem that is not related to GPS
proper, or NTP.
I don't believe NTP has any problem with year 2000.
I believe GPS has a problem on August 21/22 1999 where the week number rolls
over and some older receivers will think it's 1985 or some such. GPS does not
actually include a year, just a week number in the current epoch. Some
receivers contrive a year based on the week number, thus the problem when the
week hits zero. There's a web page somewhere that explains all this very
clearly. Some newer receivers try to get around this design blunder (my
opinion) in GPS by, for example, attempting to guess the epoch based on the
total number of leap seconds (which is in the GPS data stream). Others simply
know it can't be 1985 because it was built in 1997 and thus will contrive a
correct year for another epoch or so. Or, they simply remember the rollover
which means things could be hosed on a complete power-off reset if this
isn't kept in non-volatile memory.
If a receiver is supplying a year as two ASCII characters, I have a very
heavy weight that will fix the receiver :-)
Corrections/alternate opinions welcome!
Jim
P.S. See http://www2.datum.com/datum/rollovernr.html
From: robk@oldtimer.win-uk.net (Robin Kimberley)
Date: Sat, 31 Jan 1998 12:09:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: IRIG B to LTC or VITC [-/+]
X-Keywords: Datum [-/+] documentation [-/+] IRIG [-/+]
In article <34D222BB.517EAC19@enterprise.net>, Richard Hill (rahill@enterprise.net) writes:
>What about connecting the IRIG B output to a spare audio channel on the
>video ?
>When you play the video back, connect the audio output to the IRIG
>input, I've tried this with a Datum GPS receiver before and it works,
>the only problem is it only decodes during full playback...
>Hope this helps,
> Richard Hill
>
>John Collyer wrote:
>
>> Does any one know of a product that will take a IRIG B output from a
>> time server and convert it to SMPTE time code for video studio
>> applications. I need to lay NTP information into video tapes for
>> testing and documentation. If you know of a company making such
>> products please send me some information.
Datum's 9700 series time code products have an Option 44
which is a SMPTE/LTC Encoder. With this fitted the 9700 will accept
IRIG B (or any of a number of codes) and provide the output you
require.
Contact sales@datum.com in the USA or give me a call in the UK.
Regards
Rob Kimberley
Product Manager, Time and Frequency
Sematron UK Limited
Tel: ++44 1256 812 222
Fax: ++44 1256 812 666
Web: http://www.sematron.com
Mail: rkimberley@sematron.com
From: jonathan@Kowhai.Stanford.EDU (Jonathan Stone)
Date: 1 Feb 1998 01:14:21 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd config [-/+]
X-Keywords: ntptime [-/+] release [-/+]
In article <1d3p9yz.ilsgd01nf3fggN@[10.0.2.16]>, amitai.schlair@usa.net (Amitai Schlair) writes:
|> Rick Thomas <rbthomas@lilypad.rutgers.edu> wrote:
|>
|> > amitai.schlair@usa.net (Amitai Schlair) writes:
|> >
|> > >I'm trying to get xntpd working on my NetBSD/mac68k system, which loses
|> > >quite a bit of time as it goes along (in the vicinity of an hour or two
|> > >per day!). NTP is integrated into NetBSD as of the 1.3 release, so I'm
|> > >using the ntpdate, xntpd and xntpdc that came with the system. However,
|> > >time loss occurs at the usual rate _with xntpd running_.
|> >
|> > Read up on the man page for the "tickadj" program. The fixes for both of
|> > these problems are in the "-t" option and the "-s" option respectively.
|>
|> Strangely enough, I don't think 'tickadj' is included. I've asked some
|> NetBSD folks, and they tell me that it's no longer necessary. (?)
FWIW, I've found that the xntpd 3.5f tickadj still works fine on
NetBSD with NetBSD's xntp (which is around 3.5-92), so just building
and installing the standard xntp3.5-92 tickadj and trying Rick Thomas'
solution should Just Work.
Why no ntptime? One of the people who's been over the NetBSD in-kernel
NTP code is Dennis Ferguson, the original author of tickadj. AFAIK,
it's not supposed to be necessary on NetBSD because the NetBSD kernel
handles the kernel clock correctly -- at least on i386, sparcs,
pmaxes, sun3s, etc, etc. (also see the comments at the end of the
tickadj man page, which explain why tickadj should go away!)
On NetBSD, the `sysctl' utility (introduced in 4.4bsd) can read the
relevant kernel variables. What do you get from
sysctl kern.clockrate
I'd guess the kernel is computing its tick value correctly, but that
your Mac is losing about 4% of its clock ticks. If memory serves,
this is not unusual on 68k Macs that're also running PPP. If so, I'd
suggest contacting Allen Briggs and also filing a PR with NetBSD. If
nothing else, really badly-behaved clocks like this may be sufficient
reason to put tickadj back into the NetBSD base distribution.