From: Robert Sexton <sextonr@squared.com> [-/+]
Date: Tue, 12 Nov 96 14:36:40 PDT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Target accuracies [-/+]
In Article<562950$e2f@lyra.csx.cam.ac.uk>, <nmm1@cus.cam.ac.uk> write:
> From: nmm1@cus.cam.ac.uk (Nick Maclaren)
<<< Rational Discussion of the big WHY? deleted >>>
> Speaking as a reluctant Unix system administrator, is there any GOOD
> reason that I should spend what is a lot of effort (and stress) in
> trying to do better than the figures I quoted above?
I get this question from time to time. My favorite answer is
'Because we can'. But seriously folks...
1. Ntp works across wan's
2. Ntp is more manageble than the 'sync and pray' method
3. Close sync of clocks allows for _very_ small adjustments. This leads to
more uniform time, eliminating large stepping of system clocks.
I have found that networks (ntp at least) syncronize better (more reliably,
more quickly, etc) when you use a uniform time source. The best way to get
this is with a radio or gps clock.
It's not quite so important that system clocks are within N seconds of the
correct time, but that they all agree with each other. Protocols like timed
(ntp's big competitor) use a strange concept known as network average time.
Its pretty tough to adjust an average time. With ntp, you sync your machines
in a well defined hierarchy, which is more easily managed. timed is easier to
setup, but it's not WAN comaptible, and its very tough to manage when it's not
doing what you want.
Just my $.02,
Robert Sexton
From: I.G.Batten@ftel.co.uk (Ian G Batten) [-/+]
Date: Wed, 13 Nov 1996 09:00:14 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Target accuracies [-/+]
X-Keywords: resolution [-/+]
In article <565ln3$ko2@overload.lbl.gov>,
Michael Helm <mike@fionn.lbl.gov> wrote:
> security services use time stamping as a pre-auth/prevent replay mechanism;
> the better the synchronization, the less risk
Although as shipping the relay windows are _huge_ --- it's a while since
I played with Sun's secure rpc, but I recall the clocks had to be
aligned to within ten minutes. I don't think Kerberos is more
restrictive.
> dfs servers don't like to be very far out of time synch (90 sec?). I
> think "ubik" or something else inside dfs gets unhappy when it finds a
> file server has drifted that far from what it thinks is the correct
> time. So if you have wide area dfs, you want to keep everybody close;
> 1 min is getting pretty close to the precipice.
We've got a distributed build thingie here; instead of having a monster
machine, we've got a pile of multiprocessor Sparc 20en FDDI'd to an
Auspex, shortly to move to a pile of multiprocessor Ultra 2en. We had
all sorts of weird little funnies, even though we were syncing with
rdate, in which a make would need to be run again to finish everything
off. Installing NTP made all those problems go away. Obviously, as
timestamps in the timesystem only have 1s resolution, the 5ms grouping
we're getting is overkill. But we're convinced it's A Good Thing, so as
part of the uplift we're buying a Motorola GPS box to tie everything
right down.
Besides, I can always fall back on my ``Piete Brooks says it's a good
idea'' policy, which has served me so well in the past.
ian
From: sam@cs.stir.ac.uk (Sam Nelson) [-/+]
Date: 13 Nov 1996 15:42:16 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Target accuracies [-/+]
X-Keywords: resolution [-/+]
In article <E0sx0G.IyL@ftel.co.uk>, I.G.Batten@ftel.co.uk (Ian G Batten) writes:
| In article <565ln3$ko2@overload.lbl.gov>,
| Michael Helm <mike@fionn.lbl.gov> wrote:
| > security services use time stamping as a pre-auth/prevent replay mechanism;
| > the better the synchronization, the less risk
|
| Although as shipping the relay windows are _huge_ --- it's a while since
| I played with Sun's secure rpc, but I recall the clocks had to be
| aligned to within ten minutes. I don't think Kerberos is more
| restrictive.
|
I must admit I've never used it in earnest, but I thought the point with
Kerberos was that the tighter your clock-synch window, the better it worked:
if true, this would be a `works indefinitely' argument for better clock synch.
I could be miles off, of course.
| off. Installing NTP made all those problems go away. Obviously, as
| timestamps in the timesystem only have 1s resolution, the 5ms grouping
| we're getting is overkill. But we're convinced it's A Good Thing, so as
| part of the uplift we're buying a Motorola GPS box to tie everything
| right down.
|
It gives you `synchronisation redundancy': if you can _usually_ get 5ms and
you need 0.5s or so, you've two whole orders of magnitude's worth of badness
to descend through before you need to start worrying. And since it doesn't
take all that much work to get to a 5-10ms window, why not?
| Besides, I can always fall back on my ``Piete Brooks says it's a good
| idea'' policy, which has served me so well in the past.
|
This is of course the Ultimate Internet Protocol Argument, on a par with
mentioning the H-word to kill a thread. QED :-)
--
Sam. Scunthorpe! (Insert bandwidth-wasting disclaimer here)
To call something blue when it's not we defile it,
But oh what the heck, it's hard to rhyme 'violet'.
From: shields@crosslink.net (Michael Shields) [-/+]
Date: 14 Nov 1996 23:32:12 -0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Target accuracies [-/+]
X-Keywords: synchronized [-/+]
In article <E0sx0G.IyL@ftel.co.uk>, Ian G Batten <I.G.Batten@ftel.co.uk> wrote:
> Although as shipping the relay windows are _huge_ --- it's a while since
> I played with Sun's secure rpc, but I recall the clocks had to be
> aligned to within ten minutes. I don't think Kerberos is more
> restrictive.
A typical default for Kerberos is five minutes but you can set it closer.
Since I have all clocks NTP-synchronized, I set the bound to five seconds
and that has not caused any problems.
--
Shields, CrossLink.
From: Harlan Stenn <harlan@brown.pfcs.com> [-/+]
Date: 11 Nov 1996 01:54:14 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: New directory on louie
X-Keywords: DES [-/+] keytype [-/+]
I suggest you ask Dave about the export situation.
I know that Real Soon Now we plan to lose DES support entirely.
The current releases of xntp3-5.x default to MD5, and you have to specify
"keytype des" before you use a DES key.
H
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 12 Nov 1996 10:00:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: looking for DCF77, GPS or similar clock for 3.5f [-/+]
X-Keywords: antenna [-/+] DCF77 [-/+] HP-UX [-/+] Meinberg [-/+]
We are using a Meinberg PZF535 with the HP-UX version. If you can have
an antenna "looking at the sky" I would recommend a GPS receiver,
because the PC monitors at 800x600 send almost in the very same
frequency as the DCF77. If you can avoid having PCs near the antenna,
it will work fine though.
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]
Date: Fri, 15 Nov 1996 08:45:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: looking for DCF77, GPS or similar clock for 3.5f [-/+]
X-Keywords: Datum [-/+] DCF77 [-/+] HP-UX [-/+]
In article <1996Nov8.014446.4819@sgcl1.unisg.ch>, David-Michael Lincke (dlincke@bandon.unisg.ch) writes:
>Why are looking for a reference NTP reference clock. Since we are located
>in europe (switzerland) I guess a DCF77 receiver would be most
>appropritate. We are open to any other solutions, though, GPS or whatever...
>The clock will have to be able to cooperate with xntpd 3.5f (preferably the
>version recently released by HP as an HP-UX patch) and a HP9000 K200
>running HP-UX 10.20.
>Any suggestions and pointers are most welcome.
David,
Why not consider Datum's "standalone" GPS Time Server model
TS2100. Very simple to install and use (GPS in - Ethernet out).
Contact them at sales@datum.com or phone: ++1 408 578 4161. Not
sure who their rep is in Switzerland.
Good Luck
Rob Kimberley
Sematron UK Limited
Home : robk@oldtimer.win-uk.net
Office: rkimberley@sematron.demon.co.uk
From: Christopher Davis <ckd@loiosh.kei.com>
Date: 13 Nov 1996 15:46:59 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SunOS error: ntp/udp: unknown service
X-Keywords: bug [-/+]
AS> == Alan Strassberg <alan@bali.seg.wj.com>
AS> Getting this error on SunOS 4.1.3 (and 4.1.4) with xntpd 3.5f
AS> when I try to run xntpdc:
AS> xntpdc: ntp/udp: unknown service
AS> ntp looks fine in /etc/services. xntpd is running fine.
AS> What did I miss ?
You probably have ntp/tcp in /etc/services (or the services NIS map) but
not ntp/udp. (SunOS ships with the former only.)
Another possibility is the good old "blank lines or extraneous spaces in
the services file confuses the NIS services map" bug.
--
Christopher Davis <ckd@kei.com> <URL: http://www.kei.com/homepages/ckd/ >
"I conclude that the CDA is unconstitutional and that the First Amendment
denies Congress the power to regulate protected speech on the Internet."
-- Judge Stewart Dalzell in _ACLU v. Reno_
From: "Steve Mihelic" <arbiter@arbiter.com> [-/+]
Date: Tue, 19 Nov 1996 08:02:15 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Buying a local time source
X-Keywords: Arbiter [-/+] arbiter [-/+]
> Chris Maguire <maguirec@mindspring.com> wrote in article
<328A8135.195D@mindspring.com>...
> I would like any basic advice or pointers to shopping for a local time
> source. I'm interested in something relatively low cost to attach to a
> SPARC, and I have no idea where to start.
>
> Any help is much appreciated.
>
> Regards,
>
> Chris Maguire
>
> cmaguire@kmwg.com
>
Chris,
Arbiter Systems presently offers four different models of GPS
Satellite-Controlled Clocks that vary in price and performance. For more
information you can visit our website at "http://www.arbiter.com" or
contact us directly at:
Arbiter Systems, Inc.
P.O. Box 2279
1324 Vendels Circle, Suite 121
Paso Robles, CA 93447
Phn: 1-800-321-3831
+1-805-237-3831
Fax: +1-805-238-5717
arbiter@arbiter.com
We will be glad to answer any questions that you have.
Steve Mihelic
Applications Engineer
Arbiter Systems, Inc.
From: Chris Maguire <maguirec@mindspring.com>
Date: Thu, 14 Nov 1996 12:41:20 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: SunExpert magazine article on NTP [-/+]
X-Keywords: configuration [-/+] dialup [-/+]
In the October 1996 issue of "SunExpert" magazine, there is an article
on page 26, entitled "Tempus Fugit". The author offers the opinion
that:
"The downside of NTP is that it demands that you are permanently
connected to the Internet because the server sends regular packets out
to its peers performing time synchronization. When my site was
connected to the Net via ISDN, I needed to minimize connection time
because ISDN connections are charged per minute like a regular telephone
call. TCP/IP over ISDN would time out after some period of inactivity,
but I didn't feel it was possible to use NTP because it would have kept
the ISDN connection up for much of the day. Such frequent connection
would be prohibitively expensive in the UK."
I find my self in a situation where I am considering the configuration
that the author decided against. And naturally, being told I can't do
something I want to do makes me want to do it that much more. We have
only got a dialup ISDN connection.
I would like to understand a few things about this opinion:
My understanding is that on a machine running xntp it will gradually
improve the accuracy of the clock. And that at some point a clock that
has been corrected with xntp will run accurately on it's own, without an
external, accurate source, for an extended period of time. What I don't
understand is how long that takes, and how frequently it needs to get
the correct time from accurate machines to achieve that accuracy.
Q: Do people agree with the author's opinion?
Q: Could I for example, expect to connect to the Internet for a
few hours once a week (rebooting the machine once each week).
Q: How often would an XNTP server send packets out over the
ISDN connection?
Is it every 30 seconds, minute, five minutes, hour, etc.?
Q: Is this adjustable?
Could I make do with forcing XNTP to check less frequently?
Thank you for your help.
Regards,
Chris Maguire
cmaguire@kmwg.com
From: j.b.swenker@ptt-telecom.nl (johan swenker)
Date: Fri, 15 Nov 96 09:03:57 WET [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SunExpert magazine article on NTP [-/+]
X-Keywords: configuration [-/+] DCF [-/+] dialup [-/+] documentation [-/+] synchronised [-/+]
In article <328B59C0.6658@mindspring.com>, maguirec@mindspring.com
says...
>
>In the October 1996 issue of "SunExpert" magazine, there is an article
>on page 26, entitled "Tempus Fugit". The author offers the opinion
>that:
>
>"The downside of NTP is that it demands that you are permanently
>connected to the Internet because the server sends regular packets out
>to its peers performing time synchronization. When my site was
>connected to the Net via ISDN, I needed to minimize connection time
>because ISDN connections are charged per minute like a regular telephone
>call. TCP/IP over ISDN would time out after some period of inactivity,
>but I didn't feel it was possible to use NTP because it would have kept
>the ISDN connection up for much of the day. Such frequent connection
>would be prohibitively expensive in the UK."
>
>I find my self in a situation where I am considering the configuration
>that the author decided against. And naturally, being told I can't do
>something I want to do makes me want to do it that much more. We have
>only got a dialup ISDN connection.
>
>I would like to understand a few things about this opinion:
>
>My understanding is that on a machine running xntp it will gradually
>improve the accuracy of the clock. And that at some point a clock that
>has been corrected with xntp will run accurately on it's own, without an
>external, accurate source, for an extended period of time. What I don't
>understand is how long that takes, and how frequently it needs to get
>the correct time from accurate machines to achieve that accuracy.
>
> Q: Do people agree with the author's opinion?
I disagree. NTP does NOT demand that I am permanently connected to the
Internet. It only needs a permanent connection to an accurate clock.
Radio clock receivers like rugby, dcf and gps come into mind. DCF
receivers fo PC's cost less than $100. (I bought mine for 110 dutch
guilders)
>
> Q: Could I for example, expect to connect to the Internet for a
> few hours once a week (rebooting the machine once each week).
Probably not when you reboot once a week. The documentation speeks about
'days to synchronize'. I have been toying with 2 linux systems, say A and
B (with very inaccurate PC-clocks). In the beginning B requested the time
every minute. After a day B only needed the time once every 16 minutes
(more precise 2^10 sec).
[Strictly speaking probably yes: you only need a few seconds to send and
recieve the ntp-packets. There are thousends of 'few seconds' in 'few
hours']
>
> Q: How often would an XNTP server send packets out over the
> ISDN connection?
>
> Is it every 30 seconds, minute, five minutes, hour, etc.?
>
Strongly depends on the quality of your clock. And whether the clock is
synchronised already.
> Q: Is this adjustable?
It is not simply adjustable. It computes optimal values by itself.
>
> Could I make do with forcing XNTP to check less frequently?
May be you could play it a trick.
>
>Thank you for your help.
>
>Regards,
>
>Chris Maguire
>cmaguire@kmwg.com
--
Johan Swenker Phone:+31 50 5855257 E-mail:J.B.Swenker@PTT-Telecom.nl
DISCLAIMER: This statement is not an official statement from, nor does
it represent an official position of, PTT Telecom BV.
From: Harlan Stenn <harlan@brown.pfcs.com> [-/+]
Date: 16 Nov 1996 18:32:07 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SunExpert magazine article on NTP [-/+]
X-Keywords: dial [-/+]
I use NTP on a demand-dial PPP network and it works just fine.
The server talks to "outside" time sources when the line is up, and believes
itself when the link is down.
I don't permit NTP packets to either start the dialout connection or keep the
connection "alive".
When the PPP connection is made, NTP notices in fairly short order.
H
From: david@djwhome.demon.co.uk (David Woolley) [-/+]
Date: Sat, 16 Nov 1996 22:59:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SunExpert magazine article on NTP [-/+]
X-Keywords: configuration [-/+] dial [-/+] UDP [-/+]
In article <328B59C0.6658@mindspring.com>,
Chris Maguire <maguirec@mindspring.com> wrote:
> Q: How often would an XNTP server send packets out over the
> ISDN connection?
>
> Is it every 30 seconds, minute, five minutes, hour, etc.?
With a default configuration, any power of two interval from 64 to 1024
seconds depending on how accurate it considers the clock to be. NB
you must bring the link up before it polls, as the dial on demand setup
time is likely to completely ruin the timing, even if the UDP packet is
eventually sent. This will be your worst problem.
It will start at 64 and extend to 1024 if things are good. If you have
a significant room temperature change, it may well collapse back to 64
again.
> Q: Is this adjustable?
You can set the upper and lower limits. I think the absolute limit is
16384 seconds.
> Could I make do with forcing XNTP to check less frequently?
I have a feeling that it will have difficulty achieving a lock the
or will be unstable once locked.
There are drivers for dial up modem services which are intended for this
sort of use, although I would suggest that the pay back time for a basic
radio clock would be short. I am not entirely convinced that the dial up
clock mode works properly in current versions.
--
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: Metod Kozelj <metod.kozelj@rzs-hm.si> [-/+]
Date: Mon, 18 Nov 1996 14:53:39 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SunExpert magazine article on NTP [-/+]
X-Keywords: maxpoll [-/+] minpoll [-/+]
>> Q: Is this adjustable?
>
> It is not simply adjustable. It computes optimal values by itself.
Actually it is adjustable to some extent. It is true, that xntpd
computes values by itself, but by default they fall into interval from
2^^6 to 2^^10 seconds (ie, they can have values of 64, 128, 256, 512 or
1024 seconds). But you can allways change this interval using 'minpoll
<n>' and 'maxpoll <n>' commands.
This way, you can force minimal interval between two polls to anything
(say 2^^1 = 2048 seconds). Of course, this would cause daemon to
syncronize quite lot later.
With kind regards,
e-mail: Metod.Kozelj@rzs-hm.si
WWW: http://www.rzs-hm.si/people/Metod.Kozelj/
From: Metod Kozelj <metod.kozelj@rzs-hm.si> [-/+]
Date: Tue, 19 Nov 1996 14:08:22 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Firewalls
X-Keywords: firewall [-/+] peer [-/+] UDP [-/+]
tomb@dgtl.com wrote:
>
> I'm trying to connect to an external time source; I've allowed UDP port 123
> through the firewall but am not connecting- I can run ntpdate -d and see
> five transmits, no receives and the error "no suitable server". Any tips?
> (note my internal systems can peer each other fine). I've tried multiple
> sites. What simple item am I missing? TIA.
When running ntpdate with switch '-d', it uses non-privileged ports and
not the standard one. Try running it without that switch and see what
happens.
Hope this helps.
--
Metod Kozelj
e-mail: Metod.Kozelj@rzs-hm.si
WWW: http://www.rzs-hm.si/people/Metod.Kozelj/
From: bwb@etl.noaa.gov (Bruce (303) 497-6217) [-/+]
Date: 19 Nov 1996 18:20:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp3.5 ntp.drift 666 perms? [-/+]
X-Keywords: prefer [-/+]
Howdy,
You asked about ntp.drift file permissions. I had the same behaviour.
xntpd creates ntp.drift every hour as it writes it. To make the
permissions stay different, you should add a "umask 022" line to the
launching script.
I think such a umask might be valuable very early in the rc.local
(or whatever), since this might effect other daemons.
Bruce Bartram bbartram@etl.noaa.gov
usual disclaimers apply
-----
Roger Books (books@rtssec1.dms.state.fl.us) wrote:
: I'm running into an odd thing. My ntp.drift file has perms of 0666, I
: would prefer not to have system files writable by world. Is this something
: I have configured wrong or is it a problem? I tried setting permissions
: to be 644 (rw-r--r--) but it soon changed itself back to 666.
: Roger
From: "John R. DeWolfe" <john@internetone.com>
Date: Tue, 19 Nov 1996 16:27:56 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp3.5 ntp.drift 666 perms? [-/+]
X-Keywords: prefer [-/+]
Roger Books wrote:
>
> I'm running into an odd thing. My ntp.drift file has perms of 0666, I
> would prefer not to have system files writable by world. Is this something
> I have configured wrong or is it a problem? I tried setting permissions
> to be 644 (rw-r--r--) but it soon changed itself back to 666.
>
I ran into this problem myself. I originally modified the source
code to fix this, but after a couple of revisions gave up on it.
I have recently come across a better solution. If you are running
a System V Unix (like Sun Solaris) simply put a "umask 022" line in
the appropriate startup file. This fixed it for me. This is
probably applicable to other Unix's as well. I was told that xntp
simply uses the umask it inherits at startup time.
--
----------------------------------------------------------------------------
John R. DeWolfe email : John.DeWolfe@InternetOne.COM
Network Engineer voice : (303) 444-1993
Internet One, Inc. fax : (303) 440-4264
From: "Steve Mihelic" <mihelic@tcsn.net> [-/+]
Date: Tue, 3 Dec 1996 18:03:06 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: GPS vs. WWVB as a stratum 1 source?
X-Keywords: antenna [-/+] Arbiter [-/+] arbiter [-/+] SGI [-/+] WWVB [-/+]
Brian,
The GPS system is a much higher performance system (100ns with SA on vs
10ms, typical), more reliable and less prone to interference. The
drawbacks of GPS clocks are the price and the need to have an external
antenna with a clear view of the sky (skylights work). WWVB clocks do not
require an antenna and are less expensive, but are very sensitive to
eletronic interference. Arbiter Systems (www.arbiter.com) manufactures
GPS clocks that range in accuracy from 1ms to 100ns worst case at prices
starting under $1,000.00 to a couple thousand dollars. If you can afford
the price of a GPS receiver, it is a better timing sloution, but only the
end user can determine if the accuracy is needed or worth the additional
cost.
Steve Mihelic
Arbiter Systems, Inc.
arbiter@arbiter.com
> What are the relative pros and cons of a GPS receiver vs. a WWVB
> receiver as a stratum 1 time source? Is the higher price of the GPS
> receiver justified by a greater accuracy, and if so how much more
> accurate is it?
>
> (If it matters, it'll be connected to an SGI Indy running a recent-ish
> xntpd).
From: bwb@etl.noaa.gov (Bruce (303) 497-6217) [-/+]
Date: 4 Dec 1996 21:17:56 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Previous time adjustment incomplete?
X-Keywords: adjustment [-/+] calendar [-/+] dosynctodr [-/+] FAQ [-/+] nsec_per_tick [-/+] reset [-/+]
Savvas Pissarides (s.pissarides@resonet.com) wrote:
: I now that this question has been asked many times in the FAQ but I am not
: sure if it is normal to get few of these messages. I am running SUNOS 5.5.1
: on a SPARC5 and I am getting the following once a day:
: Dec 4 08:50:43 oxygen xntpd[814]: time reset (step) 1.408403 s
: Dec 4 08:50:46 oxygen xntpd[814]: Previous time adjustment incomplete;
: residual
: 0.003750 sec
: Dec 4 08:50:47 oxygen xntpd[814]: Previous time adjustment incomplete;
[SNIP]
: I am only using tickadj -s without any -t value.
: And again what is a normal drift value? My drift value is -66.661.
: HELP!
: Savvas Pissarides.
: Bell Canada.
: email: S.Pissarides@resonet.com
Howdy,
Solaris 2.5 (SunOS 5.5) needs a few lines in /etc/system instead
of tickadj -s to disconnect the clock/calendar chip. After adding
the new lines, you will need to reboot to make them take effect.
Bruce Bartram bbartram@etl.noaa.gov
usual disclaimer apply
----- lines for ntp in Solaris 2.4, 2.5x /etc/system
* Changes to sparc solaris 2.5 /etc/system for Network Time Protocol
* Remove if xntp is taken off this host.
* 1) Set the system variable dosynctodr to 0 to disable the system
* from calling adjtime to keep the system clock to the hardware
* clock/calendar chip. xnptd will control clock now.
set dosynctodr = 0
* 2) Adjust the nsec_per_tick variable to trim the clock frequency.
* After xntpd has been running smoothly, I averaged ome of the
* drifts. A reported drift of +132.5 parts per 2^20 makes a
* change of +1264 added to the default 10000000 nsec_per_tick.
* Sign of drift: + means local clock is slow so add nsec each tick.
* set nsec_per_tick to 10^7 + (drift * 9.537)
* I think the first try should get to within a few ppm.
* This trick came from the comp.protocols.time.ntp newsgroup.
* Reported to NOT work on x86 and Ultra 2.5x versions.
set nsec_per_tick = 10001264
* end of xntp section
-----
More details sent by email
From: Jim Reid <rid@heron.pst.cfmu.eurocontrol.be> [-/+]
Date: 06 Dec 1996 10:41:00 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Inexpensive reference clock in the UK
X-Keywords: DCF [-/+] prefer [-/+] Trimble [-/+]
terry@ppsl.demon.co.uk (Terry Glanfield) writes:
> I'm looking to acquire an inexpensive reference clock to synchronise a
> network of Suns during periods when they are not connected to the
> internet. I'd prefer sources in the UK.
You can buy a Trimble GPS receiver for about 600 quid. MSF clocks
should be avoided unless you're prepared to spend a couple of thousand
pounds to get one that has a decent quartz oscillator that will keep
good time when the transmitter is off air. Beware of cheap MSF clocks:
they are susceptible to electromagnetic interference from things like
computers. DCF receivers may be worth considering if you're in range
of the Frankfurt transmitters, but the Trimble GPS box would seem to
be the best choice for accuracy and cost.
No matter what you buy, make sure the signal can be picked up reliably
before you part with any cash. Computer rooms can be stern tests for
radio receivers. Your premises could also be in a reception dead spot.
From: ltso@phoenix.london.waii.com (Marc Brett) [-/+]
Date: 10 Dec 1996 13:33:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Setup Help
X-Keywords: fudge [-/+]
James,
The syntax for setting up a local clock varies depending on the vintage
of your xntp software. You also should set the stratum level to a high
number (eg. 10) to indicate the accuracy of the source is not as good as
a radio clock (stratum 0).
The old syntax is:
server 127.127.1.10
The new syntax is:
server 127.127.1.0
fudge 127.127.1.0 stratum 10
campbell james b0159 (campbelj@escmail.orl.mmc.com) wrote:
> Hi,
> I'm trying to setup ntp to be used by 4 machines (and those 4 only) on
> a large network. There is no accurate time source available, so I would
> like to use one of the four machines as the reference clock and have the
> others sync to it. The important thing for us is that the clocks are
> consistent, but not necessarily accurate. It is also important that we
> do not interfere with the other machines on the network.
> I'm running OSF. A copy of ntp comes with the distribution, and it is
> already available for use.
--
Marc Brett Marc.Brett@waii.com
Western Geophysical Tel: +44 181 560 3160 ext. 4178
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 21 Dec 1996 11:37:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNTP for UNIX
X-Keywords: SNTP [-/+]
In article <32B70B20.2223@net.HCC.nl>,
Rob Visser <Rob.Visser@net.HCC.nl> wrote:
>
>I am looking for an implemetation of SNTP running on UNIX.
>Does anyone have an URL for this ?
No. But you could look at dist/msntp-1.1.tar (or something like it)
on oozelum.csi.cam.ac.uk with anonymous FTP :-)
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: alan@bali.seg.wj.com (Alan Strassberg)
Date: 23 Dec 1996 19:04:23 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp client for NetWare 4.X [-/+]
In article <32B50C1D.7547@genta.net>, <s@genta.net> wrote:
>Is there the NTP client for NetWare 4.X ?
>
>I found a note about RDATE.NLM (for NetWare 386 ?)
>but I cannot reach that entity.
rdate.zip can be found at ftp://netlab2.usu.edu/misc/rdate.zip
alan
--
alan@wj.com
From: jrd@cc.usu.edu (Joe Doupnik) [-/+]
Date: 25 Dec 96 19:12:43 MDT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp client for NetWare 4.X [-/+]
In article <59nh7n$efk@bali.seg.wj.com>, alan@bali.seg.wj.com (Alan Strassberg) writes:
> In article <32B50C1D.7547@genta.net>, <s@genta.net> wrote:
>>Is there the NTP client for NetWare 4.X ?
>>
>>I found a note about RDATE.NLM (for NetWare 386 ?)
>>but I cannot reach that entity.
>
> rdate.zip can be found at ftp://netlab2.usu.edu/misc/rdate.zip
>
> alan
> --
> alan@wj.com
-----------
Correct. Also note that editions of TCPIP.NLM later than about
Jan 96 have changed internals enough to prevent rdate from running. That
means if you run those later NLMs then you are stuck with the PC clock
for the whole directory services tree. An NTP client NLM is badly needed
for NetWare.
Joe D.
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Thu, 26 Dec 1996 14:39:37 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: ntp client for NetWare 4.X [-/+]
X-Keywords: Novell [-/+] release [-/+] SNTP [-/+]
Joe Doupnik wrote:
>
> In article <59nh7n$efk@bali.seg.wj.com>, alan@bali.seg.wj.com (Alan Strassberg) writes:
> > In article <32B50C1D.7547@genta.net>, <s@genta.net> wrote:
> >>Is there the NTP client for NetWare 4.X ?
> >>
> >>I found a note about RDATE.NLM (for NetWare 386 ?)
> >>but I cannot reach that entity.
> >
> > rdate.zip can be found at ftp://netlab2.usu.edu/misc/rdate.zip
> >
> > alan
> > --
> > alan@wj.com
> -----------
> Correct. Also note that editions of TCPIP.NLM later than about
> Jan 96 have changed internals enough to prevent rdate from running. That
We use RDATE on an updated 4.10 server, it seems to run very nicely, but
I haven't checked which exact TCPIP version we have.
...
I have just RCONSOLE'd into the server from home, and you're right, the
TCPIP.NLM on this server is indeed from before Jan 96. I'll make a note
of this porblem though, thanks!
> means if you run those later NLMs then you are stuck with the PC clock
> for the whole directory services tree. An NTP client NLM is badly needed
> for NetWare.
The latest info/rumours I have from Novell sources say that an upcoming
release of NetWare will be based on NTP, or at least make it an option
to use NTP instead of TIMESYNC to synchronize the tree.
I was going to port a version of SNTP to NetWare, but have decided to
wait and see for a while longer, hoping that Novell does follow up on
this.
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: Jim Reid <rid@heron.pst.cfmu.eurocontrol.be> [-/+]
Date: 27 Dec 1996 10:55:11 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Troubels with ntpdate on HP 9000/435T HP-UX 9.10
X-Keywords: adjtimed [-/+] HP-UX [-/+]
stanb@netcom.com (Stan Brown) writes:
> I am having a problem getting ntpdate to work properly on my 435T wiht
> 9.10. I recall that 9.x HP-UX doesn;t have the adjtime call but this
> doesn;t seem to be the problem. ntpdate will step the machines
> clock if it's off by more than 1/2 second, so it should be doing this.
>
> I suspect a permissins poblem based upon the folowing transcript.:
.... verbose irrelevance deleted ....
> 26 Dec 09:53:24 ntpdate[25661]: Can't adjust the time of day: No such file or directory
As you rightly say, HP-UX 9 does not have the adjtime() system call.
ntpdate will set the clock if it's off by more than half a second. It
just calls settimeofday() rather than step it with adjtime(), which
HP-UX 9 doesn't have anyway.
To get round this HP brain-damage, xntpd comes with a program called
adjtimed. xntpd speaks to this through SysV message queues (shudder!)
via a dummy adjtime() call. Instead of making a system call, the dummy
one does some SysV IPC to tell adjtimed to poke bits of /dev/kmem,
patching the kernel variables used to maintain time. This ugliness
fakes the functionality of adjtime to keep the clock synced. [Yes,
it's a truly horrid hack. Thank you HP.] ntpdate also gets this fake
adjtime() call.
So having explained the problem, now to answer your question. Before
starting xntpd (or making small clock adjustments with ntpdate), you
must start adjtimed on HP-UX boxes. [Not on those running HP-UX 10
which has adjtime as a system call, around a decade after it first
appeared in BSD. Sigh.] If not, when the dummy adjtime() call is
invoked by xntpd or ntpdate, it will get the error ENOENT - No such
file or directory - because the SysV message queue it needs hasn't
been created by adjtimed. Yes, this is confusing because the SysV IPC
objects are not files, but that's SysV IPC for you.....
BTW, if it had been a permission problem, you would have got the error
EPERM or EACCES return - "Not super-user" or "Permission denied"
respectively. Since xntpd runs as root - you have to be root to get
the adjtime system call to work (or have something scribble in
/dev/kmem) - you shouldn't be getting permissions problems anyway.