From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 04 Feb 1998 22:31:56 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: NT as a local time server?
X-Keywords: adjustment [-/+]
Saint Standard of the Deviations wrote:
>
> Hi,
>
> I'd like to sync the clock on the linux box in my home to the clock in
> my WinNT box.. I downloaded the xntp software but am unsure of how to
> configure it for my setup. Since I don't have full-time internet
> access, I sync my NT clock with a time server using Atomtime every
> week or so (it stays accurate to within a couple of seconds per week
> which is plenty for me). Now I'd like to be able to keep my Linux
> clock accurate via the NT box.
NT makes for a bad NTP platform, due to very inaccurate timestamps, you
would be _much_ better off using the Linux box as the master and slave
NT to it!
OTOH, if accuracy of a couple of seconds/week is fine, you can do this
easily by hand with a couple of calls to a reference and a
hand-calculated adjustment to your local clock.
Good luck!
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: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 18 Feb 1998 09:53:03 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp support for sntp
X-Keywords: Mills [-/+] SNTP [-/+]
In article <34EA9070.11E4@saix.net>, Paul Gamble <paul@saix.net> wrote:
>Does anyone know if xntp supports the sntp protocol?
>Advise gratefully accepted ...
There isn't really a SNTP protocol as such (nor a NTP one, for that
matter). The NTP RFCs are descriptions of how to build programs, and
the protocol as such is described more-or-less incidentally. This
causes quite a lot of trouble :-(
To a first approximation, SNTP is a subset of full NTP (there are some
critical differences, but David Mills regards them as errors, and xntp
actually follows the SNTP rules in some places!) So, yes, xntp supports
the SNTP 'protocol'.
HOWEVER, many of the less clear assumptions of NTP and xntp boil down
to the fact that they are assuming an xntp-compatible server. So use a
SNTP client with xntp, by all means, but DON'T serve xntp from any SNTP
server - not even one run from a radio clock, unless you REALLY know
what you are doing.
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: moshier@mediaone.net () [-/+]
Date: 17 Feb 1998 21:37:04 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Bartram's bug fix
X-Keywords: bug [-/+] prefer [-/+]
Ulrich Windl (wiu09524@rrzc4) wrote:
>> I did reproduce a "local-clock-prefer" bug that Bruce Bartram
>> <bwb@etl.noaa.gov> warned about. After the local clock has been
>> forced to a wrong frequency, NTP declares LOCAL(0) insane,
>> synchronizes on one of the other clocks, and then shows a nonzero
>> phase and loop offset. After the local clock returns to normal, NTP
>> picks it again and the phase goes to zero; but the external clocks
>> still show the offset. After a while NTP again declares LOCAL insane,
>> though it is not any more. These last two states alternate,
>> apparently without ever converging to anything.
>
>If it really exists, it must be a rare but quite old one. I can
>remember something similar with a local reference clock and some
>remote servers. The remote servers were bad. xntpd sync'ed to the
>refclock, did a time step, then synced to the externel server, did a
>time step back, and similar...
Yes, the described manifestation really exists. I can reproduce the
effect at will, by abruptly setting the local clock to a wrong frequency.
From: igorl@uiuc.edu (Igor S. Livshits)
Date: Thu, 19 Feb 1998 21:57:35 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: OT native NTP client for Macintosh
In article <6cil7n$6b3$12@nntp.Stanford.EDU>, jonathan@DSG.Stanford.EDU wrote:
>In article <01bd3d8d$bf9c0c40$ce2e63c3@monolake>, "Gilgongo"
<gilgongo@phreak.co.uk> writes:
>|> You could try Vremya (it has a PPC version). We're using it fine here.
Yes, there is a PPC version, but it is not OT savvy.
Cheers, igor
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 10 Feb 1998 22:44:44 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] NTP on NT (Was: Re: To Peer or not to Peer)
X-Keywords: resolution [-/+]
Doug Hogarth wrote:
>
> Although you will typically find the 10.0144ms resolution, be aware that
> such typical value will be different on other WinNT platforms. For example
> on multi-processor Intels it will typically be ~15.625ms, on DEC Alpha it
> will typically be around 7.8125ms, etc.
>
> If you ever implement the "interpolation" routine, be sure to fully test it
> on multi-processor systems (I can't remember whether the performance counter
> is per-processor or system-wide).
OK, that is good advice!
I did suggest that the interpolated timings should always be verified
against the (hopefully measured directly) time steps, to make sure that
an interpolated time would always be bracketed by the current and next
SystemTime tick.
I do happen to know that NT uses the RDTSC opcode, if supported, for the
performance timer, but only on multi-cpu machines.
This might be another good reason to install the multi-cpu version even
on a single-cpu machine which you don't intend to upgrade! :-)
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: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 23 Feb 1998 18:33:04 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch. lost and scheduler problems? [-/+]
Are you doing ntpdate before you start up xntpd?
ntpdate will step (or slew) the clock to be "close" to the server, so
that xntpd will not have to step the clock once it achieves sync with
the server.
Rick
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Wed, 11 Feb 1998 13:30:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SCO clock ticks vanish !! [-/+]
X-Keywords: SCO [-/+]
In <34E16A92.F053419A@hol.fr> lfialaix <lufia@hol.fr> writes:
> Has anybody ever seen clock ticks evaporation ?
Sure.
> We use a COMPAQ Deskpro PC under SCO OpenServer 5.
>
> We run a program with an inifinite loop in which no sleep and no wait
> but gettimeofday calls to detect the freshest second increment. On a new
> second detection, a pulse is generated on modem signal of one of the
> eight ports. That pulse is sent to a Stanford Counter SR620 triggered on
> its internal oscillator.
>
> The result is that SCO clock time drifts with an amazing behaviour :
> about each eight minutes, three ticks of 10 ms are lost !!!!
SCO OS5's kernel has no notion at all of the duration of a tick. It justs
adds up ticks and after 100 ticks a second has gone by. In its default
config the software clock is synced to the hardware clock and adjustments
are made by putting more or less ticks in one second. You can disable this
behavior by changing the value of track_rtc in /etc/conf/pack.d/kernel/space.c
to '0'.
--
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: "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net> [-/+]
Date: Wed, 11 Feb 1998 11:00:12 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch. lost and scheduler problems? [-/+]
X-Keywords: precision [-/+] reset [-/+] sched_setscheduler [-/+] synchronized [-/+]
On Tue, 10 Feb 1998, Ingvar Keskitalo wrote:
> Hi,
>
> 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
> 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
It looks as if you have just started up ntp. It synchronized to N.N.N.N
at 8:45. NTP then discovered that the clock was off by more than it can
handle and thus did a time-reset on your machine in order to get it to
approximately the correct time. At that point, it also loses
synchronization, so it tries to synchronize again. This succeeded at
9:17. I see this behavior all the time when I first switch on a machine,
after that, the machine just synchronizes and stays synchronized.
Henk
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal@ripe.net
RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk
Singel 258 Phone: +31.20.535-4414, Fax -4445
1016 AB Amsterdam Home: +31.20.6651962
The Netherlands Pager: +6.57626855
------------------------------------------------------------------------------
%DCL-E-NOCFFE, unable to locate coffee - keyboard input suspended.
From: Ruediger Eckhard <Ruediger.Eckhard@oen.siemens.de> [-/+]
Date: Wed, 11 Feb 1998 12:20:00 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synch. lost and scheduler problems? [-/+]
This is a multi-part message in MIME format.
--------------EA76C50EF2211599F5C84496
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: bug [-/+] configuration [-/+] cpu_tick_freq [-/+] nsec_per_tick [-/+] SCO [-/+] stability [-/+]
James Carlson wrote:
> Ingvar Keskitalo <Ingvar.Keskitalo@eiscathq.irf.se> writes:
> > Why is this, is something wrong with my configuration?
> > Something not included at compile time?
> >
> > Also, the drift on the Ultra 1 machines look much worse than on for
> > example a SUN SPARCstation 4 which sounds strange for me.
>
> I can't get my Ultra 2 running Solaris 2.6 to sync up at all -- the
> kernel wobbles time by as much as a second every few minutes, and
> xntpd declares all the servers to be "insane." (Even though its own
> sanity is at best questionable. When in a glass house ...)
>
> Yes, I turned off the todr flag. No help.
Did you try to set nsec_per_tick on your Solaris 2.6? It looks like SUN did
not correct the bug from 2.5 in 2.6. That's sad. But maybe there is another
explanation.I can show you what worked for me on a Ultra 1-170 under
Solaris 2.5.1:
There is an unofficial patch from SUN, posted a year ago on this news
group.
Basically you have to patch the cpu_tick_freq kernel variable to the real
frequency as shown in the attachment. The question is how to figure out the
frequency, if xntp can't synchronise :-(
The bad side is, that this patch helped to bring down the drift from 260 to
-39 on my machine, but not better.
My machines' real frequency is 166965574. If I patch to this frequency, I
got a ppm of -39. I increased the frequency and detected, that the ppm
value found by xntp jumps between patched values of 166965595 and 166965600
from -39 to +45. So there is a huge granularity involved. But at least it
is possible to bring the drift into an area that xntp can deal with.
Maybe some day somebody can write some cookbook for adjusting the clock
frequency on the different machine types. I regard this to be the first
step to set up a ntp network. A small ppm value is one of the first steps
to ensure stability if the primary source goes away for some reason, isn't
it?
I have now set up a network consisting of linux, Solaris 2.3 and 2.5.1 as
well as SCO 3.2v5.0.4. Solaris 5.3 is ok at 1 ppm, Linux is at 16, but
Solaris 5.5.1 has a drift of -39 ppm and the SCO machines of -70.
Rüdiger
--
Ruediger Eckhard Siemens AG, OeN BN AP 22
Tel.: +49 89 722 34197 Fax: +49 89 722 27431
Email: Ruediger.Eckhard@oen.siemens.de
--------------EA76C50EF2211599F5C84496
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: cpu_tick_freq [-/+]
#!/bin/ksh
#set -x
#
# File: patchfreq
# Author: Bryan Cantrill (bmc@eng.sun.com), Solaris Performance
# Modified: Sat Apr 26 04:00:59 PDT 1997
#
# This is a little script to patch a 5.5 or 5.5.1 kernel to get around
# the cpu_tick_freq inaccuracy. Before running this script, one must
# know the true frequency of one's CPU; this can be derived by NTP,
# or by observing the clock relative to the time-of-day chip over a
# long period of time (the TOD will pull system time when it drifts
# by more than two seconds).
#
# Patching a kernel can render a machine unbootable; do not run this
# script unless you are prepared to accept that possibility. It
# is advisable to have a backout path (e.g. net booting, an alternate
# boot disk, an installation CD) should your machine fail to boot.
#
# This is not a product of Sun Microsystems, and is provided "as is",
# without warranty of any kind expressed or implied including, but not
# limited to, the suitability of this script for any purpose.
#
if [ $# -eq 0 ]; then
echo "Usage: $0 cpu_tick_freq [ alternate_kernel ]"
exit 1
fi
cpu_tick_freq=$1
kernel=/platform/sun4u/kernel/unix
if [ $# -eq 2 ]; then
kernel=$2
fi
if [ ! -w $kernel ]; then
echo "$0: Cannot open $kernel for writing."
exit 1
fi
arch=`echo utsname+404?s | adb $kernel | cut -d: -f2`
if [ ! $arch = "sun4u" ]; then
echo "Patch only applies to sun4u"
exit 1
fi
rel=`echo utsname+202?s | adb $kernel | cut -d: -f2`
if [ ! $rel = "5.5" ] && [ ! $rel = "5.5.1" ]; then
echo "Patch only applies to 5.5 or 5.5.1..."
exit 1
fi
nop="1000000" # nop
store_mask="ffffe000" # mask out low 13 bits
store="da256000" # st %o5, [%l5 + offset]
instr=`echo setcpudelay+34?X | adb $kernel | cut -d: -f 2 | nawk '{ print $1 }'`
if [ $instr = $nop ]; then
echo "Instruction already patched..."
else
let masked="(16#$store_mask & 16#$instr) - 16#$store"
if [ $masked -ne 0 ]; then
echo "Couldn't find instruction to patch; aborting."
exit 1
fi
if ! echo setcpudelay+34?W $nop | adb -w $kernel 1> /dev/null
then
echo "adb returned an unexpected error; aborting."
fi
fi
echo "Patching cpu_tick_freq to $cpu_tick_freq..."
if ! echo cpu_tick_freq?W 0t$cpu_tick_freq | adb -w $kernel 1> /dev/null; then
echo "adb returned an unexpected error; aborting."
exit 1
fi
echo "$kernel successfully patched."
exit 0
--------------EA76C50EF2211599F5C84496
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: cpu_tick_freq [-/+]
#!/usr/local/bin/tcsh
echo Tick-Frequenz im Kernel ist:
adb /platform/sun4u/kernel/unix << ENDE |& tail -2 | head -1
cpu_tick_freq?D
ENDE
--------------EA76C50EF2211599F5C84496--
From: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]
Date: 24 Feb 1998 17:10:51 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on NT (excuse the pun) [-/+]
X-Keywords: ntptime [-/+]
There are a slew of NTP implementations that work on NT which you can find
pointers to on the NTP home page. I, naturally, am partial to the one I
wrote :-).
My version: http://home.att.net/~Tom.Horsley/ntptime.html
NTP home page: http://www.eecis.udel.edu/~ntp/
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+
From: moshier@mediaone.net () [-/+]
Date: 12 Feb 1998 13:18:06 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local ATOM? [-/+]
X-Keywords: rubidium [-/+]
: I'll leave the software troubleshooting to Ulrich Windl, but there are a
: couple of other points to ponder:
After another experiment it looks like there is no software problem,
nor hardware problem either. The big fluctuations are coming from
the internet delays.
The experiment was to ignore the outside net and point the stabilized
computer at a normal, unmodified pc on the local ethernet. The normal
machine was free-running on its local clock. Now the fluctuations in
time and frequency dropped by an order of magnitude, over the course
of a day, compared to the internet connection.
I think this shows that the rubidium clock should pay attention to
the outside net, if at all, only on a very long time constant. Even
the non-stable crystal clock would have been better off (by a factor
of ten!) to ignore the short term network fluctuations.
From: moshier@mediaone.net () [-/+]
Date: 25 Feb 1998 15:42:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Local ATOM? [-/+]
X-Keywords: delay [-/+] precision [-/+] rubidium [-/+]
For the past week, the rubidium PC has remained untouched, looking out
on the net at four nearby stratum 2 clocks. The clock readings all
show a noisy trend of more than -1 msec per day, which would indicate
the rubidium is running fast by 10^-8 or so. That is much bigger than
it ought to be, but at present I don't think I have any independent way to
calibrate the rate at such a high precision.
The question is, can a drift of 10 msec in a week come from very
low frequency wandering in the network delay skew, or from a bug/feature in
ntp? I don't have enough experience with either to guess where to start
looking.
From: moshier@mediaone.net () [-/+]
Date: 26 Feb 1998 13:18:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local ATOM? [-/+]
X-Keywords: Efratom rubidium [-/+]
Robin Kimberley (robk@oldtimer.win-uk.net) wrote:
:
: Could be your Rubidium has a problem - is out of lock?
: what Rubidium do you have in there??
The rubidium is an Efratom. It's surplus, unused when purchased,
been running aboug 4 months. Since you asked, I made some tests and
found it seems OK. I do have a pretty good quartz standard available,
with 10^-10 characteristics to check against. Its true frequency is
unknown too, but it shows there hasn't been much drift lately.
Picking "ntp bug/features" as the most likely source of troubles,
I tried to trace what happens to the frequency offset value read out of
ntp.drift. The search lead to this place in the linux kernel. It
looks like it is multiplying my 15.237863042 ppm input value by
128.125/128, thereby increasing the clock rate by by about 10^-8
compared to what I wanted it to be. I am not totally sure this is
actually the clock, though! Could somebody familiar with this please
comment?
usr/src/linux/kernel/sched.c (line 1083):
ltemp = time_freq + pps_freq;
if (ltemp < 0)
time_adj -= -ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
else
time_adj += ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
#if HZ == 100
/* Compensate for (HZ==100) != (1 << SHIFT_HZ).
* Add 25% and 3.125% to get 128.125; => only 0.125% error (p. 14)
*/
if (time_adj < 0)
time_adj -= (-time_adj >> 2) + (-time_adj >> 5);
else
time_adj += (time_adj >> 2) + (time_adj >> 5);
#endif
From: ktk@ktk.bidmc.harvard.edu (Kristofer T. Karas) [-/+]
Date: 25 Feb 1998 20:01:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Peer Syncing. [-/+]
X-Keywords: broadcast [-/+] fudge [-/+] peer [-/+]
Joshua Gustin <joshua.gustin@faa.dot.gov> wrote:
>The Peer broadcasting to the Subnet'ed computers is working well. But,
>the peers do not seem to Sync up together.
You didn't mention which peer, if any, is acting as a local reference.
If none are, this would explain your results.
In general, (with a lack of an external accurate time source), you
want each system to reference not only its peers, but also its local
clock. That is, you want:
server 127.127.1.1 # Use our local clock
fudge 127.127.1.1 stratum 10 # Don't confuse our clock with real time.
in the ntp.conf for one of your machines that you believe has a pretty
stable local clock (doesn't tend to drift much), which we will call
the primary. Then, on the other machines (the secondaries), you have:
server 127.127.1.1
fudge 127.127.1.1 stratum 12
server <primary>
If the primary server (at stratum 10) is available, the secondaries
will choose it (stratum 10+1 = 11) preferentially over their own local
clocks (stratum 12), and you will achieve synchronization. If the
primary goes down, the secondaries will sync to themselves (and thus
continue to broadcast some reasonable time) until the primary comes
back up.
--
Kristofer Karas * Senior systems engineer/SysAdmin
AMA/CCS DoD RF900RR HawkGT !car * BI Deaconess Medical Center, Boston
"Build a system that even a fool can use, * http://ktk.bidmc.harvard.edu/~ktk/
and only a fool will want to use it." * Will design LISP machines for food
From: moshier@mediaone.net () [-/+]
Date: 13 Feb 1998 04:32:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local ATOM? [-/+]
X-Keywords: clockstats [-/+] configuration [-/+] delay [-/+] driftfile [-/+] filegen [-/+] fudge [-/+] logconfig [-/+] peerstats [-/+] prefer [-/+] rubidium [-/+]
On Thu, 12 Feb 1998, Tom Van Baak wrote:
> Here are two (or four) solutions to your problem:
>
> * One is to enhance the Linux clock handler to keep
> track not only of the count of clock ticks but also
> the net time error accumulated with each tick and
> to periodically compensate for this error.
...
NTP has this capability, and on Linux the amount added to the time
of day on each clock tick can be adjusted in very fine increments.
In the current (third) experiment, NTP is initialized to apply the
extra 15 ppm offset via the startup file --
/etc/ntp.drift:
15.237863042
Then the configuration file makes the free-running rubidium local
clock be the reference standard --
/etc/ntp.conf:
server x.y.z.w # remote stratum 2 clock under investigation
server q.r.s.t # another remote clock
server 127.127.1.0 prefer # local rubidium clock will be the sync source
fudge 127.127.1.0 stratum 2 # give it a stratum as good as clocks under test
driftfile /etc/ntp.drift
# enable statistics logging
statsdir /usr/local/log
logconfig =syncall +sysall +peerall
filegen clockstats type day
filegen peerstats type day
statistics peerstats
statistics clockstats
With this setup the statistics log files give the time of day offset
of the remote clocks compared to the free-running rubidium.
After only a few hours some sobering pictures developed. One stratum
2 clock on the internet showed small time fluctuations of about a
millisecond over the course of the day. Another stratum 2 clock at
almost exactly the same propagation delay distance had wild (by
comparison) fluctuations of tens of milliseconds. For some reason NTP
had liked the gyrating one as a sync source, but now I would delete it
from the configuration.
From: moshier@mediaone.net () [-/+]
Date: 27 Feb 1998 15:04:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local ATOM? [-/+]
Ulrich Windl (wiu09524@rrzc4) wrote:
: This value is updated only once per second
: to save CPU cycles, but the quantity is added every clock tick (at
: 100HZ).
I take that as a yes. So I will use a startup drift value that has been
multiplied by 128/128.125 to compensate for the imprecise arithmetic.
After a few days or weeks we'll know if there are any other inconsistencies.
I already see that there is one in the linux program -- ntp is truncating the
drift file value at 1/32768 of a part per million.
Probably what I should do then is add some more counters and gates to the
electronic circuit to make the computer input frequency correspond
to a drift file value of exactly 0.0.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 27 Feb 1998 12:52:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Peer Syncing. [-/+]
X-Keywords: broadcast [-/+] driftfile [-/+] fudge [-/+] peer [-/+]
In article <6d1tb5$33a@mufasa.harvard.edu> ktk@ktk.bidmc.harvard.edu (Kristofer T. Karas) writes:
> Joshua Gustin <joshua.gustin@faa.dot.gov> wrote:
> >The Peer broadcasting to the Subnet'ed computers is working well. But,
> >the peers do not seem to Sync up together.
>
> You didn't mention which peer, if any, is acting as a local reference.
> If none are, this would explain your results.
>
> In general, (with a lack of an external accurate time source), you
> want each system to reference not only its peers, but also its local
> clock. That is, you want:
>
> server 127.127.1.1 # Use our local clock
> fudge 127.127.1.1 stratum 10 # Don't confuse our clock with real time.
Be careful: The original version was 3.4, but in extension software
from December is 3.5f. Both use slightly different syntax.
>
> in the ntp.conf for one of your machines that you believe has a pretty
> stable local clock (doesn't tend to drift much), which we will call
> the primary. Then, on the other machines (the secondaries), you have:
>
> server 127.127.1.1
> fudge 127.127.1.1 stratum 12
> server <primary>
You should also add a driftfile to each server , but HP has supplied a
rather niche template in /usr/newconfig/etc/ntp.conf...
>
> If the primary server (at stratum 10) is available, the secondaries
> will choose it (stratum 10+1 = 11) preferentially over their own local
> clocks (stratum 12), and you will achieve synchronization. If the
> primary goes down, the secondaries will sync to themselves (and thus
> continue to broadcast some reasonable time) until the primary comes
> back up.
> --
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 26 Feb 1998 15:11:51 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: PLL control bug in 3-5.9x? [-/+]
X-Keywords: dispersion [-/+] HP-UX [-/+] implementation [-/+] stability [-/+] synchronized [-/+]
I have complained several times that recent xntpd has a possible
terrible initial behaviour after a restart:
I had a host with an initial error of about 50ms when xntpd (all
3-5.92) synchronized. Instead of locking the frequency and waiting for
some samples (as older versions did), the frequency shot up high, and
it took 4.5 hours to compensate that initial overshot. In another 20
hours the freueny had found its final value.
The measurements took place on a LAN with 5 servers on the same
segment, including a stratum-1 server (with terrible dispersion, but
with good long-time stability). I have made a GNUplot available (7kB
in compressed PostScript) on
ftp://pcphy4.physik.uni-regensburg.de/pub/wiu09524/NTP/xntp3-5.92.ps.gz
The machine was a HP 9000/K420 running HP-UX 10.20 with recent
patches, but without a kernel clock implementation.
On Linux 2.0.x (with kernel implementation) I had noticed that
STA_FREQHOLD is not set when dispersion goes below 1.0 (status change
0x89), but about one sample later. Older versions had locked the
frequency until dispersion as below something like 0.128 or
reachability 0177.
If you run ntpdate immediately before launching xntpd you won't see
this problem (as the offset is too small then).
BTW: can't ntpdate be integrated into xntpd to make an automatic quick
time step configurable? Most code should be there already.
Please someone, look into this issue.
Ulrich
From: "Jorg Heijnis" <j.heijnis@cable.a2000.nl> [-/+]
Date: Thu, 26 Feb 1998 23:20:51 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: problem compiling xntp3-5.91-export
X-Keywords: restrict [-/+]
>ntp_config.c:1133: parse error before `restrict'
This is a problem with the compiles shipped with slackware 3.4 here are two
sollutions to this problem that I tried and they work.
1 - Edit the header files that contain restrict and insert a
#define restrict restrict2
in the beginning of the file.
2 - Download and install a new version of the GCC compiler.
Greetz,
Jorg.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 27 Feb 1998 12:58:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local ATOM? [-/+]
In article <6d3q3i$f89$1@ndnws01.ne.highway1.com> moshier@mediaone.net () writes:
> actually the clock, though! Could somebody familiar with this please
> comment?
>
>
> usr/src/linux/kernel/sched.c (line 1083):
>
> ltemp = time_freq + pps_freq;
> if (ltemp < 0)
> time_adj -= -ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
> else
> time_adj += ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
>
All multiplies and divides are approximated with shifts. So you can't
have a value of 100. The code below tries to be close. time_adj is the
amount of time correction. This value is updated only once per second
to save CPU cycles, but the quantity is added every clock tick (at
100HZ).
> #if HZ == 100
> /* Compensate for (HZ==100) != (1 << SHIFT_HZ).
> * Add 25% and 3.125% to get 128.125; => only 0.125% error (p. 14)
> */
> if (time_adj < 0)
> time_adj -= (-time_adj >> 2) + (-time_adj >> 5);
> else
> time_adj += (time_adj >> 2) + (time_adj >> 5);
> #endif
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 13 Feb 1998 14:45:17 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problems with NTP3.5.91 on HPUX10
X-Keywords: auth [-/+] authentication [-/+] configuration [-/+] HP-UX [-/+] logconfig [-/+] precision [-/+] restrict [-/+]
In article <569@oldtimer.win-uk.net> robk@oldtimer.win-uk.net (Robin Kimberley) writes:
> Steffen,
>
> I believe that you will need a patch from HP to allow xntp to run on
> HP-UX10.
Robin,
please do quote only relevant parts of the message, especially when
there are log files included. Despite of that I think you are wrong.
Steffen,
There were a number of changes between 3.5f and the latest versions
having to do with authentication, default key type, etc. I'm running
3.5.92 and 3.5.90.2 on HP-UX 10.10 here and we have some other
versions on Solaris 2.5 and Linux 2.0.
>
>
> In article <887296275.1212350467@dejanews.com>, steffenp@iplbath.com
> (steffenp@iplbath.com) writes: >Hi,
[...]
> >The logfile for my NTP looks like:
> >---------------------------------------------------------------------- 11
> >Feb 11:46:05 xntpd[26355]: logging to file /steffen/expr_9/logfile 11 Feb
> >11:46:05 xntpd[26355]: xntpd 3-5.91 Tue Feb 10 16:37:03 GMT 1998 (1) 11
> >Feb 11:46:05 xntpd[26355]: signal_no_reset: signal 1 had flags 4 11 Feb
> >11:46:05 xntpd[26355]: signal_no_reset: signal 3 had flags 4 11 Feb
> >11:46:05 xntpd[26355]: signal_no_reset: signal 10 had flags 4 11 Feb
> >11:46:05 xntpd[26355]: signal_no_reset: signal 16 had flags 4 11 Feb
> >11:46:05 xntpd[26355]: signal_no_reset: signal 13 had flags 4 11 Feb
> >11:46:05 xntpd[26355]: tickadj = 5, tick = 10000, tvu_maxslew = 495, est.
> > hz = 100 11 Feb 11:46:05 xntpd[26355]: precision = 23 usec 11 Feb
> >11:46:05 xntpd[26355]: read drift of -39.827 0 from /etc/ntp.drift
Please try to avoid "auto-fill-mode" when posting log files. Despite
of that you might have noticed that the "logconfig" has a quite silent
default now. I feel quite tired when saying ``try to add "logconfig
=all" at the top of your configuration file.''.
> >
> >----------------------------------------------------------------------
> >
> >The debug output looks like:
> >----------------------------------------------------------------------
> >tick = 10000, tickadj = 5, hz = 100 kernel vars: tickadj = 5, tick =
> >10000 adj_precision = 5, tvu_maxslew = 495, tsf_maxslew = 0.002070b9
> >create_sockets(123) bind() fd 3, family 2, port 123, addr 00000000,
(The filled logfile is terrible to read)
[...]
> >event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event,
> >event_unspec' (0xc010) sendpkt(fd=3 192.168.200.51, 0.0.0.0, ttl=-8, 48)
> >transmit to 192.168.200.51 sendpkt(fd=3 192.168.200.51, 0.0.0.0, ttl=-8,
> >48) transmit to 192.168.200.51 ... /* DOES NOT RECEIVE ANYTHING */
"ntpq -c as"? What about auth? What about restrict?
> >----------------------------------------------------------------------
> >
> >The logfile for the working NTP (3.5f) looks like:
> >---------------------------------------------------------------------- 11
[...]
Regards,
Ulrich
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 25 Feb 1998 09:02:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on NT (excuse the pun) [-/+]
X-Keywords: resolution [-/+] RFC [-/+]
The main problem with NT is that the clock's resolution is still 10ms,
while new LAN cards take about 1.5ms for turn-around. So you can send
6 packets at the same time with NT ;-)
Seriously: That crude clock makes a crude reference, and there are no
local reference clocks supported yet. If you must use a PC, try some
free UNIX like Linux.
--
--- &disclaimer; ---
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de+no-spam>
Klinikum der Universitaet Regensburg, Rechenzentrum DV-med
Franz-Josef-Strauss-Allee 11\\D-93042 Regensburg, Germany
%%[PGP 2.3a/2.6ui Public Key 0x[e8]43660d on at least one key server]%%
%1024/E843660D 1994/03/26 = CF D7 43 A1 5A 49 14 25 7C 04 A0 6E 4C 3A AC 6D
Stop the SPAM, read the Nettiquette (RFC 1855)!
From: Poul-Henning Kamp <phk@freebsd.org>
Date: Sun, 01 Mar 1998 22:46:48 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Local ATOM? [-/+]
X-Keywords: delay [-/+] FreeBSD [-/+] precision [-/+] rubidium [-/+]
moshier@mediaone.net wrote:
> For the past week, the rubidium PC has remained untouched, looking out
> on the net at four nearby stratum 2 clocks. The clock readings all
> show a noisy trend of more than -1 msec per day, which would indicate
> the rubidium is running fast by 10^-8 or so. That is much bigger than
> it ought to be, but at present I don't think I have any independent way to
> calibrate the rate at such a high precision.
>
> The question is, can a drift of 10 msec in a week come from very
> low frequency wandering in the network delay skew, or from a bug/feature in
> ntp? I don't have enough experience with either to guess where to start
> looking.
Hi!
You may want to look at the code I just plugged into FreeBSD a couple of
weeks ago. It replaces the traditional stepwise time keeping with for all
practical puposes continuous timescale. This would certainly solve your
problem.
Poul-Henning