From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 7 Sep 1996 18:20:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: help ! [-/+]
X-Keywords: configuration [-/+] peer [-/+] synchronized [-/+]
In article <50l3vm$4jg@hpindda.cup.hp.com> dalton@cup.hp.com (David Dalton) writes:
>This is not a very wise configuration. Do not use the local clocks at all,
>the only reason to ever use the local clock is when you are completely
>isolated from all sources of accurate time. The local clock is almost
>guaranteed to be inaccurate, especially over a timespan of weeks or more.
I have to disagree - using the local clock as a *fallback* (i.e.
configured with a high stratum) is often very wise if done the right
way, which is typically at the server(s) that get time from the
Internet. Doing this will primarily make sure that your internal servers
stay synchronized with each other rather than run free in case your
Internet link, or the servers on the Internet that you get time from,
have problems (hopefully neither condition will persist for weeks:-).
And while having the same time on all your systems is typically much
more important than having the absolutely correct time, xntpd will do a
pretty good job of the latter too in this situation, as it will keep
applying the drift compensation value, which was determined when it had
contact with other servers, to the local clock.
>In addition it is contradictory to have a machine "peer" with another machine
>at a different stratum. You can do it, but you will be worse off in the
>end. The meaning of "peer" is "at the same level", and the purpose of the
>peer connections is to provide redundancy.
I'm afraid I have to disagree with this too, except for the very last
words. It is perfectly reasonable to configure servers at a lower
stratum as "peer", and in fact the docs that come with the distribution
more or less suggest that you use "peer" everywhere except on systems
that never provide time to others (e.g. workstations and the like).
In the xntpd context, "peer" in the config file means just "I want to
get time from this host, and am also prepared to provide time to it if
wanted". You will certainly not be "worse off" for using it, but it may
seem pointless as you don't have any time to provide. This is not
typically true however, as you probably specify several servers as time
sources - if one of them has problems with *its* sources, it can instead
get time via you from your other sources. The choice of whether to
actually do this is up to that server of course, but by specifying
"peer" you have at least made it possible.
--Per Hedeland
per@erix.ericsson.se
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Mon, 16 Sep 1996 10:33:51 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: Time Clients: request for recommendations/opinions
Christoph Badura wrote:
>
> In <51cik6$2mn@netnews.upenn.edu> tony@staff.dccs.upenn.edu (Anthony Olejnik) writes:
>
> >Q: Are there *any* other NTP clients (for the above mentioned platforms) that
> > are *NOT* listed at the 'NTP web site' which should be considered?
>
> I haven't heard about an NTP client for Netware. However there are two
> rdate clients for Netware. From looking at the source of one of them, I
> think it's possible to port xntpd to Netware.
It should have been trivial to port xntpd to NetWare 4.X, since 4.X has
it's own TimeSync process that's responsible for keeping all servers in
sync. TimeSync is definitely based on a (regrettably cursory) reading of
the NTP specs.
The guy who wrote TimeSync obviously intended to make it possible to
interface external sources to it, he started by defining external APIs
that would allow you to get/set the current time (in ntp 32:32 format!)
and get/set the current tick rate, i.e. the needed adjtime()
functionality.
Unfortunately, AFAIK, those APIs are still commented out of the source
code! This means that the only external interface that can set/adjust
the TimeSync clock is the very old SetServerTime() (sp?) api, which
cannot set fractional seconds, and has no way to modify the tick rate.
--
- <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: thomasgd@boat.bt.com (Greg Thomas)
Date: Thu, 19 Sep 96 08:22:20 GMT [-/+]
Newsgroups: comp.os.vms,comp.protocols.time.ntp
Subject: Re: xntp (ntp) for VMS. [-/+]
X-Keywords: documentation [-/+] VMS [-/+]
In article <51q0q5$5d@moon.htc.honeywell.com>,
thomas@src.honeywell.com (Vic Thomas) wrote:
>
>An experiment we are performing requires us to synchronize the clock on an
>Alpha running VMS with Suns running SunOS.
NTP comes with both the latest version of UCX (err, Digitial TCP/IP Services for
OpenVMS) and TCPware. Quite possibly a few others too, but those are the only
two I use. Check the documentation of your TCP/IP stack to see how to set it up.
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Date: 19 Sep 1996 20:07:17 GMT [-/+]
Newsgroups: comp.os.vms,comp.protocols.time.ntp
Subject: Re: xntp (ntp) for VMS. [-/+]
X-Keywords: Cisco [-/+] VMS [-/+]
In article <51q0q5$5d@moon.htc.honeywell.com>,
Vic Thomas <thomas@src.honeywell.com> wrote:
>Is there an xntp distribution for VMS? If you know of such a distribution or
>have any suggestions on how I can synch. the clocks on the VMS/Alpha box with
>the SunOS/Sparc boxes I'd greatly appreciate hearing about it. You may send
>me e-mail (thomas@htc.honeywell.com).
Both Pathway for VMS (was Wollongong, now Attachmate) and Cisco Multinet
have ntp clients. We've used both here with no problems.
--
Mike Iglesias Internet: iglesias@draco.acs.uci.edu
University of California, Irvine phone: (714) 824-6926
Office of Academic Computing FAX: (714) 824-2069
From: david@djwhome.demon.co.uk (David Woolley) [-/+]
Date: Sun, 22 Sep 1996 13:26:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: newbie question
X-Keywords: FAQ [-/+] PPM [-/+]
In article <WIU09524.96Sep20161532@rrzc5>,
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>In article <32429239.7885@apogee-com.fr> Jean-Francois Zwobada <zwobada@apogee-com.fr> writes:
>
>> After looking at the FAQ, I must confess I am quite lost...
>>
>> Could someone tell me how to interpret the drift values to adjust
>> my local clock ? One of my BSD/OS box is served by 3 external stratum 2
>> servers and its drift value is near -90.000 ...
The drift values already have compensated for the local clock errors.
>First of all the clock is a rather poor one (a PC?). Then the unit of
>drift is PPM (parts per million). If I'm not wrong your clock has an
It's actually parts in 2**20, and this does matter if you are trying
to calibrate an isolated system to run on the local clock driver. Note
that it is quite possible to set to within 100ms by wrist watch and eye
methods, and to achieve 500ms a week (actually 500ms a month on the
last cycle) drift rates. It doesn't need a large static frequency
offset for the parts per million/parts per 2**20 distinction to make a
measurable difference, although, as you iterate onto the correct
frequency you will eventually converge either way, just more slowly.
--
David Woolley, London, England david@djwhome.demon.co.uk
(Sending any email to this site constitutes a licence to copy it to any
company which might reasonably be assumed to have transported it or
might reasonably be assumed to service any addresses quoted in it. 15Sep1996)
From: Raju Varghese <Raju.Varghese@ubs.com> [-/+]
Date: Thu, 26 Sep 1996 07:36:16 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Broadcast/Multicast Client List [-/+]
X-Keywords: multicast [-/+] Windows [-/+]
Greg Hollingsworth (BIX) wrote:
>
> I'm looking for a list of broadcast/multicast NTP client
> implementations for the various operating systems (Win{95,NT,31,WFW},
> Mac, Unix). If you have such a list or can provide pointers to
> clients I would appreciate your sending me the information. I'll be
> happy to summarize what I get to the list.
TimeSync for Windows NT can handle NTP broadcasts. More information at
http://www.intsoft.com/timesync.html
---
Raju Varghese
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 26 Sep 1996 14:21:08 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Broadcast/Multicast Client List [-/+]
X-Keywords: Windows [-/+]
>
> TimeSync for Windows NT can handle NTP broadcasts. More information at
> http://www.intsoft.com/timesync.html
But TimeSync does not learn from the past; it just adjusts the clock
in single-shot manner and goes to sleep again. Doe NT learn about the
error of the clock?
>
> ---
> Raju Varghese
From: bryant@eisner.decus.org (Geoff Bryant)
Date: Thu, 26 Sep 1996 13:11:59 GMT [-/+]
Newsgroups: comp.os.vms,comp.protocols.time.ntp
Subject: Re: xntp (ntp) for VMS. [-/+]
X-Keywords: VMS [-/+]
In article <51quij$reu@ns1.nl.cis.philips.com>, c753330@lss.cp.philips.com (Alex Kok) writes:
> thomas@src.honeywell.com (Vic Thomas) writes:
>
>>An experiment we are performing requires us to synchronize the clock on an
>>Alpha running VMS with Suns running SunOS. We have xntp running on the Suns
>>but I've been unable to find an xntp for VMS. The xntp distribution (version
> ...
>>Is there an xntp distribution for VMS? If you know of such a distribution or
>
> Look at the doc. of the TCP/IP package you use. You *do* need TCP/IP.
> Multinet has it. Ucx has it. Don't know about the others.
> --
>
> Groeten, Alex Kok (c753330@nlzcl1.decnet.philips.nl)
>
TCPware from Process Software also provides full ntp support. You can
check us out at:
http://www.process.com/
info@process.com
Geoff Bryant
Process Software
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 27 Sep 1996 10:46:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd and adjustimed on 10.10x
X-Keywords: HPUX [-/+] precision [-/+]
In article <324A90F3.2AB9@pbs.org> sdroppers <droppers@pbs.org> writes:
> You may not need to compile xntp for HPUX 10.10, xntp support is now
> included as part of the standard 10.10 distribution, and can be
> configured and started from the "SAM" interface.
True, but that version is very old. It also yields poor performance
(precision -6 instead of -16), and it does not support many reference
clocks.
You might get a recent 3.5f version with almost every driver as a
patch from HP. I'm beta-testing it.
>
>
> Seton
> --
> Seton Droppers -- Senior Telecommunications Analyst
> Public Broadcasting Service, 1320 Braddock Place, Alexandria VA
> 22314-1698
> EMail: droppers@pbs.org Voice: 703.739.5089 FAX: 703.739.5428
> <a href="http://www.pbs.org/>Come Visit PBS!!!</a>
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 27 Sep 1996 10:57:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP client configuration.
X-Keywords: configuration [-/+] dispersion [-/+] driftfile [-/+] monitor [-/+] peer [-/+] precision [-/+] synchronized [-/+]
In article <324AE700.237C@healthgate.com> Ed Sanborn <esanborn@healthgate.com> writes:
> I've been asked to setup XNTP on several Sun's running Solaris 2.4
> and 2.5. I've been told to use noc.near.net as our server. I've
> compiled the binary for Solaris 2.4 and I'm try'ing to get thing's going
> on the Solaris 2.5 systems. Just to get it going is it just a
> simple matter of creating a /etc/ntp.conf file with the following in it:
>
> server noc.near.net
>
> And then starting xntpd...
Yes! You've found out the basics... But I'd recommend to add a
driftfile (/etc/ntp.drift) for quicker synchronization after reboot.
>
>
> /usr/local/bin/xntpd
>
> What should happen? Should I be able to see the time adjust?
Yes, if the server is really a ntp server. Use xntpdc's "peer" command
to monitor the dispersion (last column) of your servers. It starts
with 16.0 (no information) and goes toward zero. As soon as you are
below 1.0 (usually after 5 minutes) your time should be stepped for
the first time, and you'll lose synchronization. The game repeats once
more, but this time your clock should already be very close and the
system begins to "learn" about your clock's drift. It will try to
compensate for that.
Once you have a stabilized xntpd, it won't accept time changes too
quick (but there shouldn't be such).
For a Sparcstation 10 and Solaris 2.5 (precision -18) it can take
several hours until the local clock has been corrected to the final
precision. (Stability in xntpdc's "sysinfo" command should finally be
0 (0 is good, large numbers are bad).
>
> What options to the startup of xntpd should I use if any?
If you have a configuration file, usually none. If you have no idea
what's going on, you might try "-D4" to activate lots of debugging
messages...
>
> Thanks in advance!
Hmm, I see: Your time is not yet synchronized ;-)
>
>
> --
> Edward A. Sanborn Senior Systems Administrator
> HealthGate Data Corp. (617) 321-6000 x.236
> 380 Pleasant St., Suite 230
> Malden, MA. 02148 http://www.healthgate.com
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: robert@tabby.kudra.com (Robert Sexton) [-/+]
Date: 29 Sep 1996 22:34:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: *sigh* newbie question
X-Keywords: FAQ [-/+] fudge [-/+] NIST [-/+]
Patrick Hess (phess@best.com) wrote:
: So, I went looking for the FAQ and couldn't find it. I'm kinda in a rush
: and really hate to bother you guys, but I thought I would throw this out
: there for your perusal.
: Due to circumstances beyond my control at this time, my link to a strata 1
: server is severed. I need to be able to set a strata 0 machine within my
: domain. I don't know what to do to the config file (or if this is even
: possible) to make this change. Can someone please point me in the right
: direction (even if it is the FAQ)? I very much appreciate it.
: Pat
Use the local clock device (127.127.1.0) to designate a 'fake' source
of time. It seems desirable to use the fudge command to lower the
strata of the pseudo clock to 7-9. By tweaking the time2 parameter,
you can manually tune a local clock to run _quite_ well. I would
check mine against NIST daily until I had it with a second or so,
(16ppm, or so), an then switch to weekly checks.
One cautionary note: If there is _any_ possibility that real
time might come back on line, make sure that your local clock source
respects the lower stratum time. I recently pulled out hair when a
previously isolated local clock came into contact with a real stratum
2 server, and my clients would slew the clock back and forth switching
from the stratum 2 to the stratum 8 source.
--
Robert Sexton, robert@kudra.com
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 01 Oct 1996 13:58:17 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Auth questions ( was: *sigh* newbie question )
X-Keywords: configuration [-/+] controlkey [-/+] delay [-/+] driftfile [-/+] fudge [-/+] password [-/+] poll [-/+] prefer [-/+] requestkey [-/+] trustedkey [-/+]
In article <52r55v$73l@shellx.best.com> phess@best.com (Patrick Hess) writes:
> Thanks for your help. I now have the local clock as a stratum 3 source.
> I would like to set it to stratum 10 (because your suggestion sounds
> reasonable). After reading the dox, I get the impression that I need to
> have the "requestkey" keyword in the conf file or else my "fudge" attempts
> will be ignored. I have added it. I have also added the entry in ntp.keys
> that I think should correspond.
requestkey is needed for interactive adjustments/configuration.
Usually you'll have a request key (and an entry in /etc/ntp.keys, your
keyfile).
>
> I have been poring over the dox, and have found some confusing information in
> authopt.html. With the "requestkey" in the conf file, I am supposed to use
> an integer argument to indicate the key number for use with xntpdc. Then, in
> the ntp.keys file, I am suppsed to use the same key number and give it a
> password. Does this sound right? I suspect I'm reading this wrong.
Right, the keys are passwords in reality; thus chmod go-rw /etc/ntp.keys.
>
> Here is the /etc/ntp.conf:
>
> # /etc/ntp.conf
> # nuts -- stratum 10 config for local clock
>
> requestkey 9
>
> driftfile /etc/ntp.drift
>
> server 127.127.1.0 prefer
I'm not sure about the "prefer"; better leave it out; NTP is smart.
>
>
> Here is the /etc/ntp.keys:
>
> 9 A NTPsux
I also have a "trustedkey 9" and a "controlkey 9" in my /etc/ntp.conf file.
Maybe you need that, too.
>
> Hoever, here what I get when I try to use "fudge" from xntpdc:
>
> xntpdc> peers
> remote local st poll reach delay offset disp
> =======================================================================
> =LOCAL(0) 127.0.0.1 3 64 1 0.00000 0.000000 15.8850
> xntpdc> fudge 127.127.1.0 time1 0.0 time2 0.0 stratum 10
> Keyid: 9
> Password: [unechoed NTPsux]
> ***Permission denied
See my last comment.
You might use "fudge 127.127.1.0 stratum 10" and
"fudge 127.127.1.0 time2 12.345"
in your /etc/ntp.conf, too (works for me).
> xntpdc>
>
> Can someone point me in the right direction with this one, too? I promise
> this will be the last question I ask in here. Also, thank you for all the
> previous help.
>
> Pat
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 01 Oct 1996 08:40:33 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Checking status of NTP.
X-Keywords: documentation [-/+] FAQ [-/+] loopstats [-/+] stability [-/+]
(First a general note: Please try to read some articles from the past
before asking potentially FAQs)
Run "xntpdc your_host" and enter "pe". You should see a '*' in the
first column indicating the current reference for that host. In the
"offsets" column you see the offsets in seconds.
Enter "loopinfo" to see the estimated offset of your clock.
With "sysinfo" you can watch the stability of your local clock (0 is
good, large is bad).
If you want more information, read the documentation, especially
xntpd's "loopstats" statistics.
Ulrich Windl
(Isn't there a FAQ supplied with xntp3)
From: add@pecos.is.rice.edu (Arthur Darren Dunham) [-/+]
Date: 1 Oct 1996 20:20:28 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Client configure.
X-Keywords: dialup [-/+]
In article <52gpev$33d@news.iastate.edu>,
Jon Hamilton <hamilton@sysad.cnde.iastate.edu> wrote:
>In article <WIU09524.96Sep27124339@rrzc5>,
>Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>If your connection is dial-up with varying IP addresses you can't use
>>xntpd.
>Don't tell that to my home machine, which uses dynamic IP addresses and
>xntpd. I just use the machine's clock as a stratum 10 reference, and
>some public ntp servers for better information while the machine is
>dialed in. I did have to put the public servers in my hosts file so
>xntpd didn't have problems resolving them (in which case it punts).
I think what Ulrich was referring to was the fact that your xntpd daemon
will not notice when your machine's IP interface changes among your
dialup provider's addresses. Since yours is working, I imagine you must
have a script which runs when your link comes up that kills the daemon
and restarts it so it can latch onto the new dialup interface.
--
Darren Dunham add@is.rice.edu
UNIX Sysadmin Rice University
(This line currently in revision) Houston, TX
Any resemblance between real opinions and my post is coincidental
From: pausch@electra.saaf.se (Paul Schlyter) [-/+]
Date: 4 Oct 1996 08:34:29 +0200 [-/+]
Newsgroups: sci.astro.amateur,sci.astro,comp.protocols.time.ntp
Subject: Re: Leap seconds Re: how many seconds from 700101 to 950101?
X-Keywords: compatible [-/+] nist [-/+]
In article <32517272.3800@nist.gov>,
Bruce Borchardt <bruce.borchardt@nist.gov> wrote:
> Leap seconds are a consequence of the conversion from astronomical to
> atomic time-keeping. Donald B. Sullivan is the chief of the Time and
> Frequency Division of the National Institute of Standards and Technology
> (where I work, but in the length metrology division), and he says that
> the leap seconds are primarily a compensation for the re-definition of
> the second in 1967. The new number (9.162770 billion oscillations of
> the cesium atom) wasn't quite consistent with the astronomical second.
Untrue -- the second was redefined already back in 1960: prior to 1960
it was defined as 1/86400 of a mean solar day, and after 1960 as some
fraction of the length of the Earth's tropical year in 1900. Since
then astronomers have been forced to keep track of the difference between
UT and ET (Ephemeris Time), which now is somewhat more than one minute.
When the atomic second was defined, it was purposely defined as close as
possible to the Ephemeris second. They succeeded quite well -- the atomic
second is so well compatible with the Ephemeris second that the two can
be considered a continuous time scale within the accuracy obtainable in
Ephemeris time.
The really new thing with atomic time was that it was available
immediately. Ephemeris time was available only a few years
afterwards, when the analysis of the relevant astronomical
observations (mostly the Moon's precise motion) had been completed.
That's why there were no leap seconds back then: since the difference
between Ephemeris time and Universal time wasn't known until a few
years later, there was no way "leap seconds" could practically be
handled.
> As previous posts have shown, we tend to add roughly one second per
> year. The *variation* in the leap seconds is due to variations in the
> earth's rotation rate, but the "base rate" is from the adoption of the
> new definition. In theory, a leap second can be negative, but it never
> has happened, and it's unlikely to ever happen.
The base rate changes too. Our current atomic second, which is based
on the earlier Ephemeris second, pretty well matches the Earth's
rotation rate some 100-200 years ago. If the atomic second had been
defined and implemented some 300 years ago and earlier, then negative
leap seconds would have been very common.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch@saaf.se psr@home.ausys.se
From: bwb@etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Date: 4 Oct 1996 17:45:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: minpoll argument log2(seconds)
X-Keywords: dispersion [-/+] maxpoll [-/+] minpoll [-/+] poll [-/+] prefer [-/+] RFC [-/+] stability [-/+]
I'm posting my answer to a private question about minpoll
in hopes it helps others. (A bit long.)
Question:
By the way, do you know how to increase the polling interval?
By default, every client asks for the time every 64 seconds
(something about that I think). I would prefer if this value would
be something about 600 seconds. I found a parameter "minpoll", but
when I set this to for example 600, xntpd tells me that minpoll is
bigger than maxpoll... Do you know anything about that?
Possible Answer and discussion:
The minpoll and maxpoll options in the ntp.conf server
statement have arguments of log2(seconds), which is the
internal unit. As I read the xntp3.5-86/html/confopt.html
the range is 4 to 14 (16 sec to 16384 sec), but I think there
are some restrictions to a lesser range for certain cases.
I've tried to set 127.127.1.1 to other values without much
joy.
I have an outside server that is a fallback and I have
the line
server nic.near.net minpoll 10
in my ntp.conf to reduce the poll speed to once / 1024 seconds.
I do this to reduce the trafffic to this popular server.
(As always, please ask permission to access public servers.)
If I reboot and this is my only server, xntpd would take
about an hour and a half to achieve initial synch (maybe longer).
Changing minpoll can really change the xntpd behavior.
I don't have enough experience or math to understand the
trade-offs of having large minpoll values on the main line
of the synch sub-network. It depends on the network delays
and clock stability details... I suggest waiting a week or
two to learn about your hosts clocks and behaviors. The poll
times should be low while xntpd is learning the host's drift.
I suggest checking as to why the daemon keeps the polling
times low. If xntpdc showp <server> has widely varying delays,
minpoll 8 might be a good answer. If the details show that your
nearest, smallest stratum number server is stable, but other
outside servers at the same stratum have variable offsets &
delays, you might want to try the
server <nearyby> prefer
trick to prevent xntpd from averaging the top three servers
which is the default behaviour (which is against the RFC but
seems very sensible when these servers have similiar stats).
I use prefer on my best/nearest server to stop averaging some
noise and it makes my poll times run out nicely, unless
the network delays gets bad for several hours.
xntpd should run the poll times out to 1024 to 4096 with
typical clocks on a quick local network. When my building's
network is overloaded, the poll times drop down to 64 sec due
to the repeated extra delays increasing offest and dispersion.
Over quiet weekends, I've seen them run out to 8192. My lower
stratum server that is very near a good reference seems to
sit at 16384 most of the time.
I personally think maxpoll 12 (4096 sec) is a good choice
for servers without particularly good clocks. At poll value
14 (16384 seconds), the server can drift off a modest amount
without noticing if something changes, such as room temperature.
It then thrashs about a bit as it recovers. I think "hourly"
polls would keep the offset low enough to smoothly tune onto
the correct time, instead of dropping poll times way down.
Bruce Bartram bbartram@etl.noaa.gov
Boulder, CO usual disclaimers apply
From: dalton@cup.hp.com (David Dalton) [-/+]
Date: 7 Oct 1996 20:58:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Precompiled NTP for HP-Ux
X-Keywords: adjtimed [-/+] DCF77 [-/+] HP-UX [-/+] Meinberg [-/+] Spectracom [-/+]
Roger Killick (rpk@kco.co.uk) wrote:
: Are there any versions of NTp available for HP-UX, already compiled.
I am preparing patches that will bring NTPv3.5 to HP-UX 9.x and 10.x
systems. Right now I just have binaries, not official patch packages, but
they work well and drop into your system very easily. Send me email and I
will mail you back shar files of the binaries.
BTW it is very easy to compile the Public Domain NTP on HP-UX 9.x systems,
and lots of people have done this. The steps are:
1. make refconf (take default response to all questions)
2. make
3. put one or more entries in /etc/ntp.conf
4. start adjtimed (perhaps with "-r" option)
5. start xntpd
Building on HP-UX 10.x is trickier. If you need more NTP functionality
than what is delivered with 10.x, the binaries from me are the best bet
until the official patches are ready.
I am particularly interested in beta sites with external reference clocks.
Right now I only have Spectracom Netclock/2, although the HP GPS clock is
coming soon and Meinberg DCF77 (Germany) and Motorola GPS are in the works.
I would love to add your clock to the list as well.
-> My $.02 only, not an official statement from HP
--
Our technology is weeks ahead of the competition!
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.com 408/447-3016
From: wls@astro.umd.edu (William L. Sebok)
Date: 8 Oct 1996 16:46:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP and Sun ULTRA's ???
X-Keywords: dosynctodr [-/+] fudge [-/+] nsec_per_tick [-/+]
In article <53duqs$m18@listserv.rice.edu> add@pecos.is.rice.edu
(Arthur Darren Dunham) writes:
>Under Solaris 2.x the recommended way of removing the TOD clock sync
>and fudging the 'tick' value was to add lines in /etc/system like this.
>
>set dosynctodr=0
>set nsec_per_tick = 10001000
>
>Under Solaris 2.5 (and 2.5.1 it appears) the tick fudge no longer
>works. It's just plain ignored.
Not quite true. For Sparc machines other than Ultra's, setting nsec_per_tick
works fine under Solaris 2.5. For Ultra's it is ignored. This machine is a
Sparc IPX running Solaris 2.5 with "set nsec_per_tick=9999675" in /etc/system.
ntp.drift is currently -1.11490. Generally I can do about that well.
I wish that Sun would make tweaking nsec_per_tick work on Ultra's.
--
Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy
Internet: wls@astro.umd.edu URL: http://www.astro.umd.edu/~wls/
From: hpa@transmeta.com (H. Peter Anvin) [-/+]
Date: 7 Oct 1996 03:18:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timezone
X-Keywords: DST [-/+] timezone [-/+]
Followup to: <532fr4$e2h@comm.bmsu.simbirsk.su>
By author: igor@bmsu.simbirsk.su (Igor Vinokurov)
In newsgroup: comp.protocols.time.ntp
>
> re,
>
> Quick question: who regulates timezones in Europe? Where I can
> get information about new dailight saving rule? (Sep->Oct)
>
Each country decides on their own what timezone they want to be in.
The DST rules have been harmonized within the EU for member nations; I
don't know if Switzerland and Norway have followed suit or not. The
Olson timezone database in ftp://elsie.nci.nih.gov/pub/
(tzdata*.tar.gz, the current version is tzdata96k.tar.gz) usually is a
very good collection of available information, and is
machine-readable; in fact, nearly all modern UNIX systems use the
Olson database, compiled with a program called "zic" which is a part
of the tzcode*.tar.gz package available on the same site.
-hpa
--
Not speaking for Transmeta in any shape, way, or form.
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 10 Oct 1996 11:03:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How to prevent ntpd from jumping forward in time [-/+]
X-Keywords: configuration [-/+] driftfile [-/+] synchronized [-/+]
In article <325C2B1A.5595@cae.ca> Eric Richer <richere@cae.ca> writes:
> Assume the following:
>
> We have a time server hookep up to a GPS clock and many client
> workstations trying to sync to the server. If one client workstation
> was disconnected from the network, fell behind in time by 10 seconds and
> then reconnected to the network then it would try to re-sync with the
> server. We observed that the client would at one point jump forward in
I guess that you eiher have no drift file configured and that yor
workstation uses a "sand clock (TM)", or you lose connection for
several days.
Without reboots you should lose less than one second per week. You
don't have other synchronization daemons running, have you?
> time by many seconds in one step. Our application running on the client
> workstation is very sensitive to big jumps (more than one second) in
> time either forward or backward.
Compile with -DALWAYS_SLEW (or something sounding very similar)
>
> Does anyboby know if there is a switch or configuration parameter to
> prevent ntpd or xntpd on Unix from jumping forward in time or to limit
> the size of the step that it takes?
>
> Any help is appreciated. Thank you.
>
Try my recommendations (driftfile, -D switch) and see what's going
on. Still, you shouldn't see these time warps IF xntpd is running and
has synchronized once. Remember: The very first synchronization can
take several hours, depending on the badness of the clock.
> Eric Richer
> CAE Electronics Ltd.
From: bwb@etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Date: 10 Oct 1996 18:39:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How to prevent ntpd from jumping forward in time [-/+]
X-Keywords: configuration [-/+] nsec_per_tick [-/+] SLEWALWAYS [-/+]
Eric Richer (richere@cae.ca) wrote:
: We have a time server hookep up to a GPS clock and many client
: workstations trying to sync to the server. If one client workstation
: was disconnected from the network, fell behind in time by 10 seconds and
: then reconnected to the network then it would try to re-sync with the
: server. We observed that the client would at one point jump forward in
: time by many seconds in one step. Our application running on the client
: workstation is very sensitive to big jumps (more than one second) in
: time either forward or backward.
: Does anyboby know if there is a switch or configuration parameter to
: prevent ntpd or xntpd on Unix from jumping forward in time or to limit
: the size of the step that it takes?
Howdy,
ntp_loopfilter.c shows compile switch SLEWALWAYS changes the program
to always use adjtime and never step the time.
For older versions, I think you add -DSLEWALWAYS to Config.local.
For the new xntp3-5.86, I think the ./configure --enable-slew-always
does the job. WARNING: I haven't tried either !
You could help your problem by keeping the clients clock closer to
the correct time. If xntpd kept running, I think it would continue
to adjust the drift. Various systems have tweaks to trim the clock
rate. In xntp land, tickadj can help. In Solaris 2.5 (except Ultra
and x86 versions ???) /etc/system nsec_per_tick can get you to within
a few ppm in a stable temperature. I think there are linux tricks, too.
Bruce Bartram bbartram@etl.noaa.gov
usual disclaimers apply
From: tgl@netcom.com (Tom Lane) [-/+]
Date: Fri, 11 Oct 1996 03:40:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How to prevent ntpd from jumping forward in time [-/+]
X-Keywords: SLEWALWAYS [-/+]
Eric Richer <richere@cae.ca> writes:
> If one client workstation
> was disconnected from the network, fell behind in time by 10 seconds and
> then reconnected to the network then it would try to re-sync with the
> server. We observed that the client would at one point jump forward in
> time by many seconds in one step.
As some other respondents pointed out, there's a compile time switch
to force large time corrections to be applied via slew rather than step.
However, making that change is putting a bandaid on the symptom, not
solving the real problem. If xntpd is configured and operating properly
it should never *get* so far off correct time.
If you anticipate losing communication with your primary time source,
you should configure your slave xntpds to use the system local clock
as a secondary time source (with a high stratum number of course,
maybe 10 or so). This is maybe not obvious. But if xntpd believes
it has *no* source of time, then it stops adjusting the system clock,
leaving you with essentially just your hardware clock. With the system
clock configured as a reference source, xntpd stays happy and will
keep adjusting your clock for the drift it previously measured against
the master time source.
Once you have a reasonably accurate drift number (this takes a few
hours or days of contact with the master server), you shouldn't ever
get more than a couple hundred msec off correct time, even after
disconnection intervals of many hours. Even el cheapo junk PCs
have clocks good enough for that.
You may need to also use "ntpdate" to get the local clock set accurately
at system boot, before you start xntpd and your clock-sensitive application.
I'd recommend leaving the SLEWALWAYS switch unset. It just masks
serious problems. Also, it takes a *long* time to close a 10-second
error via slewing...
regards, tom lane
From: bwb@etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Date: 18 Oct 1996 17:55:25 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: tickadj and ntp
X-Keywords: adjtimex [-/+] adjustment [-/+]
Andrej Borsenkow (bor@itsmx1.mow.sni.de) wrote:
:...
: What is normal range for drift value? E.g. I have two machines; one shows
: drift -1.306, another 99.130. I have no idea, which one is incorrect if
: any.
:
: And how should I change tickadj value? That is, when I add and when I
: subtract?
Howdy,
Drift values show the frequency offset between ntp (hopefully real)
time and the local host's clock. Units are roughly ppm (1 part / 2^20).
I think the drift adjustment is done each second, along with the
recent filtered error.
A large drift means that the the adjtime call tweaks the host's
time line and adds roughness to any use of that clock.
Tuning the clock to reduce the drift is critical only when the
drift is over a few hundred ppm or when xntpd has trouble.
Tuning the clock via tickadj works on some systems and not on
others. SunOS 4.1 is a typical tickadj example. tickadj -t 9999 or
tickadj -t 10001 changes the number of microseconds the OS
adds to the clock on each interrupt by 100 ppm. The default is 10000.
I'm told that on linux 2.0 systems, the adjtimex call in the OS
directly adjusts the inside of the clock and tickadj is not needed.
On Solaris 2.4, 2.5 (except Ultra and x86 platforms, tickadj
is replaced by chagnes to /etc/system. On my system, I fixed a
drift of 123 ppm to about +/- 2 ppm by adding one line and rebooting.
If it is easy to tune the system at 100 ppm, I'd do it to make
the time on the host a little smoother.
Bruce Bartram bbartram@etl.noaa.gov
Boulder, CO, USA usual disclaimers apply
From: david@djwhome.demon.co.uk (David Woolley) [-/+]
Date: Sun, 20 Oct 1996 12:46:57 GMT [-/+]
Newsgroups: comp.os.linux.misc,comp.protocols.time.ntp
Subject: Re: xntp 3.5f Compile Errors
X-Keywords: Linux [-/+] PLL [-/+]
In article <3267c9df.23127148@news2.cts.com>,
Dan Anderson <dan@bluebird.com> wrote:
>
>Perhaps the newest xntp doesn't work with the older Linux 1.2.13 and
>older gcc. I would try an older xntp (e.g., 3.5d ) or upgrade Linux to
>2.0.x.
3.5f works with kernel 1.2.13, provided you don't try to use a kernel PLL
(in which case it may do strange things, like bogus leap seconds).
--
David Woolley, London, England david@djwhome.demon.co.uk
(Sending any email to this site constitutes a licence to copy it to any
company which might reasonably be assumed to have transported it or
might reasonably be assumed to service any addresses quoted in it. 15Sep1996)
From: andreas@informatik.rwth-aachen.de (Andreas Fasbender)
Date: Fri, 18 Oct 1996 09:50:47 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: need some help
X-Keywords: delay [-/+] stability [-/+] synchronized [-/+]
In article <3265E375.18B5@turing.postech.ac.kr>, yhkwen
<yhkwen@turing.postech.ac.kr> wrote:
>My network is 10Mbps Ethernet.
>Hosts are Sun Ultra2, and Sun sparc20.
>Is it possible to synchronize these within 1ms without external
>reference clock?
Within a local area network, delays are in the range of some 1 or
2 ms, and very deterministic compared to wide-area internets. This
means, that the maximum observeable error for an ntp synchronized
network over an Ethernet (which is limited by the round-trip delay
in any case) is in the 1 ms range. Additional algorithms used by
ntp further decrease the clock errors, thus your envisaged accuracy
is certainly achieveable. Nethertheless, you will have to check the
stability of your Sun clocks to be sure.
I don't think you will find relieable statements like "accuracy is
below x ms in this and that evironment". Prove me wrong...
Regards,
Andreas
--
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
: Andreas Fasbender Tel: +49-241-80-21410 :
: Department of Computer Science Fax: +49-241-8888-220 :
: Informatik 4 (Communication Systems) :
: Aachen University of Technology :
: Ahornstr. 55 :
: D-52056 Aachen http://www-i4.informatik.rwth-aachen.de :
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
From: vjs@calcite.rhyolite.com (Vernon Schryver) [-/+]
Date: 21 Oct 1996 19:55:16 -0600 [-/+]
Newsgroups: demon.tech.unix,comp.unix.admin,comp.protocols.time.ntp
Subject: Re: Porting timed [-/+]
In article <54g7k8$43k@sol.ctr.columbia.edu>,
Zack Weinberg <zack@nutation.phys.columbia.edu> wrote:
> ...
>I'd be inclined to think that running timed and xntpd on the same system is a
>Bad Idea -- wouldn't they fight over the clock? ...
No, not if `timed` is run with "-F localhost" or "-F hostname",
where hostname is the primary name of the local host.
That is because `timed` will average only the ticks of the systems
named with -F or -G, and if it is averaging only the local ticks,
will never feel inclined to adjust the local clock.
As I keep saying, I know of between 10,000 and 20,000 computers in
a corporate internet that run this way, with some bunchs of IP
networks gatewaying using only `timed`, others using NTP, and still
others using an ancient hack called timeslave.
Vernon Schryver vjs@rhyolite.com