From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]
Date: Fri, 10 Oct 1997 06:35:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Using an external time source on HP-UX 10.20 [-/+]
X-Keywords: Datum [-/+] HP-UX [-/+]
In article <343A3627.3BEC1F8@nerdnet.nl>, Rob van der Krogt (rob@nerdnet.nl) writes:
>Hello,
>
>We want to synchronize the time on our servers to the 'real time' as
>provided by a radio receiver through a serial port. The standard time
>daemon on HP-UX provides this facility, but I don't know what hardware
>to buy. Can anybody help me?
>
>Thanks in advance,
>Rob
>
>
Why not use a dedicated Network Time Server from Datum. The model
TS2100 uses GPS as its front end time reference, and outputs NTP via
10baseT or AUI. If you are already running NTP, it is by far the
simplest method (as a minimum, just set up your IP address on the
TS2100). We sell this product in the UK, but Datum also has a
distributor in the Netherlands
If you need more information, either take a look at www.datum.com
and go to the Bancomm-Timing division, or contact me here in the
UK.
Regards
Rob Kimberley
Product Manager, Time and Frequency
Sematron UK Limited
Office Home
Tel: ++44 1256 812 222 ++44 1926 613 162
Fax: ++44 1256 812 666 ++44 1926 613 775
Web: http://www.sematron.com http://www.pcug.co.uk/~oldtimer
Mail: rkimberley@sematron.com robk@oldtimer.win-uk.net
From: jussi.torhonen@tietosavo.fi (Jussi Torhonen)
Date: 10 Oct 1997 09:05:27 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Server for WIN NT [-/+]
X-Keywords: Windows [-/+]
In article <O2yCxsP18GA.312@upnetnews04>, hniemann@bigfoot.com says...
>
>Hy !
>
>I search a freeware NTP Server for Windows NT.
ftp://ftp.cs.uta.fi/pub/av/ntp/xntp3-5_90_3-gui.zip
Jussi
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Jussi Torhonen / Internet: jussi.torhonen@tietosavo.fi
Tietosavo Oy / AX.25: OH7DC@OH7RBA.#KUO.FIN.EU
P.O.Box 1582 / X.400: C=fi;ADMD=elisa;PRMD=tsnet;O=tietosavo;
FIN-70461 KUOPIO / S=torhonen; G=jussi
FINLAND / Tel: +358-17-193 231, Fax: +358-17-193 355
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From: carl-junk@five-ten-sg.com (Carl Byington)
Date: Fri, 10 Oct 1997 16:18:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Server for WIN NT [-/+]
X-Keywords: Windows [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
In article <O2yCxsP18GA.312@upnetnews04>, hniemann@bigfoot.com says...
>I search a freeware NTP Server for Windows NT.
The NT port of ntp 3.5.90.3 is at
http://www.five-ten-sg.com/util/ntp35903.zip as a temporary service
until Larry's NT porting site is back.
- --
Mail address munged for the obvious reason - remove the junk.
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
-----BEGIN PGP SIGNATURE-----
Version: 4.5
iQCVAwUBND5HIdZjPoeWO7BhAQHbQgP+JuhPoy/iaBhGn/i2J4skUUbL6jcVfZAI
8Vf/4fsoxHIFN1RkAoNvLWo6njk64uiIgP9Is5/mRH4j9aAEXVOi4YHjgQKczqEN
JNUPPywI39fg6KKWbkcCAQlJmslGyb2fZjZsWD2B/fCgEboJEapMEuFkY5Jj/ZXE
5kkErtZWBu4=
=H11S
-----END PGP SIGNATURE-----
From: John Hay <jhay@zibbi.mikom.csir.co.za> [-/+]
Date: 10 Oct 1997 20:26:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NMEA clock driver
X-Keywords: clockstats [-/+] FreeBSD [-/+] NMEA [-/+] prefer [-/+]
Henk Uijterwaal <henk@ripe.net> wrote:
: I'm trying to set up NTP with a NMEA reference clock. This clock is
: connected to the com2 port of a PC running FreeBSD.
: I started by patching refclock_open so that it sets up the com port
: correctly (baud rates, com-port options, etc). This is code
: transplanted
: from a little test program that I wrote. With a second test-program
: that just listens to the port, I can see that the clock is sending the
: right strings. However, when I add the clock to /etc/ntp.conf with
: server 127.127.20.1 prefer
I have three FreeBSD machines here using the nmea driver. You should not
need to make any changes to xntpd to get it to work, if you are using
FreeBSD 2.2 or later.
If your NMEA source don't use the NMEA standard 4800bd, etc. I would
rather lock those values in /etc/rc.serial to the values that you
need. That way you can use xntpd without mods and upgrades will also
be easier.
Why do you use 127.127.20.1 and not 127.127.20.0? Do you have more than
one NMEA clock? You will also need to link /dev/gps0 (if you use
127.127.20.0) to your serial port device, something like this:
-----
# ls -l /dev/gps0
lrwxrwxrwx 1 root wheel 10 Feb 8 1997 /dev/gps0 -> /dev/cuaa1
-----
Another thing that you can do is to enable clockstats in your ntp.conf
file, then you should see lines like this in there:
-----
50731 73097.429 127.127.20.0 $GPRMC,201817,A,2548.6171,S,02816.5179,E,000.0,195.5,101097,015.1,W*7A
50731 73161.498 127.127.20.0 $GPRMC,201921,A,2548.6117,S,02816.5088,E,001.1,195.5,101097,015.1,W*71
50731 73225.486 127.127.20.0 $GPRMC,202025,A,2548.6039,S,02816.4965,E,001.7,348.9,101097,015.1,W*71
-----
John
--
John Hay -- John.Hay@mikom.csir.co.za
From: jra@scfn.thpl.lib.fl.us (Jay R. Ashworth) [-/+]
Date: 10 Oct 1997 18:44:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NTP over variable-latency network routes [-/+]
X-Keywords: Garmin [-/+] NMEA [-/+] PPS [-/+]
On 30 Sep 1997 18:04:43 GMT,
David Dalton <dalton@cup.hp.deletethis.com> wrote:
> You are not the first person to say: "I want network services to work even
> when the network is down!", but I have a hard time with this attitude. It
> will take some sysadmin work on your part to set your systems up for this
> environment, but it is doable. It reminds me of attempting to shoot a
> mosquito with an elephant gun.
It's worthy of note in this context, also, that external clock sources
with decent 1PPS outputs are _incredibly_ cheap nowadays, but past
standards. Garmin manufactures a standalone GPS receiver, the GPS 25,
I believe, that offers a usable 1 PPS and NMEA absolute GPS time output
for about $250 or so.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "People propose, science studies, technology
Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
From: Richard Curnow <richard@curnow.demon.co.uk>
Date: 15 Oct 1997 07:48:41 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NTP over variable-latency network routes [-/+]
X-Keywords: delay [-/+]
>>>>> "Terje" == Terje Mathisen <Terje.Mathisen@hda.hydro.com> writes:
Terje> If I get 3 times, like 90, 80 and 250 ms, using just the
Terje> lowest (80ms) value will give a maximum error of 40 ms,
Terje> using a (weighted?) average of all three will probably give
Terje> much worse results, unless the weighting was such as to
Terje> effectively disregard the highest turnaround time.
Given an offset measurement T a root distance L (=Lambda in RFC1305),
appendix H of RFC1305 shows that the local time is then known to be
within [T-L/2, T+L/2]. Given a single measurement you know little
more than that, because you have no idea of the relative sizes of the
forward and return network delays. On an unloaded network link they
would probably be about the same, which gives T as the best estimate
of the local offset, provided L is small.
In the case stated above, with measurements T1, T2 and T3, we can
infer that the local offset lies in the intersection of three
intervals like this
[T1-45ms,T1+45ms] /\ [T2-40ms,T2+40ms] /\ [T3-125ms,T3+125ms]
(This ignores effects due to skew between the times when we make the
measurements).
If we get different ratios of forward and return network delays in the
three measurements, this may give us a tighter bound than the best of
the individual measurements.
Now if we know the round-trip delay for a particular measurement, we
can compare this with the lowest such values encountered to date for a
particular server. Amongst all the measurements with comparably low
round-trip delay, we can be fairly sure that none of the measurements
are biased by one network trip taking much longer than the other.
Consequently, it makes sense to examine the trend of such samples
against time to get an idea of how fast or slow the local clock is
running per unit time.
This concept can be extended by weighting the samples used in the
trend analysis; the weighting would probably be some inverse power of
the root distance associated with each sample.
In certain environments, when the round-trip delay rises, it can be
pretty much guaranteed that all the extra delay is on one side of the
journey (e.g. dial-up machines downloading news/ftp etc - all the
delay is on the return side.) This knowledge _could_ be used to
'correct' the offset measurements, at the risk of sometimes making the
error on the measurements twice as bad (if the machine is uploading
something at the time). Alternatively, any measurements whose
round-trip delay exceeds the typical minimum by some factor (I've
found 1.75 to be quite workable) can be discarded from the analysis.
Richard.
--
Richard P. Curnow
Stevenage, England
Date sent: Sat, 13 Sep 1997 11:43:20 EDT
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Copies to: mills@udel.edu
Subject: Re: kernel timekeeping and STA_PPSFREQ [-/+]
X-Keywords: authentication [-/+] configuration [-/+] glitch [-/+] PPS [-/+] TIME_ERROR [-/+]
Ulrich,
I'm really busy just now with NTPv4, so I will have to answer your message
in pieces. The STA_PPSFREQ and STA_FREQHOLD were added post facto,
mainly for PGP (Principle of General Paranoia). Sometimes there is a
PPS source which is stable, but not necessarily locked to UTC. In such
case, set STA_PPSFREQ, but not STA_PPSTIME. The STA_FREQHOLD is
intended for use in the xntpd spike detector to avoid frequency surges
in case of large time spikes detected by xntpd. My experience is that
glitches are relatively unimportant and infrequent and, if suppressed,
do not disrupt the timekeeping business. Perhaps these should be
reported in STA_PPSJITTER, but if not are within PGP range. The
other three error bits really do reveal the health of the animal.
Note that the pps_jitter variable is an exponential average of past
samples and must be maintained even in case of spike, in order to
provide for reliable detection of a real step. I did not intend to
avoid such spikes, only to reveal them for postmortem analysis.
The glitch detector gets rid of the real bad ones anyway.
The transition function for TIME_** should be clear from context.
The daemon sets a leap bit and the state machine jumps to TIME_INS
or TIME_DEL sometime during the day preceeding the leap. The kernel
hops one way or the other at the leap and winds up in TIME_WAIT.
When the daemon clears the leap bit, the machine hops back to
TIME_OK. The daemon can order TIME_ERROR at any time, but the kernel
doesn't care.
I don't understand your comment about ntp_gettime. The daemon does not
use that syscall, but a user program might.
As I said originally, changing names and retrofitting existing kernels
is simply not in my card deck.
NTPv4 is still in flux but working in most respects. The new clock
discipline algorithm is working, the authentication scheme implemented,
but not yet tested. The major change for autonomous configuration is
mostlly done, but the grad working on that won't be available until
October.
If you are working on PPS for linux, you should see the Internet Draft
on an API proposed by Digital, Sun and myself. It was submitted last
week, but I haven't verified it has been put up yet.
Dave
Date sent: Sat, 13 Sep 1997 12:06:07 EDT
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Copies to: Dave Mills <mills@huey.udel.edu>
Subject: Re: kernel timekeeping and STA_PPSFREQ [-/+]
X-Keywords: TIME_ERROR [-/+]
Ulrich,
One thing I tried to do in the kernel was leave the error handling to
the daemon, on the grounds that the daemon is much easier to change
than the kernel. The downside to this is, if the daemon croaks, the
kernel can sail to the sunset without fair warning. In most cases
this will lead to expanding error bounds as per spec. In some aberrant
cases, the kernel can sail to Monday leaving the system clock warped.
Furthermore, I didn't want to get into a pissing match with the
kernel and daemon, so I suggest you leave the kernel state machine alone
and let the daemon worry about TIME_ERROR.
Your comment on the calibration problem witih missed pulses deserves
further analysis. It should be able to tolerate a missed pulse or
two; however, accurate frequency calibration requires accurage knowledge
of the calibration interval. Thinks about that.
Dave
Date sent: Tue, 16 Sep 1997 19:30:48 +0100
From: "David L. Mills" <mills@udel.edu>
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Copies to: Dave Mills <mills@huey.udel.edu>
Subject: Re: kernel timekeeping and STA_PPSFREQ [-/+]
Ulrich,
There might in fact be the case that the kernel stuff in the
distribution and kern.tar be different. However, whichever carries
the later date contains the actual text ported into the vendor's
kernels. I tried to make them all the same and to follow the simulator,
primarily as a verification tool. Some defines might have been fiddled
to match the particular machine hardware, such as oscillator frequency
tolerance (Digital is very strict, nobody else cares). There might be
places where the code could be improved and where it behaves slightly
different than the inline commentary. The primary reason for the
commentary is to reassure vendor kernel programmers that the code is
solid and can be trusted. For that reason, I am reluctant to change even
one line or one comment, unless there is a real problem, such as you
found. In any case, the code I wrote has been incorporated in at least
two vendor kernels and, believe me, it is Real Hard to change anything.
So, I regard myself as out of the kernel timekeeping business, at least
to the extent that the current and future NTP agenda works with the
current kernel model and code. Unless you find another obvious gaffe, I
recommend you do the same.
In any case, thanks for the careful scrute and sane check.
Dave
From: Ulrich.Windl@rz.uni-regensburg.de [-/+]
To: mills@udel.edu
Date: 1997-09-07 [-/+]
Subject: kernel timekeeping and STA_PPSFREQ [-/+]
X-Keywords: bug [-/+] PPS [-/+]
Dave,
I think I have found a bug in the PPS kernel simulator:
in kern.c (with line numbers):
851 if (v_usec > (tick >> 1)) {
852 if (pps_glitch > MAXGLITCH) {
853 pps_glitch = 0;
854 pps_tf[2] = u_usec;
855 pps_tf[1] = u_usec;
856 } else {
857 pps_glitch++;
858 u_usec = pps_offset;
859 }
860 } else
861 pps_glitch = 0;
862
869 pps_tf[2] = pps_tf[1];
870 pps_tf[1] = pps_tf[0];
871 pps_tf[0] = u_usec;
Lines 854 and 855 should set ``pps_tf[1]'' and ``pps_tf[1]'' (compare
with lines 869 and 870). Otherwise it does not make much sense in my
eyes...
To be complete, here's a patch:
--- kern.c Sat Dec 17 05:22:47 1994
+++ kern.c.new Sun Sep 7 19:02:41 1997
@@ -851,8 +851,8 @@
if (v_usec > (tick >> 1)) {
if (pps_glitch > MAXGLITCH) {
pps_glitch = 0;
- pps_tf[2] = u_usec;
pps_tf[1] = u_usec;
+ pps_tf[0] = u_usec;
} else {
pps_glitch++;
u_usec = pps_offset;
Ulrich
Date sent: Tue, 23 Sep 1997 14:35:17 EDT
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Copies to: Harlan Stenn <stenn@whimsy.udel.edu>, mills@udel.edu
Subject: Re: Suspect code in ntp_loopfilter [-/+]
X-Keywords: implementation [-/+] Linux [-/+]
Ulrich,
Originally, the ntv.shift was intended to detect the presence or absence
of the pps extensions, which were added some time after the initial
implementation. As I recall, Linux had a problem when the pps version was
used with the old timex.h, a situation that may continue even today. Your
suggestion might be better, but would incorrectly identify the extensions
as not present when they were, but only in the initial stages before the
averaging interval ramps uo. Actually, if we can determine that the
"new" timex.h is in fact in standard Linux, I't like to take that little
widget out.
Dave
Date sent: Thu, 25 Sep 1997 09:27:22 EDT
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Copies to: Dave Mills <mills@huey.udel.edu>, Harlan Stenn <stenn@whimsy.udel.edu>
Subject: Re: Suspect code in ntp_loopfilter [-/+]
X-Keywords: antenna [-/+]
Ulrich,
I do have considerable concern for cases in which some greenhorn
enables pps and then connects the antenna to a random signal generator.
The enable protocol used by xntpd is rather anal-retentive, in that
the companion reference clock has to be considered truechimer and
survivor and well within the ambiguity range of +-0.5 s. Your suggestion
adds an additional sieve that requires at least enough samples to ramp
up the integration interval. I have no problem with that, other than
the concern that, once the change has been announced, I will have literally
cozens of product support dudes yammering at me with concerns that
747s will crash, civilizations will revolt and God will curse me,
unless I clearly ennumerate the hazards of do/not do the change. Life
is ugly.
Dave
From: Ulrich.Windl@rz.uni-regensburg.de [-/+]
To: mills@udel.edu
Date: 1997-09-14 [-/+]
Subject: Suspect code in ntp_loopfilter [-/+]
X-Keywords: jitter [-/+] Linux [-/+] PPS [-/+]
Dave,
the following code is from <timex.h> included in the kernel.tar:
#ifdef PPS_SYNC
#define MAXFREQ (512L << SHIFT_USEC) /* max freq error (100 ppm) */
#define MAXTIME (200L << PPS_AVG) /* max PPS error (jitter) (200 us) */
#else
#define MAXFREQ (512L << SHIFT_USEC) /* max freq error (200 ppm) */
#endif /* PPS_SYNC */
I don't see how ``(512L << SHIFT_USEC)'' corresponds to ``100ppm'',
especially not how it can also correspond to ``200ppm'' without
``PPS_SYNC''. The comment in from of it says:
* MAXFREQ is the maximum frequency tolerance of the CPU clock
* oscillator plus the maximum slew rate allowed by the protocol. It
* should be set to at least the frequency tolerance of the oscillator
* plus 100 ppm for vernier frequency adjustments. If the kernel
* PPS discipline code is configured (PPS_SYNC), the oscillator time and
* frequency are disciplined to an external source, presumably with
* negligible time and frequency error relative to UTC, and MAXFREQ can
* be reduced.
Even if PPS_SYNC is configured in the kernel, it's not guaranteed that
PPS sync will work all the time. Thus it does not make much sense (IMHO)
to put `MAXFREQ' into a constant; maybe a variable would be better.
Also your example code for `hardpps' contains the following lines:
/*
* Here the calibration interval is adjusted. If the maximum
* time difference is greater than tick / 4, reduce the interval
* by half. If this is not the case for four consecutive
* intervals, double the interval.
*/
if (u_usec << pps_shift > bigtick >> 2) {
pps_intcnt = 0;
if (pps_shift > PPS_SHIFT)
pps_shift--;
} else if (pps_intcnt >= 4) {
pps_intcnt = 0;
if (pps_shift < PPS_SHIFTMAX)
pps_shift++;
} else
pps_intcnt++;
IMHO the calibration interval is increased after 5 (not 4) successful
calibrations, because the count is increased at last. For Linux I
rewrote the section as:
int_count++;
if (u_usec << pps_shift > bigtick >> 2) {
int_count = 0;
if (pps_shift > PPS_SHIFT)
pps_shift--;
} else if (int_count >= 4) {
int_count = 0;
if (pps_shift < PPS_SHIFTMAX)
pps_shift++;
}
Would you agree? (I also hoped to save one jump that RISC processors
don't like anyways...)
Regards,
Ulrich
Date sent: Mon, 27 Oct 1997 22:12:20 EST
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Copies to: mills@udel.edu
Subject: Re: NTP: hardpps routine [-/+]
X-Keywords: jitter [-/+] PPS [-/+]
Ulrich,
I gotta put you on hold. It's been awhile since I last danced with that
code and I have a couple of heavy conferences to survive. However, I
recall the intent of the code was not necessarily to ignore jitter
or even wander, as long as the calibration interval could safely
increase while avoiding a slip of the tick, which could cause
severe error. The idea is to discipline the frequency in a closed-
loop system, not necessarily to calculate the exact frequency. Once the
frequency has been measured and the interval increased to the max, it's
pretty hard to kick the loop out of lock, unless the PPS jitter becomes
much larger than the tick interval.
Dave
From: Ulrich.Windl@rz.uni-regensburg.de [-/+]
To: mills@udel.edu
Subject: NTP: hardpps routine [-/+]
Date: 1997-09-24 [-/+]
X-Keywords: dispersion [-/+] implementation [-/+] jitter [-/+] PLL [-/+] PPS [-/+]
Dave,
yet another pack of questions for the kernel discipline technical
memorandum ('96) and the implementation:
In the reference <timex.h> MAXTIME is defined as
#define MAXTIME (200L << PPS_AVG) /* max PPS error (jitter) (200 us) */
with
#define PPS_AVG 2 /* pps averaging constant (shift) */
In the simulator kern.c (Dec 94) the pps-jitter is initialized with
long pps_jitter = MAXTIME; /* time dispersion (jitter) (us) */
and in ntp_gettime() implemented in kern_ntptime.c (Sep 94) pps_jitter is
returned as
ntv.jitter = pps_jitter >> PPS_AVG;
All the above would indicate that pps_jitter is scaled microseconds,
and not microseconds (as the comments suggest). That's just a minor
thing though.
When the frequency is set in the kern_ntptime.c (MOD_FREQUENCY) the
current pps_freq is subtracted from the value given. I tried to find
that in the memorandum, but I could not. Similary the frequency
returned will add the pps_freq. If I want to know the PLL frequency,
will I have to subtract ppsfreq manually?
Ulrich