From: schueman@access4.digex.net (Greg Schueman) [-/+]
Date: 22 Jun 1996 00:53:35 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What NTP code? Un*x/NT/VMS
X-Keywords: HP-UX [-/+] Novell [-/+] release [-/+] VMS [-/+]
In article <31BFF74C.500F@ggr.co.uk>,
Richard Wright <jrw3612@ggr.co.uk> wrote:
>I am looking to distribute NTP round our network which has many types of
>clients. Naturally I have xntp as often referred to in this group, but
>what other options are there? How good are they?
>
>I am looking at support for SG IRIX, HP-UX, Sun in the Unix world then
>stuff for NT and VMS and possibly Novell. Should I just look to port
>xntp or are there OS versions, others?
Well there is an ntpdate port for VMS.
Also there is a stable but with REFCLOCK support version for NT.
look at ftp://ftp.digex.net/pub/access/schueman/ntp
Diffs for NT including many bugfixes and a GUI installer have
been submitted, but you can get them on my site until the next
release becomes available.
On Netware RFC868 (daytime protocol), see RDATE.NLM from Murkworks
I believe. (it's free)
-Greg Schueman
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Sat, 29 Jun 1996 19:05:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.setup
Subject: Re: Linux & NTP - should I update the system clock before halt? [-/+]
X-Keywords: fudge [-/+]
In article <DLM.96Jun27140105@firebird.osf.org>,
Dan Murphy <dlm@firebird.osf.org> wrote:
> 2. Since the clock is only corrected once/day typically, I run
> a little utility that calls ntp_adjtime to set the "frequency"
Providing you define a local clock (127.127.1.x) you can do this with
the fudge command in xntpdc.
> ntp_adjtime, the timekeeping is good to within about 0.5
> second/day.
I get about +-100ms a day, although the machine is in an air conditioned
room. This was by reading the time with 'netdate localhost' and comparing
against a radio controlled watch.
>
> 3. I almost never halt my system, but setting the cmos clock
> from the system clock before shutdown would be a good idea if
> the system clock has been maintained as above. There is a
> little utility ( clock ) that will do that for you. I believe
> it comes with most distributions.
The kernel does this anyway (1.2.13). Once you've tweaked the time
once, the kernel goes into a mode where it believes the software clock
and corrects the CMOS clock at a nominal interval of 11 minutes (see
kernel/sched.c for details). Don't use clock -a if you've ever run
timed or xntpd in the same boot session; they fight each other!
--
David Woolley, London, England david@djwhome.demon.co.uk
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 01 Jul 1996 20:19:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.setup
Subject: Re: Linux & NTP - should I update the system clock before halt? [-/+]
X-Keywords: fudge [-/+]
In article <Dtrzp6.63o@djwhome.demon.co.uk> David Woolley <david@djwhome.demon.co.uk> writes:
> > 2. Since the clock is only corrected once/day typically, I run
> > a little utility that calls ntp_adjtime to set the "frequency"
> Providing you define a local clock (127.127.1.x) you can do this with
> the fudge command in xntpdc.
So you can! I hadn't read the local clock blurb carefully enough
to notice that.
> > ntp_adjtime, the timekeeping is good to within about 0.5
> > second/day.
> I get about +-100ms a day, although the machine is in an air conditioned
I'm actually getting 100 ms a day or better also (as indicated by
the amount of correction ntpdate applies), so I figure practically
any PC should be tunable to within 0.5 sec.
dlm
From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) [-/+]
Date: 3 Jul 1996 18:56:07 +0200 [-/+]
Newsgroups: comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Re: Leap Seconds [-/+]
X-Keywords: broadcast [-/+] DCF77 [-/+] FAQ [-/+] Linux [-/+] precision [-/+]
Ted.Harding@nessie.mcc.ac.uk (Ted Harding) writes:
>Now all that is fascinating, and I sincerely appreciate learning it.
Check the sci.astro FAQ, where I have written a chapter that
summarizes the various forms of standard time (UT0, UT1, UT2, UTC,
TIA, etc.) and how they are kept in sync with leap seconds.
Recommended reading for all computer experts that do not yet know how
the time standards work.
>BUT: What the heck is Mark Shuttleworth's (or anyone else's) system doing
>nit-picking with leap seconds? According to John Kuhn you get one every
>12-18 months.
There has been no official leap second at the end of last June, so
Mark's mache has shown some kind of error which he should investigate.
Here is how leap seconds are handled in Linux:
The system call _adjtimex() allows any root process to tell the kernel
that at the end of this day (in the UTC time zone!), a leap seconds
will be inserted or skipped. And then, the kernel will either repeat
the second 23:59:59 or it will skip it. You can use _adjtimex() in
order to find out, whether a leap second is just in progress (for
instance in order to display 01:59:60 MET on my local central european
leap second aware X clock). I live in time zone UTC+02:00, so when it
is 23:59:60 in Greenwich on the zero meridian (i.e., in Universal
Time), then it is 01:59:60 in German summer time.
_adjtimex() is usually called by software like xntpd, which receive
time information over the NTP protocol. NTP includes a flag that
allows to warn all time receivers that this UTC day will end with a
leap second. Time broadcast services like GPS or DCF77 also announce
leap seconds at least an hour before (GPS even many weeks before). If
you use software to adjust the phase and frequency of the kernel clock
with _adjtimex(), then this software might also forward the leap
warning to the kernel.
>My real question is: Can it be true that Linux fusses over this "leap
>second" question? Or is it some kind of "in" joke by the system
>developers?
No, this was no in-joke (like the famous "printer on fire" kernel
message)! I have a DCF77 long wave time signal receiver (for 20 US$)
connected to the serial port of my Linux machine, and my Linux time is
always with around 1 ms error the exact official atomic reference time
UTC. If my Linux would not be aware of leap seconds, I would get a
time error 1000x the normal time error in the few minutes after the
leap second.
BTW: When you call _adjtimex() periodically in order to discipline the
kernel clock according to the reference clock, then the Linux kernel
knows that it knows the time better than the CMOS battery clock in the
PC and it will then write the time back automatically every 11 min
onto the CMOS battery clock with a precision of around 5 ms. This
ensures that I have very precise time on my system even after a
reboot.
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>
From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) [-/+]
Date: 7 Jul 1996 13:51:04 +0200 [-/+]
Newsgroups: comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Re: Leap Seconds [-/+]
X-Keywords: DCF77 [-/+] delay [-/+] filter [-/+] fudge [-/+] implementation [-/+] Linux [-/+] PLL [-/+] PPS [-/+]
David Woolley <david@djwhome.demon.co.uk> writes:
>Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de> wrote:
>>message)! I have a DCF77 long wave time signal receiver (for 20 US$)
>>connected to the serial port of my Linux machine, and my Linux time is
>>always with around 1 ms error the exact official atomic reference time
>>UTC. If my Linux would not be aware of leap seconds, I would get a
>How did you manage to calibrate it to this accuracy? On my reckoning,
>the kernel will see the signal from a simple receiver like this some 15
>to 30ms after the true reference time (filter group delay (probably the
>main factor), UART sampling error (1 / ("baud" rate * 16)) and
>intrerrupt latency). Unless you have a calibrated radio clock on the
>same LAN, I think it would be difficult to calibrate to an absolute
>error as tight as 1ms.
Simply write a small test routine (either in the kernel in do_timer()
or as a user process) that outputs from the kernel clock a pulse per
second (PPS) signal on a printer port pin. Then use a digital
oscilloscope and compare the phase error of your Linux clock to the
PPS signal of a borrowed GPS receiver with good PPS output. Adjust the
fudge factor in order to minimize this phase error.
The interrupt latency and UART sampling errors do not matter, because
the kernel PLL applies a low pass filter that averages out all these
errors anyway in the long term.
>Also, have you reported back successful use of this clock driver to the
>University of Delaware, so that they can declare it supported for Linux
>and include it in the Makefile.
Raw DCF77 pulses have either 100 ms or 200 ms length (1 bit/s data
transmission rate). At 50 bit/s, the serial input can easily
distinguish these two pulse forms. All this DCF77 raw pulse serial
port parsing has been supported by xntpd for years now, including the
leap second warning. Frank Kardel built it originally into xntpd.
There is absolutely nothing new about my implementation.
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>
From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) [-/+]
Date: 5 Jul 1996 01:24:07 +0200 [-/+]
Newsgroups: comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Re: Leap Seconds [-/+]
X-Keywords: daylight [-/+] Linux [-/+] precision [-/+]
wiu09524@rrzc5 (Ulrich Windl) writes:
>In article <4re8n7$39g@cortex.dialin.rrze.uni-erlangen.de> mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) writes:
>> BTW: When you call _adjtimex() periodically in order to discipline the
>> kernel clock according to the reference clock, then the Linux kernel
>> knows that it knows the time better than the CMOS battery clock in the
>> PC and it will then write the time back automatically every 11 min
>> onto the CMOS battery clock with a precision of around 5 ms. This
>> ensures that I have very precise time on my system even after a
>> reboot.
>Except when you enter daylight savings time. After reboot your clock
>is off by one hour, then. Believe me. Nobody fixed it yet. Ok, it
>only happens if you run your CMOS clock in local time (for software
>like MS-DOS or OS/2).
Those people who care about correct timing on their Linux machine all
run the battery buffered CMOS clock under UTC. Even DOS can handle
this with clk360rs.zip (see archie). Therefore I don't see any need to
fix something which happens only in a situation (keeping local time in
the CMOS clock) that should not be used right from the beginning.
Never reboot Win95 during the hour that is repeated in local time when
daylight saving time ends? Really silly things happen ...
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>
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 04 Jul 1996 08:09:03 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP and Linux : sugggestions?
Linux-2.0.1 should be used when doing NTP...
From: gwinn@res.ray.com (Joe Gwinn) [-/+]
Date: Tue, 09 Jul 1996 20:13:47 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS time display
X-Keywords: bug [-/+] Linux [-/+] TAI [-/+]
In article <hpa.31df07c4.I.use.Linux@freya.yggdrasil.com>, hpa@zytor.com
(H. Peter Anvin) wrote:
> Followup to: <4rbpcc$nr@nadine.teleport.com>
> By author: bkg@teleport.com (Brian K. Garrett)
> In newsgroup: comp.protocols.time.ntp
> >
> > Hmmmm. Seems like there are several things that could have caused this
> > discrepancy--a software bug, display of GPS time as opposed to UTC, and
> > failure to receive the satellites correctly. I think the most likely is
> > that it was displaying GPS time--I thought it was 10 sec *behind* UTC, but
> > if GPS time is *ahead* by 10 (or 11 now) seconds then I was probably
> > mistaken about the receiver lagging behind--seems kind of coincidental
> > that it would be that same 10 sec difference. And it *is* difficult to
> > get accurate readings from this things inside a store, but OTOH if it
> > wasn't reading the satellites then how did it get the latitude and
> > longitude?
> >
>
> Note: if the software author was lazy or misinformed about time
> scales, the time displayed might be TAI, i.e. with no leap seconds
> added. If so, it would be an integral number of seconds (in the
> teens) ahead of UTC.
The ahead/behind terminology is confusing. GPS System Time is a fixed
number of seconds (19.0) different from TAI; both are varieties of Atomic
Time. UTC is a form of Earth Rotation Time, which follows the
ever-slowing rotation of the Earth. GPS broadcasts GPS System Time, plus
a byte containing the number of seconds between UTC and GPS. Currently,
GPS-UTC= +11 seconds, exactly. This difference grows more or less
linearly at 0.75 seconds per year, but the actual changes (leaps) are
always whole seconds. TAI-UTC= +30.0 seconds at present.
For a good paper on these kinds of time, see:
"http://sadira.gb.nrao.edu:80/~rfisher/Ephemerides/times.html".
For the lowdown on leap seconds, see: "http://tycho.usno.navy.mil/leapsec.html".
For the list of all leap seconds from 1961 Jan 1 through 1996 Jan 1, see:
"ftp://maia.usno.navy.mil/ser7/tai-utc.dat", which is also referencef from
the above-referenced webpage.
From: Philip Gladstone <philip@raptor.com>
Date: Wed, 10 Jul 1996 09:25:40 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: timex.h version skew [-/+]
X-Keywords: adjtimex [-/+] compatible [-/+] implementation [-/+] Linux [-/+] Mills [-/+] PLL [-/+]
Dan Murphy wrote:
>
> Any enlightening information on this would be welcome. Including:
> why were the #*$##* field names changed? Any known reason that
> NTP wouldn't work on Linux if the field names were reconciled?
> Why not standardize on the original field names as in Linux?
As the person who did the original Linux kernel port, I can answer some
of
these questions:
Linux never even had the regular adjtime call. I had proposed adding
adjtime
and adjtimex, but this was shot down in flames. I settled for an
adjtimex
that used a couple of (then reserved) bits in the mode word to allow
adjtimex
to run in an adjtime compatible manner. adjtime was then implemented as
a
library function in libc.
Unfortunately, Dave Mills was still working on his kernel interface and
we had a couple of iterations and I think (this was a few years ago)
that
there was a time when the interfaces were compatible.
In retrospect, I'd do it all differently and have both adjtime and
adjtimex
as library routines, and have a kernel_clock_ctl system call. This would
use version number stamped data structures. It would be the job of the
adjtimex
library function to perform the appropriate mapping. I might want to
hack the
code in ntp_loopfilter.c to be able to support different versions of the
kernel,
but I'm not sure.
It would be really nice if your implementation aligned with the Linux
implementation.
I suspect that the Linux implementation has the largest installed base
(in fact, I
bet that no other kernel PLL implementation comes close). It is a pity
that the
current versions of XNTP don't support it!
Philip
--
Raptor Systems, Inc. Voice: +1-617-487-7700
WWW: http://www.raptor.com/
From: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) [-/+]
Date: 10 Jul 1996 11:59:00 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: timex.h version skew [-/+]
X-Keywords: compatible [-/+] FreeBSD [-/+] implementation [-/+] Linux [-/+] PLL [-/+]
In article <31E3AF54.63CB@raptor.com>,
Philip Gladstone <philip@raptor.com> wrote:
>It would be really nice if your implementation aligned with the Linux
>implementation.
>I suspect that the Linux implementation has the largest installed base
>(in fact, I
>bet that no other kernel PLL implementation comes close). It is a pity
>that the
>current versions of XNTP don't support it!
FreeBSD 2.x has been shipping with an NTP-compatible kernel PLL for
two years now... We also ship with the (comparatively ancient)
version 3.4e of xntpd. FreeBSD 1.1 implemented the original PLL
interface for nine months before that (and shipped with 3.3x, if I
remember correctly).
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
From: billingd@crc.cra.com.au (Mr David Billinghurst)
Date: 21 Jul 1996 19:54:55 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Windows NT binaries for XNTP
I got a reply
~Date: Wed, 17 Jul 1996 08:53:41 +0000
~From: Antoon Milatz <antoon.milatz@tek.com>
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
Organization: Tektronix
To: billingd@tek.com
~Subject: NT / NTP
X-Keywords: Windows [-/+]
>Does anyone know of a site with xntpd binaries for Windows NT?
>Replies by mail thanks. News feed is down.
Try
ftp://ftp.digex.net/pub/access/schueman/ntp/intel/
Antoon
-------------------------------------------------------------------------
(Mr) David Billinghurst Phone : +61 3 469 0642
Comalco Research Centre Fax : +61 3 462 2700
PO Box 316, Thomastown 3074, Australia E-mail : billingd@crc.cra.com.au
From: Robert Sexton <sextonr.crestvie@squared.com> [-/+]
Date: Fri, 19 Jul 96 09:59:55 PDT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Handheld GPS vs. Station Clock [-/+]
X-Keywords: antenna [-/+] PPS [-/+]
In Article<31ECAAD3.41C6@ggr.co.uk>, <jrw3612@ggr.co.uk> writes:
>
> I have been trialing a GPS Station Clock (Trax as it happens). This
> works fine, but does seem to be rather expensive given that several of
> my collegues have suggested that their handheld GPS devices could tell
> me the time too. Given that these handhelds are something like 1/10th of
> the price of the station clock I can afford to have several to gain
> resilience for considerably less cost. In fact I would probably have
> _greater_ resilience.
>
> Does anyone use handhelds? Can anyone think of a good reason not to use
> them? We are a commercial company and consistent time across the network
> is probably of greater benefit than abosolute reference to UTC.
I have played around with my Magellan XL, and I was not convinced that
if provided very good accuracy. It did much better than eyeball-and
wristwatch, but the timecode output seemed to be rather irregular.
Magellan makes an OEM reciever with software optimized
for timing applications. It costs about $450, and you have to provide
a power supply. It does output 1 PPS, plus some time codes. I am not
sure whether you have to provide an antenna or not.
- Cheers,
Robert Sexton.
From: bbense@shred.stanford.edu (Booker C. Bense)
Date: 22 Jul 1996 07:05:19 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Handheld GPS vs. Station Clock [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
In article <NEWTNews.837796010.30031.cis418@pc398.cis.squared.com>,
Robert Sexton <sextonr.crestvie@squared.com> wrote:
>
>In Article<31ECAAD3.41C6@ggr.co.uk>, <jrw3612@ggr.co.uk> writes:
>>
>> I have been trialing a GPS Station Clock (Trax as it happens). This
>> works fine, but does seem to be rather expensive given that several of
>> my collegues have suggested that their handheld GPS devices could tell
>> me the time too. Given that these handhelds are something like 1/10th of
>> the price of the station clock I can afford to have several to gain
>> resilience for considerably less cost. In fact I would probably have
>> _greater_ resilience.
>>
>> Does anyone use handhelds? Can anyone think of a good reason not to use
>> them? We are a commercial company and consistent time across the network
>> is probably of greater benefit than abosolute reference to UTC.
>
- - Well, what you're actually paying all that money for is the oscillator
inside the box. The GPS part is actually not all that much money. Once
it syncs to UCT, the clock will continue to generate accurate time, whether
your GPS works or not. These clocks are probably overkill for most nets.
They are designed to be lab instruments, not just clocks for computers.
- - If you just want consistant time, all you need is the xntpd software and
a computer with a reasonable on board clock (good luck there!).
- - Booker C. Bense : bbense@networking.stanford.edu
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMfOKnQD83u1ILnWNAQE0DAQA0N796YOvGlZlO0+Xp2d9Gj8GTSCSzRnp
Q9lBxsTRFN9WWLFv6H3Ioq/7YAiZbZpioo2AEvhbj9Gx6Hg4rWJ3TKhDP3+vPPZI
nfgYJjV6U4zEuz5kn7E3+pwCPimdg9I5FCRtQ8RxOw1Nz8565T/RifzhC9nR7YQ2
koube33nREs=
=YUJR
-----END PGP SIGNATURE-----
From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) [-/+]
Date: 23 Jul 1996 14:48:39 +0200 [-/+]
Newsgroups: comp.std.internat,comp.protocols.time.ntp,de.comp.standards
Subject: Re: Official English Abbreviation for German Time Zone [-/+]
X-Keywords: caesium [-/+] DCF77 [-/+] precision [-/+] synchronized [-/+]
genef@netcom.com (Gene Fornario) writes:
>Maybe a nation's attitude is reflected in it's timekeeping :)
Oh, then what does this tell about Germany?
Here, practically all public transportation clocks have second
precision, because they contain long wave receivers for the German
DCF77 time signal transmitter located in Frankfurt. The cost for
additional DCF77 reception hardware can be as low as 10-20 USD. Most
other publicly visible clocks contain DCF77 receivers, too.
Many traffic lights are synchronized by DCF77. Some German cities use
a concept called "Green Wave", where the traffic lights along a main
road through a citiy a coordinated in a way that optimized traffic
flow and discourages speeding. For a working Green Wave traffic light
control, you need second precision time available in a large area and
DCF77 receivers are much cheaper than installing wires between the
traffic lights.
You can buy wrist watches with DCF77 receivers for 50 DEM which show
the time with <100 ms precicion all the time.
The German TV broadcaster ZDF generates its broadcasting sync signals
from a caesium clock that is adjusted to UTC(PTB). If you watch the
second German TV channel, you will therefore see a frame rate of
50.0000000000 Hz. I wouldn't want to watch TV without this frequency
accuracy ... ;-) Well, it is actually quite usefull, because you can
use any TV set in order to calibrate the timing in your oscilloscope.
Sorry, off-topic but hopefully not entirely boring ...
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>
From: genef@netcom.com (Gene Fornario)
Date: Tue, 23 Jul 1996 18:01:00 GMT [-/+]
Newsgroups: comp.std.internat,comp.protocols.time.ntp,de.comp.standards
Subject: Re: Official English Abbreviation for German Time Zone [-/+]
X-Keywords: DCF77 [-/+] NIST [-/+] precision [-/+] WWVB [-/+]
In article <4t2hn7$12k@cortex.dialin.rrze.uni-erlangen.de> mskuhn@cip.informatik.uni-erlangen.de writes:
>genef@netcom.com (Gene Fornario) writes:
>
>>Maybe a nation's attitude is reflected in it's timekeeping :)
>
>Oh, then what does this tell about Germany?
>Here, practically all public transportation clocks have second
>precision, because they contain long wave receivers for the German
>DCF77 time signal transmitter located in Frankfurt. The cost for
>additional DCF77 reception hardware can be as low as 10-20 USD. Most
>other publicly visible clocks contain DCF77 receivers, too.
Our National Institute for Standards and Technology (NIST) has just
announced that they will increase the power of WWVB (60 KHz, Fort Collins,
Colorado) four-fold from 13 kilowatts. They expect to do this by the end of
1997. This should increase coverage and make it possible to have such
receivers.
At this time, the only watch that will receive WWVB signals is going for a
price of $1000 USD.
Gene--
From: pm@zetnet.co.uk (Paul Martin)
Date: 24 Jul 1996 14:57:37 GMT [-/+]
Newsgroups: comp.std.internat,comp.protocols.time.ntp,de.comp.standards
Subject: Re: Official English Abbreviation for German Time Zone [-/+]
X-Keywords: NIST [-/+] WWVB [-/+]
In <genefDv0Cpp.3IJ@netcom.com>, genef@netcom.com (Gene Fornario) writes:
>Our National Institute for Standards and Technology (NIST) has just
>announced that they will increase the power of WWVB (60 KHz, Fort Collins,
>Colorado) four-fold from 13 kilowatts. They expect to do this by the end of
>1997. This should increase coverage and make it possible to have such
>receivers.
Mmm... I wonder if that will cause interference to MSF transmissions
(Rugby, UK) also on 60kHz, but with slightly greater ERP.
I doubt it.
Markus mentioned TV signals of ZDF being particularly precise. MSF is
calibrated by measuring the phase difference of the line sync of a TV
transmission from Bedford, as measured at Rugby and at the National
Physical Labs.
The emissions on 198kHz from Droitwich (don't know about Westerglen and
Burghhead) are precisely controlled, as are those from Allouis on 162kHz.
--
Paul Martin <pm@zetnet.net>
From: vjs@calcite.rhyolite.com (Vernon Schryver) [-/+]
Date: 30 Jul 1996 21:18:26 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: timed looping forever
X-Keywords: broadcast [-/+] daylight [-/+] FreeBSD [-/+] Linux [-/+]
In article <4tkev8$rc@castle.snafu.de>,
Bernd Hentig <bernd@finow.snafu.de> wrote:
>Hi.
>I'm running the current in.timed binary from Caldera Linux 1.2.13 (libc4.7)
>and a home-made version ported from the current FreeBSD Sources on
>Linux 1.2.13 / libc5.0.9.
It might pay to look at the most recent `timed` source in
ftp.sgi.com:sgi/src/timed.tar.Z I made a few fixes since last the
version I sent to 4.4BSD-Lite.
>The problem is, that timed -M loops forever printing the following messages
>to my log file:
> ...
> 127.0.0.0 NOMASTER
> 192.168.6.0 NOMASTER
> nets=2 masters=0 slaves=0 ignored=2 delay2=500
>acksend: to broadcast: MASTERREQ 1 16327 127.255.255.255 helpdesk
That net-127 is an unusual IP address for timed to pay attention to.
>readmsg: looking for MASTERACK from ANY, 127.0.0.0
>readmsg: wait 0. 0 at Tue Jul 30 09:53:55 1996
> ...
>Obviously timed doesn't accept itself as the master demon.
Actually, there is no such thing as a "[timed] master demon". Instead,
there is only the Moderator elected to average all systems's ticks and
distribute the consensus or average time.
The easiest way to debug such a problem, particularly in the simple
situation of only one host, is to run `timed -dM` in your favorite
debugger, such as gdb. `Timed` is more challenging to fight when you
are running it on several hundred systems scattered over dozens of IP
networks.
By the way, I trust that -M is in use, so that `timed` knows that it
can be a candidate for moderator/master.
>Any idea why ?
>Should I throw timed away and use xntpd instead or just try to rewrite timed ?
>Which are the proper RFCs to do so ?
It's your nickel, so spend it to give what you think is the most fun.
Because `timed` is shipped turned on by default by some UNIX vendors,
it is might be running on more systems than the various NTP implementations
combined. I do not mean that `timed` is better than NTP; they serve
somewhat different purposes. I that mean if `timed` didn't work at all,
someone in the last 10 years might have noticed, so a wholesale rewrite
would be best justified on other grounds.
Note also that this newsgroup, comp.protocols.time.ntp, is officially
about NTP instead of TSP, the protocol used by `timed`. Well, actually,
I guess it is now mostly about incredibly interesting topics such as
the criteria for determining the correct accronym for daylight savings
time in various small states and principalities.
Vernon Schryver vjs@rhyolite.com
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Sun, 11 Aug 1996 16:47:20 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd 3.5 and linux 1.2.13 [-/+]
X-Keywords: Linux [-/+] PLL [-/+]
In article <alrybjp7zvk.fsf@pprz04.HRZ.Uni-Marburg.DE>,
Wolfgang Ratzka <ratzka@hrz.uni-marburg.de> wrote:
>
>Will xntpd 3.5 work with Linux 1.2.13 or will I need a newer version
>of Linux?
An unmodified 3.5f will run perfectly happily with the 1.2.13 kernel,
providing you don't try to enable the kernel PLL option (typical errors
relative to SunOS 4.1.1 on the same LAN are around 400 microsecond, with
peak errors of only a few milliseconds).
Note that you must either use the tickadj utility to set the clock
frequency within about 70ppm, or must apply a patch to tell xntp that
Linux tickadj is really 5 microsecond, giving a maximum frequency error
of over 300ppm, even though corrections of down to 1 microsecond can be
applied. I've done both. Using tickadj is always reccommended.
I find xntpdc the most useful tool for debugging xntp.
--
David Woolley, London, England david@djwhome.demon.co.uk
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 12 Aug 1996 09:06:36 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd 3.5 and linux 1.2.13 [-/+]
X-Keywords: PLL [-/+]
In article <ul3ivapa62z.fsf@artemis.fsl.noaa.gov> romberg@artemis.fsl.noaa.gov (Mike Romberg) writes:
> Hmm, with the 2.0 kernel 3.5f does not seem to work unless you enable
> the kernel PLL option. When I did so I needed to change a few defines
> so that they would match what was in /usr/include/sys/timex.h (__adjtimex
> and __ntp_gettime). Xntpd-3.5f seems to be working ok now. It did not
> work without these changes. Something must have changed between 1.2.13 and
> 2.0 which affects xntpd.
Sure; the kernel PLL has been fixed! Thus for a more accurate time I'd
strongly recommend Linux-2.0!
From: Wolfgang Ratzka <ratzka@hrz.uni-marburg.de>
Date: 14 Aug 1996 17:40:03 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd 3.5 and linux 1.2.13 [-/+]
X-Keywords: Linux [-/+]
>>>>> "DW" == David Woolley <david@djwhome.demon.co.uk> writes:
DW> Note that you must either use the tickadj utility to set the
DW> clock frequency within about 70ppm, or must apply a patch to
DW> tell xntp that Linux tickadj is really 5 microsecond, giving a
DW> maximum frequency error of over 300ppm, even though
DW> corrections of down to 1 microsecond can be applied. I've
DW> done both. Using tickadj is always reccommended.
I automated the search for the right tickadj value by the following
shell script fragment:
------------------------------------------------------------
#!/bin/sh
# This is where the files are in our setup
TICKADJ=/anw/start/tickadj
NTPDATE=/anw/start/ntpdate
XNTPD=/anw/start/xntpd
XNTPDCONF=/anw/tree/system/xntp-3.5f/lib/stratum3.conf
SED=/usr/bin/sed
NAWK=/usr/bin/gawk
SERVER=whatever.server.you.want.to.use.for.ntpdate
SERVERVERSION=2
HOSTNAME=`/bin/uname -n`
# I use /etc/tickadj.$HOSTNAME to store the tickadj value appropriate
# for the machine. This saves those people who "clone" Linux boxes
# using tar, as they usually change at least the host name.
if [ -r /etc/tickadj.$HOSTNAME ]
then
echo "Using /etc/tickadj.$HOSTNAME"
$TICKADJ `cat /etc/tickadj.$HOSTNAME`
else
echo "/etc/tickadj.$HOSTNAME not found"
# In this case /etc/ntp.drift is invalid, too, I guess.
/bin/rm /etc/ntp.drift /etc/tickadj.* >/dev/null 2>&1
echo "Wait 10 sec to determine drift of internal clock."
#
# Is 10 secs too short???
#
$TICKADJ 10000 >/dev/null 2>&1
$NTPDATE -b -p8 -o$SERVERVERSION $SERVER >/dev/null 2>&1
sleep 10
TICK=`$NTPDATE -b -p8 -o$SERVERVERSION $SERVER \
| $NAWK '/step time server/ { \
gsub("^.*offset ","",$0); \
gsub(" sec.*$","",$0); \
print int(10000.5+1000*$0); }'`
echo $TICK > /etc/tickadj.$HOSTNAME
$TICKADJ $TICK
fi
$NTPDATE -b -p8 -o$SERVERVERSION $SERVER >/dev/null 2>&1
$XNTPD -c $XNTPDCONF
--
Wolfgang Ratzka Phone: +49 6421 28 5876 FAX: +49 6421 28 6994
SnailMail: Uni Marburg, HRZ, Hans-Meerwein-Str., D-35032 Marburg, Germany
"The number of wildflowers planted at Olympic venues is 1.5 million
square feet" (from IBM's Olympic WWW Server)
From: lea@mickey.etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Date: 12 Aug 1996 19:43:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: CLOCK.TXT
henrym@sacto.mp.usbr.gov wrote:
: I have not been keeping up with NTP developments lately. I went
: to look at louie.udel.edu and could not find a copy of clock.txt
: anywhere on the system. I also pulled down the latest NTP kit
: (xntp3-5.85) and could not find clock.txt in there either.
: Whois is maintaining clock.txt these days, and where is it homed?
: Thanks in advance,
Howdy,
I've found
http://www.eecis.udel.edu
to have the clock1.html and clock2.html files.
I too would like a text version on the ftp site (louie.udel.edu),
but I guess I can learn to surf.
(Copies snarffed in June emailed to henry 12 Aug about 19:30z)
Bruce Bartram bbartram@etl.noaa.gov NOAA Boulder, CO
From: mose@ns.ccsn.edu (Russell Mosemann)
Date: 12 Aug 1996 06:43:00 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate [-/+]
X-Keywords: firewall [-/+]
Derek Ferguson <derekf@direct.ca> writes:
>I've just downloaded and compiled xntp3.5f. I'm running SunOS 5.5.
>When I try using the ntpdate utility, I always get the message
>ntpdate: no server suitable for synchronization found
Why don't you turn on debugging and then let us see the output?
It's really hard to just dream up something out of thin air as to why
you are having problems when no one else is. Something else you can
check is to make sure that you are accessing version 3 servers and
that you aren't sitting behind a firewall which is denying packets
from those servers, but you would have been able to tell that if you
had turned debugging on.
--
Russell Mosemann Concordia College Voice: (402) 643-7445
Computing Center Seward, NE 68434 Fax: (402) 643-4073
"I'm not happy about that at all, not even a little bit." - Mike Reith
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Mon, 12 Aug 1996 06:36:06 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: ntp and PC Time Source [-/+]
X-Keywords: implementation [-/+] precision [-/+] resolution [-/+] SNTP [-/+] Tardis [-/+] Windows [-/+]
In article <320A7267.35C3@wasp.co.za>,
Tiaan van Aardt <tiaan@wasp.co.za> wrote:
>
>If your Alpha canuse SNTP, time/tcp, or time/udp to sync with other systems,
>you can try and get hold of Tardis (now a shareware app). Tardis95 (for win95)
>acts as a SNTP, time/tcp, or time/udp server.
I've just been reading the web pages on another SNTP implementation, called
WinSNTP.
Something that should born in mind in synching a Unix system to such a
product is that, WinSNTP, at least only claims an accuracy of 100 to 200
m (I assume they meant ms). That would be so poor that xntp would
probably consider lock to have been lost, on encountering a more
reliable time source, and would step the time rather than slewing. My
reading of the web page suggests that WinSNTP always steps the time, but
is probably better than RDATE (time/tcp and time/udp) based methods
because it can use fractional second information.
With the reference implementation of NTP and even with a pre-emptive
multi-tasking OS with poor clock resolution, you can expect errors in
the 15ms range, even when the reference is over the internet, and, over
a LAN, with systems with good resolution, you can expect sub-millisecond
errors, when the reference source is on the same LAN segment.
I'm not knocking the product here - it is limited by the Windows
environment; for precision time, you want to attach the reference source
to a pre-emptive multi-tasking source, with clock frequency control, and
slave the Windows systems off it, not the other way round.
The URL for WinSNTP is:
http://www.solaris.com/~stu/winsntp/winsntp.html
--
David Woolley, London, England david@djwhome.demon.co.uk
From: WhiskerP@logica.com (Peter Whisker) [-/+]
Date: Mon, 12 Aug 96 10:21:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp and PC Time Source [-/+]
X-Keywords: Windows [-/+]
In article <DvzF6E.4zr@djwhome.demon.co.uk>, David Woolley <david@djwhome.demon.co.uk> wrote:
>In article <320A7267.35C3@wasp.co.za>,
>Tiaan van Aardt <tiaan@wasp.co.za> wrote:
>>
>
>I'm not knocking the product here - it is limited by the Windows
>environment, and the marketing prose is no more ambiguous than most.
>The URL for WinSNTP is:
>
>http://www.solaris.com/~stu/winsntp/winsntp.html
There is a nice *free* as apposed to shareware program from Rob Chambers
<robc@thinkman.com>, http://www.thinkman.com/~thinkman/ which is far superior
to WinSNTP (in my opinion at least), however is only supported on Win95
or WinNT4.0. It is called Dimension 4.1.
It sits minimised on your toolbar and never displays anything even at startup
unless you want it to.
It uses the simplified NTP too, but is totally hassle free in my experience.
Peter
************************************************************
* Peter Whisker * Logica UK Ltd, Cobham, Surrey, UK
*Any opinions are mine!* http://www.logica.com/ for theirs !
* whiskerp@logica.com * http://public.logica.com/~whiskerp/
For PGP key:Send e-mail to pgp_peter@reepicheep.logica.co.uk
Fingerprint:FD 97 98 9A F4 1E 9C 89 8B 8D FF 73 65 A0 E1 99
From: Stu Phillips <stu@coetanian.com>
Date: Mon, 12 Aug 1996 22:52:52 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp and PC Time Source [-/+]
X-Keywords: adjustment [-/+] implementation [-/+] poll [-/+] resolution [-/+] RFC-1305 SNTP [-/+] Windows [-/+]
As the author of WinSNTP I thought I'd comment on the following...
David Woolley wrote:
>
> What is SNTP? Someone pointed to a web page for a program called WinSNTP,
> but my reading of that implied that SNTP is a marketing name for a
> simplified, non-compliant implementation, of NTP.
>
WinSNTP is a client (and server) side implementation of RFC-1769,
The Simple Network Time Protocol - based on a true subset of RFC-1305 (NTP).
Not a marketing name, just a statement of fact.
> Something that should born in mind in synching a Unix system to such a
> product is that, WinSNTP, at least only claims an accuracy of 100 to 200
> m (I assume they meant ms). That would be so poor that xntp would
> probably consider lock to have been lost, on encountering a more
> reliable time source, and would step the time rather than slewing. My
> reading of the web page suggests that WinSNTP always steps the time, but
> is probably better than RDATE (time/tcp and time/udp) based methods
> because it can use fractional second information.
>
WinSNTP in actuality maintains synchronization considerably closer
than 100-200 mS - even with time steping and lost interupts on the PC.
Unfortunately, under Windows and Windows 95 there is no provision for
fine clock adjustment in the OS - Windows NT provides the capability for
finer adjust but is still prone to loss of interupt - a time factor
not simply ameanable to clock phase adjustment.
WinSNTP was designed for an environment where the load on servers was
to be minimized. We presumed (rightly I believe) that having hordes
of Internet connected clients pounding on NTP servers was unsports-person
like conduct to say nothing of downright un-neighborly.
WinSNTP therefore constrains the time error to be 100 mS over
a maximum of 16 times the initial poll period (documented in the help
file for those wishing to read it) as a balance between appropriately
accuracy and server load.
> With the reference implementation of NTP and even with a pre-emptive
> multi-tasking OS with poor clock resolution, you can expect errors in
> the 15ms range, even when the reference is over the internet, and, over
> a LAN, with systems with good resolution, you can expect sub-millisecond
> errors, when the reference source is on the same LAN segment.
>
> I'm not knocking the product here - it is limited by the Windows
> environment, and the marketing prose is no more ambiguous than most.
> The URL for WinSNTP is:
Ahhhhh, dammed for faint praise ;-)
WinSNTP offers both client and server support for all Windows environments.
Its typical accuracy is within < 20 mS given modern day hardware and reasonable
connectivity. Unlike freeware, it is supported software.
For those still interested, WinSNTP can be found on:
and soon to move to (pages now active BTW)...
Regards
Stu