From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Fri, 19 Dec 1997 22:38:23 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NT server as Time server [-/+]
X-Keywords: clockstats [-/+] driftfile [-/+] filegen [-/+] firewall [-/+] loopstats [-/+] peerstats [-/+] poll [-/+]
Jill K. Smith wrote:
>
> I have the installshield version, but all it puts in the conf file is the
> server addresses (of the US Naval Observatory) where I am pointing to for
> time. I wanted to put in some kind of parameter to tell it how often to poll
> the time from the Observatory. Or my question is, does the time stepping and
If you only want to poll a couple of times per day, then you should use
ntpdate as a regularly scheduled application.
> time drift determine when it polls? Do you just use the defaults for the
> tickadj and step parameters??
NTP is very good at adjusting itself, normally it will drop down from a
starting value of one poll per 64 seconds to just once per 1024 secs,
i.e. a couple of packets per server every 17 minutes.
>
> Does anyone have a sample of their ntp.conf that I could get a copy of?
Sure, here's my home NT setup:
This is just the file as generated by InstallShield, (with the ip
addresses hidden) with one extra server added.
All three servers are on our internal net, where the first two have been
setup to to able to pass the firewall to sync to 5-6 external stratum 1
& 2 clocks, while the last is my TymServe NTS-100, which also talks to
the first two unix machines.
#
# File: ntp.conf
# Purpose: give the NTP Service its startup parameters and
# list of startup files.
#
#
#
# Miscellaneous stuff
#
driftfile %windir%\ntp.drift # path for drift file
statsdir c:\var\ntp\stats\ # directory for statistics files
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
# Need to set up time sources...
# server ip-address
#
#
server xxx.xxx.216.55
server xxx.xxx.216.11
server ntp0.hda.hydro.com
#
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: jeff@ollie.clive.ia.us (Jeffrey C. Ollie)
Date: Thu, 18 Dec 1997 23:20:49 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NT server as Time server [-/+]
X-Keywords: configuration [-/+] DTS Novell [-/+] Tardis [-/+]
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 18 Dec 1997 22:40:47 +0100, Terje Mathisen <Terje.Mathisen@hda.hydro.com> wrote:
>Ulrich Windl wrote:
>>
>> In article <349835EB.7585FDFB@epamail.epa.gov> "Jill K. Smith" <smith.jill@epamail.epa.gov> writes:
>>
>> > Vesna, I am implementing MS Time Service that is included with the NT Resource
>>
>> "MS Time Service" spendid idea! Now that also Novell has a time
>> service, it is really necessary to have "MS time service". I guess
>> it's about 95% stolen from NTP or DTS, and 5% added for
>> incompatibility. Why not implement a non-Bill-Gates standard?
>
>I agree totally re. the MS Time Service: The only possible excuse for
>using this instead of the free ntp port, would be because MSTS used much
>less resources (RAM, cpu should be nearly equal, i.e. close to zero).
The person that wrote Tardis (sorry can't remember the name) has a new
program called K9. K9 (on NT) is a service that listens for NTP
broadcasts and syncs the local clock. It's very tiny and requires no
configuration. I can't imagine the possibility of anything being
easier. It's relatively inexpensive too.
>OTOH, I haven't yet been able to persuade TPTB that NTP would be a
>_really_ good idea here as well, they've only promized to sync the
>"master" MSTS server(s) with NTP.
>:-(
It amazes me at how easily some people buy into the MS marketing hype.
Fortunately my boss is fairly immune to anyone's hype. Unfortunately
we're still stuck with MS products.
[A copy of the headers and the PGP signature follow.]
~Date: Thu, 18 Dec 1997 23:20:49 -0600
~Newsgroups: comp.protocols.time.ntp
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
Organization: netINS, Des Moines, IA, USA
~References: <01bd054d$343d5fa0$64e698c2@VesnaCiglar.uprava.ina.hr> <349835EB.7585FDFB@epamail.epa.gov> <WIU09524.97Dec18104810@rrzc4> <3499985F.62F6@hda.hydro.com>
~Subject: Re: [++] Re: NT server as Time server
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.
iQCVAwUBNJoENZwkOQz8sbZFAQHumQP/fZ1ZbaF/+PJm7j2sQcToiw73KATxSSmf
/OFs/eiA+F2Ux7a6vkZbUOYON+jGnG2FivBv8sUf9bBc6j7RjrJHmhHnVIUxlWg+
e/vxOFSAC/L1ukmSFyBX0Sh2hB7cNMonl7RNInQ92KDya/+uovJ0Vh9c/RmXXUG6
XUzCOh3TPwM=
=8PaN
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie | Should Work Now (TM)
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Wed, 17 Dec 1997 22:32:11 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: ]++] Re: Question, how to read time with high resolution/accuracy? [-/+]
X-Keywords: HP-UX [-/+] PPS [-/+] reset [-/+] resolution [-/+]
Ulrich Windl wrote:
>
> In article <678hiv$3mu@smash.gatech.edu> "Andy Register" <andy.register@gtri.gatech.edu> writes:
>
> > Dear NTP Experts,
> >
> > I am trying to figure out exactly how you go about reading the time once you
> > set up a stratum 1 NTP machine.
> >
> > Lets say you have a GPS clock connected to the workstation via a serial
> > connection. (Almost all the clocks fix the rate at 9600 baud.) A 1-PPS
> > pulse is available and the serial timecode is also available.
> >
> > The most obvious answer is to use the GetTimeOfDay call to return the time.
> > This would be fine except it is typically accurate to something like 1/100th
> > sec (10 mS). So there appears to be only two options: read the timer
> > hardware or read the serial timecode. Are there any other options with this
> > kind of setup?
> >
> > <Read the Hardware Timer>
> > How easy is it in general to read the timer hardware on various Unix
> > machines? Is there a general solution or will this be platform dependent?
>
> Most reasonable operating systems include an interpolation of clock
> interrupts when reading timestamps (gettimeofday). HP-UX does, and
> Linux on i386 does. Solaris also does... Windows/NT 3.51 does not...
From all the tests I've done, it seems that about 10ms is the resolution
of the clock in NT, assuming you're using the FTime calls. Now, this API
is capable of returning timestamps with 100ns resolution, but NT doesn't
even seem to try to interpolate.
If I switch to the Multimedia calls instead, then I can get 1 ms
resolution, if I wrap all timeGetTime() calls in a timeBeginPeriod(1),
timeEndPeriod(1) pair, but I haven't found a way to do this on absolute
time stamps (timeGetTime() returns milliseconds since reset, and wraps
around after 2^32 ms).
The best alternative I've found for NTP would be to use the performance
timer (QueryPerformanceTimer()), which normally returns timings with 0.8
microsec resolution, but then we're back at the problem of relating
these times to clock time.
By raising the thread priority to near realtime, it might be possible to
busy-wait until the clock is updated, and note the performace timer at
that moment.
At this point, all NTP client requests could be timestamped relative to
this base time, this would probably work as long as the drift between
clock time and the performace timer would stay much smaller than the
basic tick interval.
The _real_ solution would of course be an OS driver which fixed the
GetSystemTimeXXX calls, by interpolation from the last hardware timer
tick.
Would this even be possible, or would it require an OS patch?
Terje
PS. As long as NTP is running on a Pentium or similar/better cpu, the
internal cpu timestamp is the best way to go, since RDTSC returns a
64-bit clock cycle count, and it is useable from all protection levels.
--
- <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: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 18 Dec 1997 00:02:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Stratum-1 Server [-/+]
X-Keywords: Arbiter [-/+] arbiter [-/+] delay [-/+] documentation [-/+] FreeBSD [-/+] fudge [-/+] implementation [-/+] PPS [-/+] precision [-/+]
In article <882293587.6320.0.nnrp-07.c1c3e001@news.demon.co.uk>
joew@demon.net (Joe Warren-Meeks) writes:
>Pentium PC (Any one have a guide to the loading it would be expected to
>take?) running OpenBSD 2.2 and using the Arbiter 1092 GPS clock, running 3.5f
>
>However if this isnt suitable we can use a sparc (5-10-20) with 2.5.1
>
>Does anyone have any experience running a stratum-1 with a set up like this?
>Anyone have any experience with the arbiter under BSD?
I have used the Arbiter 1092 on FreeBSD (2.2.2 IIRC) and Solaris 2.5.1
(and SunOS 4.1.4), with xntp3-5.90ish. Some comments:
You didn't say anything about what precision you want to achieve - the
1092 is spec'ed as 1 ms, which is probably more than good enough for
most people - and unless you use the PPS signal, your OS will introduce
variations that are greater than that. 1 us precison is available as an
option, but this is pointless without using PPS.
The Arbiter is an excellent choice IMO - reasonable price, good
functionality, and easy installation - including PPS without any
additional hardware. Xntp 3.5f doesn't support it at all though, I don't
know why you're considering such an old version (perhaps it's the one
that ships with OpenBSD?). Arbiter support (formally for the 1088, but
the interface is essentially identical) appeared somewhere around
xntp3-5.80; you should definitely use the latest version 3-5.91.
I don't know how much OpenBSD differs from FreeBSD these days, but on
FreeBSD: "Default" usage, i.e. only timestamps via the serial port,
entails variations of +/- 5 ms as observed by xntpd, due to the serial
I/O driver being optimized for high throughput rather than low latency.
This can be overcome, and variations pushed into the sub-ms area, with a
trivial modification of the driver (not really a modification even, just
setting a variable). PPS support is included in the standard FreeBSD
distribution, and used automagically by xntpd - however the Arbiter has
the "wrong" polarity in its PPS signal, so a trivial driver mod is
needed for this too.
Solaris 2.5.1, even on faster machines than those you consider,
introduces variations in "time stamp only" mode that are at least as big
as the abovementioned, sometimes on the order of tens of ms - for no
particular reason other than poor implementation of the serial I/O
system, I believe, and with no known "fix". There is no PPS support for
the Arbiter available on Solaris. I see no reason to recommend this over
any of the free x86-based Unices.
Even though you don't mention it (and I haven't tried it), you should
also definitely have a look at Linux with the patch package that Ulrich
Windl has produced, and posted about here occasionally.
As to load on the machine, this is totally dependant on how many clients
you intend to serve - the load from xntpd with the reference clock alone
is hardly measurable on any half-way modern hardware.
>And is there any documentation specific to setting up a stratum 1 around?
There isn't much to it as long as you don't use the PPS signal (and if
you do, it varies...) - but I believe the docs are frequently incomplete
if not downright wrong in this area. For a single Arbiter:
1. Create a symlink /dev/gps0 -> /dev/cuaa0 (or whatever the name/number
of the serial port is - make sure that it does *not* require a DCD signal)
2. Put this in ntp.conf:
server 127.127.11.0
You can also use a line like 'fudge 127.127.11.0 time1 0.0043' to
compensate for a fixed delay for the timestamps' traveling from serial
port to xntpd, but you need some way to determine the value... The rest
is basically standard stuff, i.e. not particular to stratum-1.
--Per Hedeland
per@erix.ericsson.se
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 18 Dec 1997 14:45:15 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SGI O2 and NTP Stratum 1, What should I buy? [-/+]
X-Keywords: Bancomm [-/+] PPS [-/+] resolution [-/+] SGI [-/+] synchronized [-/+] TrueTime [-/+] WWV [-/+]
>In article <67463d$pgb@smash.gatech.edu> "Andy Register" <andy.register@gtri.gatech.edu> writes:
>> Dear NTP Experts,
>>
>> I have an application where I need to collect data on two machines and time
>> tag the data so that the time-tags are synchronized to an error smaller than
>> 1 milli-second. One machine will probably be in Maryland and the other in
>> Texas. What I think I need to do is either use NTP and configure each
>> machine as a stratum 1 NTP machine I have to use SGI O2 machines, sponsor
>> requirements.
>>
>> I have read just about all the FAQs and info I can find on NTP and it
>> _appears_ that 1 milli-second may be pretty optimistic with a 1-PPS serial
>> synch method. True or Not True? If the serial sync method will support < 1
>> mS, whose GPS unit should I buy? (Of course this presumes GPS is the way to
>> go.) If a radio receiver (e.g., WWV) is just as good, I would also like
>> someone to tell me this as well.
>>
>> When operating in the serial sync mode, do you need two serial connections,
>> one for the 1-PPS signal and one to transfer the timecode?
>>
>> I have read that if you can have a bus-based timecode generator, then you
>> can sync to about 100 micro-seconds. The O2 machines have a 64-bit PCI card
>> slot. Can I put a 32-bit GPS PCI card from Datum-Bancomm or TrueTime or
>> Odetics in this 64-bit slot and expect the hardware to function? Is anyone
>> aware of a hardware/driver combination that will work with the PCI slot in
>> the SGI O2 machine? Is anyone aware of a driver that has been written to
>> support one of these cards on _any_ unix platform?
>>
Andy,
NTP will be hard-pressed to give you guaranteed sub-millisecond
accuracy. On some lightly loaded SGI O2 systems here, offsets average
less than 1 ms, but have occasional excursions to 10 ms or more.
Whatever you do, it ain't gonna be cheap! (but then, SGI O2's usually
mean money, so that's probably not a problem in your case...) The
ultimate best solution would be to ignore NTP entirely, and put a
bus-based timecode generator in each of your O2's. That should give
you micro-second resolution and, (assuming the time-base comes from
GPS with good long-term averaging to overcome the DoD's silly
"selective availability") micro-second accuracy as well. I know that
Odetics (at least, and probably others as well) make PCI cards with
GPS derived time-bases. Whether they have software for the SGI O2
machines, I can't tell. Best bet would be to call the vendors and
ask. Worst-comes-to-worst, they will probably be willing to give you
the source for an x86 PC driver, so you can roll your own for the
SGIs.
My recommendation would be to take your time-tags directly from the
card, and ignore the OS clock entirely as far as your applications
program is concerned.
Just out of curiosity, what is the application? VLBI radio-astronomy
comes to mind, but there are other possibilities.
Rick
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 22 Dec 1997 08:20:25 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What is the maximum step adjustment ??
X-Keywords: adjustment [-/+] FAQ [-/+] reset [-/+] RFC1305 [-/+]
In article <349947C8.1DC@hp.com> Nick Boorman <nick_boorman@hp.com> writes:
> Hi,
>
> Please could someone spare two minutes of their time to answer this
> question !
>
> I have been reading the RFC1305 and from it I have been unable to
> determine the maximum step adjust NTP can make it anyone time, is it
> 4 seconds (CLOCK.ADJ).
Hmm, sounds like a FAQ. In fact it is:
http://www-nw.uni-regensburg.de/~wiu09524/faq2Ears.htm#arasp
>
> In other words if my clock was 10 minutes out, would NTP reset my clock
> in one step, or several small steps, and if so what is the maximum clock
> step value.
The minimum(!) step is 128ms, the maximum step is about 900 seconds.
Differences below the minimum are slewed, differences above the
maximum cause abnormal termination of the program (something might be
very wrong). You can force the daemon to use adjtime() instead
settimeofday(), but the adjustment could take several minutes to
complete. See the FAQ for "previous time adjustment did not complete"
(keyword "adjustment" in the keyword index of the FAQ)
>
> Thanks in advance
>
> Nick Boorman
Excuse me saying RTFFAQ (read the fine FAQ), but I have indexed it ;-)
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Fri, 19 Dec 1997 22:38:23 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: NT server as Time server [-/+]
X-Keywords: clockstats [-/+] driftfile [-/+] filegen [-/+] firewall [-/+] loopstats [-/+] peerstats [-/+] poll [-/+]
Jill K. Smith wrote:
>
> I have the installshield version, but all it puts in the conf file is the
> server addresses (of the US Naval Observatory) where I am pointing to for
> time. I wanted to put in some kind of parameter to tell it how often to poll
> the time from the Observatory. Or my question is, does the time stepping and
If you only want to poll a couple of times per day, then you should use
ntpdate as a regularly scheduled application.
> time drift determine when it polls? Do you just use the defaults for the
> tickadj and step parameters??
NTP is very good at adjusting itself, normally it will drop down from a
starting value of one poll per 64 seconds to just once per 1024 secs,
i.e. a couple of packets per server every 17 minutes.
>
> Does anyone have a sample of their ntp.conf that I could get a copy of?
Sure, here's my home NT setup:
This is just the file as generated by InstallShield, (with the ip
addresses hidden) with one extra server added.
All three servers are on our internal net, where the first two have been
setup to to able to pass the firewall to sync to 5-6 external stratum 1
& 2 clocks, while the last is my TymServe NTS-100, which also talks to
the first two unix machines.
#
# File: ntp.conf
# Purpose: give the NTP Service its startup parameters and
# list of startup files.
#
#
#
# Miscellaneous stuff
#
driftfile %windir%\ntp.drift # path for drift file
statsdir c:\var\ntp\stats\ # directory for statistics files
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
# Need to set up time sources...
# server ip-address
#
#
server xxx.xxx.216.55
server xxx.xxx.216.11
server ntp0.hda.hydro.com
#
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: Russ Garber <rgarber@k4ziv.erols.com> [-/+]
Date: Wed, 17 Dec 1997 22:50:58 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Does ntp modify RTC parameters?? [-/+]
Rick Thomas wrote:
>
> >In article <34969CC1.2018@lafn.org> Art Hurst <ae799@lafn.org> writes:
>
> >> We've been running ntp on local machines for several months w/
> >> connection to internet from 7AM to 6PM. Now I need to study ways to
> >> adjust clock parameters for remote machines that don't have inet access.
>
> >> My question is-- after having run ntp for several months, has my RTC or
> >> system clock been affected such that the parameters are now different
> >> than when the systems first ran ntp?? My objective is to set up systems
> >> so that when they ship they will remain stable within a minute over one
> >> or more month's time without intervention. (I can't afford dial-up to
> >> time servers or radio clocks. Cost of the system is very tight and
> >> remote systems may be anywhere and usually 3rd world locations). The
> >> reason for my question is that I don't know if by stopping ntp service
> >> my experiments are running on a well tuned system because of prior ntp
> >> activity and the results would be tainted and different from a system
> >> out of the box.
>
Hi Art,
To my knowledge, you didn't say what operating system you are
running. And
since you said ntp and not xntpd, I suppose it could be dos or win95..
Just in
case, here is info about a shareware product called "RighTime" (from
www.RighTime.com)
that can do what you want, it handles cmos and dos clock accuracy
problems:
RighTime makes possible sustained clock accuracies on the order of tens
of milliseconds per day, easily and
automatically. There are many other problems with the PC system
clocks; RT2@PTTI.Txt is a detailed
discussion of them and how RighTime solves them.
Russ
From: Bill McGovern <wem@lucent.com> [-/+]
Date: Wed, 17 Dec 1997 17:47:13 -0600 [-/+]
Newsgroups: comp.unix.solaris,comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: configuration [-/+] dispersion [-/+] FAQ [-/+] PLL [-/+]
Dima,
Thanks for your suggestion to turn off kernel pll support at compile time. I
too was seeing high offsets and and dispersion with 3-5.91 compiled on the
Solaris 2.6 box (SPARC 5). After following your suggestion, the resultant
xntpd runs very nicely now, like the way it did under 2.5.1!
Another item for the FAQ?
Bill McGovern
Lucent Technologies
Dima Volodin wrote:
> I had equally bad experience with xntpd in 2.6 until I turned kernel PLL
> support off - it looks like 2.6 and xntpd have drastically different ideas
> about what it means. After that, the boxes I run xntpd on run rock solid
> without any complaints. All these boxes are x86 platforms of very dirrefent
> configurations - two of them are your basic PCI pcs with dual IDE and all,
> the third one is an EISA/PCI SCSI-equipped combo. One note - I tried to run
> xntpd (no kernel PLL support) under 2.6 beta on a box with the hard disk
> drive and the CD drive on one IDE controller and IDE driver configuration
> was the worst-case one (smallest possible block_factor). And it did look to
> me that the system would lose timer interrupts when any disk activity
> appeared.
>
> Dima
From: Dann Lunsford <dann@greycat.com>
Date: Tue, 30 Dec 97 19:26:35 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Building xntp3-5.91 on Linux
X-Keywords: Slackware [-/+] Windows [-/+]
In <34A81C28.109BB7AD@ktk.bidmc.harvard.edu>, on 12/29/97
at 04:54 PM, "Kristofer T. Karas" <ktk@ktk.bidmc.harvard.edu> said:
>Dann Lunsford wrote:
>> Running Slackware 3.4, gcc 2.7.2.3, libc5.4.38.
>> Configuring xntp 3.5.91 went fine. BUT...
>It's a problem with the customized version of GCC-2.7.2.3 used in
>Slackware 3.4. It was compiled to allow it to back-end the g77
>compiler; something about configuring gcc thusly causes this behaviour.
>Two solutions are available: if you need g77, then use the GCC-2.7.2.1
>package in slackware's contrib directory (Patrick Volkerding put it there
>to allow compiling ntp, samba, and a few other programs that also break).
>If not, obtain H.J. Lu's official gcc-2.7.2.3.bin.tar.gz packages from
>sunsite or tsx-11.
Thanks for the info! This was driving me nuts (not a long distance, I
admit). I grabbed HJL's package, and everything started working just
fine. Samba, too? Heh, that was the next major package I was going to
deal with; would have caused a little confusion...
Thanks, again.
--
Dann Lunsford * The only thing necessary for the triumph of evil *
dann@greycat.com * is that men of good will do nothing. -- Cicero *
The Ultimate Windows Bug Fix: OS/2 with PROTECTONLY=YES!
Hiroshima 45 -- Chernobyl 86 -- Windows 95
From: Andrew Hood <ajhood@fl.net.au> [-/+]
Date: Thu, 01 Jan 1998 22:54:46 +1100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How long for time to sync up?
Paul Kroculick wrote:
>
> Hello,
>
> I just setup xntp on an QNX box. The machines started out 8 minutes
> apart. After two days, they're still 8 minutes apart. I'm assuming
> I did something wrong, but how long should it take for the machine to
> sync its time?
If you have not set up an external time source or told one of them to
use its internal clock as a time source they never will synchronise.
My observation is that on a reasonably loaded network with stable clock
sources (eg GPS) everything syncs within 10 minutes. Usually within 5
minutes. Less if you run ntpdate first to get the clock close before you
start xntpd.
But then I don't have QNX. Just Solaris, Linux, WinNT and OS/2.
Andy
From: nospam@nospam.org (Mark K. Pettit)
Date: 05 Jan 1998 15:09:01 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: dispersion [-/+]
> In article <34986480.E1997E79@lucent.com> Bill McGovern <wem@lucent.com>
> writes:
> >Dima,
> >
> >Thanks for your suggestion to turn off kernel pll support at compile time. I
> >too was seeing high offsets and and dispersion with 3-5.91 compiled on the
> >Solaris 2.6 box (SPARC 5). After following your suggestion, the resultant
> >xntpd runs very nicely now, like the way it did under 2.5.1!
I've been following this thread for some time now, and I appreciate all
the work everyone has done to find out why xntpd behaves so badly under
Solaris 2.6. However, one thing that I'm still confused about is how,
exactly, to implement the recommended changes to xntpd 3.91. You mention
"turning off kernel pll support at compile time", but how does one do
this? Is there a switch I need to pass to the "configure" script? Is
there a change I need to make to the "Makefile" or "config.h" files?
Thanks for any advice...
--
------------------+--------------------------------------------
Mark K. Pettit | SpamGard(tm) in effect. To send me mail,
pettit@acm.org | include the word "tiger" in the subject.
------------------+--------------------------------------------
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 5 Jan 1998 23:34:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: KERNEL_PLL [-/+]
In article <x7hg7iwmb6.fsf@geocities.com> nospam@nospam.org (Mark
K. Pettit) writes:
> You mention
>"turning off kernel pll support at compile time", but how does one do
>this? Is there a switch I need to pass to the "configure" script? Is
>there a change I need to make to the "Makefile" or "config.h" files?
There might be a more "elegant" way to do it, but per Dima Volodin's
suggestion: Run configure as usual, then edit config.h to comment out
the '#define KERNEL_PLL 1', then make.
--Per Hedeland
per@erix.ericsson.se
From: clake@belay.cs.utah.edu (Chad Lake)
Date: 6 Jan 1998 06:52:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
X-Keywords: KERNEL_PLL [-/+]
In article <68rqmg$s8a$1@news.du.etx.ericsson.se>,
Per Hedeland <per@erix.ericsson.se> wrote:
>In article <x7hg7iwmb6.fsf@geocities.com> nospam@nospam.org (Mark
>K. Pettit) writes:
>> You mention
>>"turning off kernel pll support at compile time", but how does one do
>>this? Is there a switch I need to pass to the "configure" script? Is
>>there a change I need to make to the "Makefile" or "config.h" files?
>
>There might be a more "elegant" way to do it, but per Dima Volodin's
>suggestion: Run configure as usual, then edit config.h to comment out
>the '#define KERNEL_PLL 1', then make.
>
And I might point one more thing out, that burnt a lot of my time: you
need to reboot the machine after running a version of xntpd that uses
kernel pll support before running a "non-kernel-pll-support" version.
Perhaps someone here knows why this is so and perhaps has a better way
around it, but I lost a whole day trying to get 3.91 running on a
Solaris 2.6 box to no avail until I rebooted the thing. Once I did
that it has been running smoothly for about 10 days now.
-c
ps- note that the xntpd that comes with 2.6 uses kernel pll support
(or at least I think so...if you have run it since the last time the
machine was rebooted you might give powercycling a try).
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 6 Jan 1998 23:10:11 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp support in Solaris 2.6? [-/+]
In article <68skb8$mf3@magus.cs.utah.edu> clake@belay.cs.utah.edu (Chad
Lake) writes:
>And I might point one more thing out, that burnt a lot of my time: you
>need to reboot the machine after running a version of xntpd that uses
>kernel pll support before running a "non-kernel-pll-support" version.
Me too (actually I didn't burn a lot of time as it was only a test setup
- put it on the backburner, and then found after a totally unrelated
reboot that it was suddenly working fine:-). I do believe I've mentioned
that here before, but it's certainly worth repeating.
>ps- note that the xntpd that comes with 2.6 uses kernel pll support
>(or at least I think so...if you have run it since the last time the
>machine was rebooted you might give powercycling a try).
It does not, as far as truss tells me - only adjtime() calls, no
ntp_adjtime(). Which is no real surprise as that version (3.4y) didn't
have the needed code AFAIK, and the changes Sun have made to it aren't
related to this (according to someone from Sun who posted here a while
back).
I.e. the shipped version runs reasonably well if you don't need any
functionality added in a later version - as long as you haven't tried
running a kernel-pll-support version, then the shipped version becomes
unstable too until you reboot - utterly confusing until you've figured
this out of course!:-)
--Per Hedeland
per@erix.ericsson.se
From: John Ackermann <john.ackermann@daytonOH.ncr.com> [-/+]
Date: Tue, 06 Jan 1998 11:48:22 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Clock solution for SCO [-/+]
X-Keywords: SCO [-/+]
You might check the "Torally Accurate Clock" project -- it's a GPS
receiver/interface board combination for about $500 that can provide
sub-microsecond timing, and can serve as a reference clock for xntpd.
Check http://www.febo.com/ntp for pointers to information about the TAC
and the clock driver.
John Ackermann N8UR
jra@febo.com
http://www.febo.com
CMG wrote:
>
> Hello,
>
> I'm looking for a clock solution for my project. Initially, we wanted to
> use HOPF radio-time receivers
> but we've found out that on the location we have to install, we cannot
> guarantee proper reception of
> the radio time.
> Next, we wanted to use XNTPD but due to the nature of our connection to a
> reference server,
> we cannot use this (thanks to Kees Hendrikse for the information). The
> nature is that the reference
> server calls our machine and has a PPP link available for about 20-30
> seconds.
>
> Now I'm stuck. My goal is to keep the drift of the system clock of a SCO
> Unix box
> within 10 msec / 7 hours. The PC's I do have do not achieve this using
> their native
> clock (they drift between 50 and 150 msec in that time).
>
> My best option seems to be to use high quality clock card. Then, using the
> results from NTP date
> store the reference clock information onto this card and use the time from
> the card as a
> reference. Is anybody aware of a product that could do this?
>
> Furthermore, I have read somewhere that the drift can be estimated from the
> difference ntpdate
> reports. Can anybody elaborate for me on this? Is it a manual procedure or
> can it be automated?
>
> Thanks
>
> Marcel
--
John Ackermann Amateur Radio N8UR (ex-AG9V)
home: jra@febo.com http://www.febo.com
work: john.ackermann@daytonOH.ncr.com
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 06 Jan 1998 14:28:24 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: Clock solution for SCO [-/+]
X-Keywords: AIX [-/+] ATOM [-/+] dispersion [-/+] NMEA [-/+] PPS [-/+] resolution [-/+] SCO [-/+]
CMG wrote:
>
> Hello,
>
> I'm looking for a clock solution for my project. Initially, we wanted to
> use HOPF radio-time receivers
> but we've found out that on the location we have to install, we cannot
> guarantee proper reception of
> the radio time.
What you want/need is probably a GPS reference clock connected to the serial
port of the SCO box, using the NMEA and ATOM clock drivers.
You can get fairly cheap GPS units with the PPS signal if you buy them from
TAPR (www.tapr.org), but this requires you to do some assembly/soldering
work.
Otherwise, most of the companies who deliver HOPF-based reference clocks
will also have GPS interfaces for them, so this would also work.
The easiest solution to set up is a dedicated NTP-GPS Stratum-1 clock, I
have recently installed one from TymServe, but there are at least two other
vendors.
With this clock as the source, and 3-4 unix (AIX, Solaris, Linux) machines
listening to the master and peer-ing between each other, we get _very_
stable system clocks, with sub-millisecond dispersion even in the middle of
the day when network traffic is peaking.
> My best option seems to be to use high quality clock card. Then, using the
> results from NTP date
> store the reference clock information onto this card and use the time from
> the card as a
> reference. Is anybody aware of a product that could do this?
If you want to use a clock card, then you can just query the card directly
for micro-second resolution timestamps at any point.
I have noticed that TymServe has such a PCI-based card, as well as an older
AT-bus version. I believe both can/will use GPS for the time reference.
> Furthermore, I have read somewhere that the drift can be estimated from the
> difference ntpdate reports.
Yes, it can, but probably not accurately enough to keep your drift rate
below 10ms/day.
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: salgado@mars.lpthe.jussieu.fr (Julien SALGADO)
Date: 8 Jan 1998 08:35:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.misc
Subject: Re: xntp in linux [-/+]
X-Keywords: broadcast [-/+] configuration [-/+] peer [-/+]
Kelvin Leung wrote:
>Anyone who has setup xntp in Linux? I'm going to do it but I'm not quite
>sure how to start...
Non't be afraid, it is quiet easy, I did it. Fisrt get xntp, and compile it
or get a binary archive. After if you want to use xntp, you just need to
set up the configuration file, here is mine:
/etc/ntp.conf
peer clet.lpthe.jussieu.fr
server ntp1.jussieu.fr
server ntp2.jussieu.fr
broadcast 134.157.10.127
The server lines gives the names of two close ntp server, you will have to
find out the names of yours.
The peer line is the name of a other machine in my LAN which I want to
syncronise with.
The syncronization is made with the first available server and checked with
the peers, that mean that all the machines of your LAN will be at the same
time.
The last line should be clear.
Here is my /etc/rc.d/init.d/xntp file for redhat System V, if someone needs it
(my xntp programs are in /usr/local/bin, change the path if necessary):
#! /bin/sh
#
# ntp Start/Stop the xntp clock daemon.
#
# Author: Julien F. J. SALGADO
#
# Source function library.
. /etc/rc.d/init.d/functions
# Add /usr/local/bin in the PATH
export PATH=$PATH:/usr/local/bin
# See how we were called.
case "$1" in
start)
echo -n "Starting xntp daemon: "
daemon xntpd
echo
touch /var/lock/subsys/xntp
;;
stop)
echo -n "Stopping xntp daemon: "
killproc xntpd
echo
rm -f /var/lock/subsys/xntp
;;
*)
echo "Usage: xntp {start|stop}"
exit 1
esac
exit 0
--
Julien
From: John Ackermann <john.ackermann@daytonOH.ncr.com> [-/+]
Date: Thu, 08 Jan 1998 16:25:14 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.misc
Subject: Re: xntp in linux [-/+]
Kelvin Leung wrote:
>
> Hi,
>
> Anyone who has setup xntp in Linux? I'm going to do it but I'm not quite
> sure how to start...
>
> B.R.,
> Kelvin
There's an xntp3 package available in the Linux distribution, so the
simplest way might be to grab that. However, the stock xntp3-5.91
sources are an easy build under Linux. Just untar and read the READMEs.
John
--
John Ackermann Amateur Radio N8UR (ex-AG9V)
home: jra@febo.com http://www.febo.com
work: john.ackermann@daytonOH.ncr.com
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Thu, 08 Jan 1998 09:26:58 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.misc
Subject: [++] Re: xntp in linux [-/+]
Kelvin Leung wrote:
>
> Hi,
>
> Anyone who has setup xntp in Linux? I'm going to do it but I'm not quite
> sure how to start...
Linux is probably _the_ easiest platform to setup xntp on!
Simplified procedure:
ftpsearch (http://ftpsearch.ntnu.no/ftpsearch) the net for a nearby copy of
xntp-3.*
(or just go directly to The Source: ftp://ftp.udel.edu/pub/ntp) for the
source code.
Try to get version 3.5.91 (xntp3-5.91.tar.gz)
cd /usr/src
tar -xzv < <file_we_just_got
cd xntp3-5.91
./configure
make
make install
vi /etc/ntp.conf # Create a minimum config file, see the docs!
xntpd # Start the deamon
That's it.
Terje
PS. If you don't have gcc properly installed, then you can search for a
pre-compiled .RPM version and avoid the ./configure & make steps.
--
- <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: Tom.Horsley@worldnet.att.net (Thomas A. Horsley) [-/+]
Date: 07 Jan 1998 17:07:01 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate source?
X-Keywords: Windows [-/+]
>Does anyone know where I can get a simple version of ntpdate that I
>can compile under Microsoft C++ or some similar compiler running on
>i386 machines?
The NTPTime program on my web site works on NT and Windows 95 and the
source code is available, but I don't know how easy it would be to
port to wfw3.11. (see .sig below for pointer to web site).
--
>>==>> 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: Corey <corey@virtual-impact.com>
Date: Thu, 08 Jan 1998 09:34:06 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.misc
Subject: Problems with xntp (was)[++] Re: xntp in linux [-/+]
X-Keywords: reset [-/+] synchronized [-/+]
Hello,
I've had ntp set up for a few weeks now on a small network at our office.
It seems to be working
out just fine except for one thing:
# grep ntp /var/log/messages
Jan 6 19:04:41 visidev xntpd[18996]: synchronisation lost
Jan 6 19:53:42 visidev xntpd[18996]: synchronized to 164.67.62.194, stratum=1
Jan 6 23:18:48 visidev xntpd[18996]: time reset (step) -0.151109 s
Jan 6 23:18:48 visidev xntpd[18996]: synchronisation lost
Jan 6 23:24:07 visidev xntpd[18996]: synchronized to 164.67.62.194, stratum=1
Jan 7 01:45:17 visidev xntpd[18996]: synchronisation lost
Jan 7 02:19:18 visidev xntpd[18996]: synchronized to 164.67.62.194, stratum=1
Jan 7 05:15:02 visidev xntpd[18996]: time reset (step) -0.149627 s
Jan 7 05:15:02 visidev xntpd[18996]: synchronisation lost
Jan 7 05:20:22 visidev xntpd[18996]: synchronized to 164.67.62.194, stratum=1
Jan 7 05:41:42 visidev xntpd[18996]: time reset (step) -0.179457 s
This happens often and sporadically .... anything to worry about?
Helpfull replies much appreciated.
Corey
corey@virtual-impact.com
From: ktk@ktk.bidmc.harvard.edu (Kristofer T. Karas) [-/+]
Date: 9 Jan 1998 22:59:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.misc
Subject: Re: Problems with xntp (was)[++] Re: xntp in linux [-/+]
X-Keywords: adjtimex [-/+] adjustment [-/+] implementation [-/+] manpage [-/+] panic [-/+] PLL [-/+] PPM [-/+] prefer [-/+] reset [-/+]
Frank Sweetser <rasmusin@WPI.EDU> wrote:
>Corey <corey@virtual-impact.com> writes:
>> It seems to be working out just fine except for one thing:
>> Jan 6 23:18:48 visidev xntpd[18996]: time reset (step) -0.151109 s
>
>this is normal. pc clocks are only so-so accurate,
No, this isn't normal; it means the clock is running so fast that it
exceeds the kernel's ability to adjust it using the PLL (100 PPM in
this implementation), forcing xntpd to panic and `step' the clock.
Fortunately, the kernel implementation has a gross-adjustment (`TICK')
which you can change to remove the bulk of this static error (or
"systematic drift" if you prefer); that's the most likely culprit in
this case.
Grab a copy of adjtimex-1.3.tar.gz off of sunsite.unc.edu
Read the manpage.
configure ; make ; make install ; adjtimex --compare
Heed the value of 'tick' it arrives at.
Add a line to your startup script (/etc/rc.d/rc.S, or whereever your
'clock -s' or 'hwclock --hctosys' command resides) that tells adjtimex
to adjust system timing accordingly. For example, one linux machine
here has 'adjtimex --tick 9996 --freq 1120000' in its rc.S.
Xntpd will now be able to keep your system time phase-locked.
--
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: Marc Brett <mbrett@rgs0.london.waii.com> [-/+]
Date: 9 Jan 1998 10:42:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP and MVS ? [-/+]
X-Keywords: implementation [-/+] MVS [-/+]
xyz@oo.here wrote:
> Hello,
> I am looking for a XNTP-solution for MVS/ESA 5.2.2.
> Does anybody know something about it?
AFAIK, there is no implementation of NTP on MVS.
One soulution is to buy a Sysplex Timer from IBM, and run NTP on the
OS/2(?) control workstation. Then write a program to periodically send
a message to the Sysplex Timer with the current time.
--
Marc Brett +44 181 560 3160 Western Atlas
Marc.Brett@waii.com 455 London Road, Isleworth
FAX: +44 181 847 5711 Middlesex TW7 5AB UK
From: Carl Brewer <c.brewer@abm.com.au> [-/+]
Date: Sun, 11 Jan 1998 10:23:24 +1100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP and MVS ? [-/+]
X-Keywords: implementation [-/+] MVS [-/+]
Marc Brett wrote:
>
> xyz@oo.here wrote:
> > Hello,
>
> > I am looking for a XNTP-solution for MVS/ESA 5.2.2.
> > Does anybody know something about it?
>
> AFAIK, there is no implementation of NTP on MVS.
Agreed, I looked into this fairly closely last year, and there
is no (that I found) way to directly drive an MVS system to
use NTP to set its clock(s).
> One soulution is to buy a Sysplex Timer from IBM, and run NTP on the
> OS/2(?) control workstation. Then write a program to periodically send
> a message to the Sysplex Timer with the current time.
That's probably the best way to do it.
Guess what a Sysplex is worth ....
(and how lots of shops then set them ... it's a laugh :) )