From: jon@oaktree.co.uk (Jon Ribbens)
Date: 22 Oct 1996 13:37:42 GMT [-/+]
Newsgroups: demon.tech.unix,comp.unix.admin,comp.protocols.time.ntp
Subject: Re: Porting timed [-/+]
X-Keywords: restrict [-/+]
Zack Weinberg <zack@nutation.phys.columbia.edu> wrote:
> Your ntp.conf looks fine to me.
>
> What OS are you running? xntpd needs a cooperative kernel (as does timed,
> actually). In particular, you may need to tweak the 'tickadj' parameter;
> there is a program, tickadj, included in the distribution that will help.
> You must also tell the kernel not to slave the software clock to the
> hardware clock, otherwise xntpd (or timed, for that matter) will do no
> good at all. tickadj does this too.
I've managed to get it working now by taking out the 'restrict' lines.
(I'm using NetBSD 1.1.)
> 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? I personally run an ntpd
> with all the refclocks compiled out on each machine, and point them all at
> one machine that then queries the servers.
If I'm understanding 'timed's gibberish man page correctly then
doing 'timed -M -F <localhost>' makes timed just act as a server,
and not affect the local machine's clock at all. You can then just
run 'timed' on other machines on the same network and they will
all sync to the machine running -M (which is also running xntpd).
Cheers
Jon
____
\ // Jon Ribbens //
\// jon@oaktree.co.uk //
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 23 Oct 1996 09:57:01 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP newbie
X-Keywords: authentication [-/+] controlkey [-/+] password [-/+] requestkey [-/+] trustedkey [-/+]
In article <54br55$vp@jerry.loop.net> brooks@loop.com (Brooks Graham) writes:
> Lastly, in reading the documents which come with the standard
> distribution, I see that there is authentication and restriction
> mechanisms in xntpd. Although I can't tell for sure, it appears
> that if I don't specifically mention any restrictions in the
> ntp.conf, that by default, xntpd will not allow any runtime config
> changes apart from those made at localhost. This is what I want.
> Am I correct?
If you want to do runtime reconfiguration you'll have to create one
key (type 'A') and specify it as controlkey, trustedkey and
requestkey. I'm not sure whether you need all of them right now, but
it will work. You'll be asked for a key and a password in xntpdc...
From: Robert Sexton <sextonr@squared.com> [-/+]
Date: Fri, 25 Oct 96 10:09:19 PDT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP newbie question [-/+]
X-Keywords: fudge [-/+] peer [-/+] precision [-/+] stability [-/+]
In Article<326F1FF4.2D51@apogee-com.fr>, <zwobada@apogee-com.fr> writes:
> What do you do, guys, for a large site with no Internet access ?
> (Suppose this is a Campus network) Do you install one high precision
> clock ? More than one, peering with each other ?
> If you have several sites interconnected by some leased lines, do
> you put clocks in the biggest sites, for example ?
<Insert usual "I'm not an expert" Disclaimer>
ntp is pretty tolerant, and will work just fine with non-optimal networks.
The scenario I am using now involves a hierarchy of stratum pools.
Design goals:
a. Everything is hierachical, to spread the load.
b. everything is based upon threes, to simplify clock selection
c. extensibility is a good thing.
d. The groupings below are based upon a peer group size of 6. I don't
believe there is anything magical about this number. Others may want to
comment on the virtues of larger and smaller peer groups.
e. Network traffic should be minimized.
<Stratum N Layer>
1. Pick three good machines. These are your reference clock servers.
Machines in environmentally controlled rooms seem best.
Set them all at different strata by fudging the localclock.
DO NOT set them to the same strata! If you do, your network will not be
stable! There needs to a final authority on the time, as per the ntp design.
That way, if your stratum 7 localclock goes toes up, everybody will follow the
stratum 8 clock, etc. More importantly, this will cause the stratum 8 clock
to sync to the stratum 7 clock, so when there is a problem, there will not be
a substantial difference in the percieved time. When/If you get a radio
clock, you attach it to one of these three machines. No other changes
necessary.
<Stratum N+1 Layer>
2. Group your servers into 3 sets of six or so machines. These machines peer
with each other, and are responsible for the brunt of the time sync duties.
These machines are clients to all three reference time servers, so their
ntp.conf's look like this:
server reference 1
server reference 2
server reference 3
peer buddy 1
peer buddy 2
peer buddy 3
peer buddy 4
peer buddy 5
peer buddy 6
<Stratum N+2 Layer>
3. Group remaining machines into groups of 6, and setup as in step 2.
Within each cell, all machines peer with each other, and server off of three
machines in the N+1 Layer. If possible, each server should come from a
different N+1 time group. Add as many N+2 groups as you wish.
As for network topology, you can move around your peer groups to suit your
WAN. By placing machines in peer groups, you make things more robust, and
reduce network traffic. In our case, we have lots of machines at the far end
of T1 and slower links. It's a star topology. In this case, the isolated
machines do not belong to peer groups.
As for running off of local clocks instead of the real thing, it works OK.
>From what I have learned, the primary benefit from using a radio time source
is not that it gives you accurate time, but that it gives you _Uniform_ time.
Erratic time sources cause problems with syncronization. I suspect thats why
climate control is such a help for clock stability. One other thing you can
do is to manually tune the clock on your reference machine by adding ppm with
the fudge command. Set the clock by eyeball and wristwatch, and then
determine the drift of the clock manually by calculating seconds/day of drift
from the correct time. Convert this to ppm, and Voila! clock accuracy thats
measured in seconds/month.
Best of Luck,
Robert Sexton.
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 26 Oct 1996 10:09:53 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP newbie question [-/+]
X-Keywords: FAQ [-/+] prefer [-/+]
In article <NEWTNews.846266393.120.robert@pc398.cis.squared.com> Robert Sexton <sextonr@squared.com> writes:
> Set them all at different strata by fudging the localclock.
>DO NOT set them to the same strata! If you do, your network will not be
>stable! There needs to a final authority on the time, as per the ntp design.
>That way, if your stratum 7 localclock goes toes up, everybody will follow the
>stratum 8 clock, etc. More importantly, this will cause the stratum 8 clock
>to sync to the stratum 7 clock, so when there is a problem, there will not be
>a substantial difference in the percieved time.
Just a note (I believe this is also in the FAQ, wherever it is): The
stratum difference should be at least 2. Otherwise, e.g. in your
example, as the server with a local clock at 7 will announce itself as
stratum 8, the server with the local clock at 8 will have two stratum
8's to choose from, and just might prefer its local clock - which was
exactly what you wanted to avoid.
This *may* not be necessary in recent releases of xntp, as there have
been some changes to make a local clock less preferable than it would
"normally" (based on stratum etc criteria) be (e.g. the most annoying
fact that you have to mark it as "prefer" if you want it to be the
potential base for broadcasts) - but I'd still recommend using this as a
design principle, you never know when the rules may change again!:-)
--Per Hedeland
per@erix.ericsson.se
From: ekilroy@orbitsw.com (E.A. Kilroy, III)
Date: Thu, 31 Oct 1996 05:09:35 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP server software for WindowS NT 3.51
X-Keywords: SNTP [-/+] Tardis [-/+] TCP [-/+]
Greg Schueman <schueman@ix.netcom.com> wrote:
>Bill Hempy wrote:
>>
If you don't truely need full NTP functions and accuracy, try Tardis
~from:
It has NT (with control panel), Win95, and WFW versions. NT and Win95
provide both client and server SNTP, Time/UDC & TCP. Shareware for
$20 each.
e.a.
>Try my site (soon to be gone) for what you need. Some of what you need
>is probably
>there, as I haven't cleaned it up in a while.
> ftp://ftp.digex.net/pub/access/schueman/ntp
>-Greg
From: per@erix.ericsson.se (Per Hedeland) [-/+]
Date: 25 Oct 1996 21:24:37 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Trimble Acutime II GPS and xntp [-/+]
X-Keywords: PPS [-/+] Trimble [-/+]
Although I've used xntp with great success (and some rather weird
configs:-) for many years, this is my first venture into the world of
*real* clocks, so I guess these are newbie questions in that area...
- even partial answers would be very much appreciated.
For various reasons, others in my company think that the Trimble Acutime
II GPS antenna/receiver (see
http://www.trimble.com/products/catalog/pd_om002.htm) is a good choice
for a GPS timing source (and from what little I understand, I'd tend to
agree). Now I've been asked to look into using it with xntp... The
initial platform for this would be Solaris 2.5.1 on Sparc.
1) From browsing the xntp distribution, I find that the "Generic
Reference Driver" (PARSE) supports "Trimble SV6 (TSIP and TAIP
protocol)". The Acutime II apparently speaks TSIP, and I have at least a
vague suspicion that it actually houses an "SV6". Thus it seems xntpd
out-of-the-box should be able to get along with the Acutime II - is this
correct?
2) I gather that using the kernel/STREAMS support is a big advantage -
however parse/clk_trimtsip.c says "CURRENTLY VERY MUCH UNDER
CONSTRUCTION". On the other hand it's dated over two years ago -
abandoned or finished?:-)
3) (OK, so this is probably the wrong group, but...) The Acutime II uses
RS-422 - I guess I need RS-422 to RS-232 converter(s) to connect it to a
serial port on the Sparc? Or is it possible to "cheat" and connect them
more or less directly if you don't need to go a long distance with the
cable?
4) Does the Acutime II + cable + power supply + probably RS-422<->RS-232
per above comprise everything I need hardware-wise - i.e. no additional
interface electronics etc? - I can probably handle a bit of wiring...:-)
5) What *about* the wiring, in particular the PPS signal
(html/driver8.html mentions feeding it into the CD pin on the Sparc)? A
diagram would be great, but any advice is appreciated.
Thanks
--Per Hedeland
per@erix.ericsson.se
From: ltso@phoenix.london.waii.com (Marc Brett) [-/+]
Date: 28 Oct 1996 18:06:00 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Trimble Acutime II GPS and xntp [-/+]
X-Keywords: PPS [-/+]
I'd recommend getting ftp://ftp.ee.lbl.gov/ppsclock.tar.Z. It has
PostScript diagrams for RS-422 to RS-232 converters, and code for the
SunOS 4 kernel mods necessary to support the PPS line discipline.
--
Marc Brett Marc.Brett@waii.com
Western Geophysical Tel: +44 181 560 3160 ext. 4178
From: gwinn@res.ray.com (Joe Gwinn) [-/+]
Date: Tue, 29 Oct 1996 17:49:41 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: decoding the IRIG B signal
X-Keywords: Bancomm [-/+] Datum [-/+] IRIG [-/+] PLL [-/+] release [-/+] resolution [-/+]
In article <hron2x7gqfe.fsf@psu.edu>, Andy Jacobson
<andy-jacobson@psu.edu> wrote:
> Howdy, Time Gurus-
>
> We are going to do an experiment here in which we acquire some
> data which needs to be time-stamped. We are using a multichannel A/D
> board and intend to devote one channel to recording an IRIG-B signal
> (an amplitude-modulated version, I believe).
>
> So we would like to be able to decode the digitzed IRIG B
> signal later on. I am trying to download the xntp3.5f release right
> now, (the U Delaware ftp service is *really* slow) in order to see if
> the appropriate decoding algorithm can be found within.
>
> Can some clueful person tell me whether it is worth our time
> to try to tease the routine out of the xntp release? That is, might
> there already be stand-alone programs to decode digitized IRIG-B
> signals? We'd rather use something tried and true than develop/debug
> our own program.
The amplitude-modulated IRIG-B signal is 50% modulation on a 1 KHz
carrier, with a defined phase relationship between carrier and the digital
modulation. To get one millisecond resolution, the AM form is required.
To get better than one millisecond resolution, a phase-locked loop (PLL)
locked to the 1 KHz carrier is required; the controlled oscillator is say
1 MHz, divided by 1000 and compared to the carrier. The 1 MHz is used to
drive the timecode, allowing microsecond resolution from a kilohertz
carrier.
The IRIG-B signal isn't all that complex, but if you need timestamp
resolution exceeding one millisecond, you will probably want to buy an
IRIG-B receiver card. Otherwise, you need to implement a phase-lock loop
in software. These receivers can be obtained for VMEbus and Sun Sbus, and
perhaps others. Try Odetics and Bancomm div of Datum (408-578-4161).
Typically, the receivers present a 16-digit array in memory, the digits
being "dddhhmmss.sssssss" (day of year, hours, minutes, seconds, (implied
decimal point) decimal fraction of second, with the lsd being one-tenth of
a microsecond (although the time may tick at 1 MHz, so this last digit is
unused).
The better grade of IRIG Timecode receiver has a temperature-compensated
PLL, and can drive other units via some RG58 coax cable, ensuring a common
sense of time between multiple boxes.
From: "Doug Hogarth" <DougHo@internetMCI.com> [-/+]
Date: 31 Oct 1996 15:11:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Seeking info on daylight dates worldwide. [-/+]
X-Keywords: daylight [-/+]
There is a up-to-date .gz file at an FTP site if you know what to do with
those.
There is a pointer to it called "reference for computer time zone info" in
the Time/frequency section of my home page.
--
Doug Hogarth's Home Page http://www.digitaldaze.com/dougho/
Lennart Regebro <regebro@enklav.stacken.kth.se> wrote in article
<558l4f$ha3@news.kth.se>...
> I'm in need for Information about daylight saving dates world-wide.
> Does anybody know about some place to get information on this?
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Sun, 3 Nov 1996 10:40:28 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: establishing xntp on a small lan
X-Keywords: documentation [-/+] SCO [-/+] syslog [-/+]
In article <1996Oct31.235323.23167@news.wrc.xerox.com>,
Marty Leisner <leisner@sdsp.mc.xerox.com> wrote:
>
>Can I have a scenerio of how to set this up...I tried both xntp and bsd
>timed, without luck...
With the level of information supplied, the correct answer is read the
documentation. If you want more specific answers, you need to tell
what operating systems you are using, which version of xntp, what
you tried, and what went wrong (syslog events, output from xntpdc/ntpq).
Pay particular attention to the tickadj program when reading the
documentation, as one thing which will break both timed and xntd is
systems (SunOS, SCO...) which try to lock the software clock to the
real time clock.
--
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: hdavies@kzin.mon.rnb.com (Hugh J.E. Davies)
Date: 31 Oct 1996 10:53:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Seeking info on daylight dates worldwide. [-/+]
X-Keywords: daylight [-/+] timezone [-/+]
In article <558l4f$ha3@news.kth.se>, regebro@enklav.stacken.kth.se (Lennart Regebro) writes:
>I'm in need for Information about daylight saving dates world-wide.
>Does anybody know about some place to get information on this?
Any Unix system that uses the Olson (?) timezone code has a directory
full of this kind of stuff. SunOS 4.1.3 keeps it in /usr/share/lib/zoneinfo.
The man pages for 'zic' are helpful, too.
----
Hugh J.E. Davies, AVP Unix Support, Newsmaster,
Republic National Bank, 30 Monument Street, London.
This is *NOT* an official publication of RNB.
From: "Doug Hogarth" <DougHo@internetMCI.com> [-/+]
Date: 31 Oct 1996 15:11:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Seeking info on daylight dates worldwide. [-/+]
X-Keywords: daylight [-/+]
There is a up-to-date .gz file at an FTP site if you know what to do with
those.
There is a pointer to it called "reference for computer time zone info" in
the Time/frequency section of my home page.
--
Doug Hogarth's Home Page http://www.digitaldaze.com/dougho/
Lennart Regebro <regebro@enklav.stacken.kth.se> wrote in article
<558l4f$ha3@news.kth.se>...
> I'm in need for Information about daylight saving dates world-wide.
> Does anybody know about some place to get information on this?
From: "Tom Clark (W3IWI)" <clark@tomcat.gsfc.nasa.gov>
Date: Mon, 04 Nov 1996 05:24:54 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Motorola Oncore as RefClock?
X-Keywords: NMEA [-/+] PPS [-/+] precision [-/+]
Ian G Batten wrote:
>
> The current Maplin catalogue offers the Motorola Oncore GPS receiver,
> together with a development kit to provide an RS232 output and a PPS
> output. For less than 350 quid, this strikes me a A Good Thing. I plan
> to buy one for here.
>
> The Motorola gadget provides ``Motorola Binary Format'', together with
> optional NMEA output. Has anyone interfaced this unit to xntpd, or am I
> going to have to cut code myself? I'd like to use the PPS output if
> possible. Moreoever, it would be nice if I could tee the output into a
> pair of machines for reliablity.
>
> ian
Hello, Ian. Regarding the ONCORE, you might want to browse my ftp server
for
info on my "Totally Accurate Clock" project at
ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/
We have seen that the ONCORE is an extremely good/accurate timekeeping
device for scientific applications, achieving performance in the 30 nsec
RMS range -- that's both precision and accuracy!
In the TAC, we have made the 1PPS signal available to the computer on
the
DCD handshaking line. On aleph you will find a standalone MessDOS
program
I wrote called SHOWTIME that controls the TAC and provides a very useful
clock display. On aleph, you will find a file emulate.zip that tells
you
how to make the ONCORE you plan to buy into a virtual TAC by adding one
wire to the RS232 cable.
I hope to soon be making an announcement about the TAC-2 interface board
that
I've designed. It will have all the features of the original TAC design,
and
offers support for several other GPS receivers as well. For folks
needing to
use it in computer synchronization applications, it has the new added
feature
that the entire GPS rcvr can mount in a floppy drive bay, even to the
point
of having its power connector matching that on disk drives. The plans
are to
make the TAC-2 available as a kit thru the auspices of a non-profit
amateur
radio R&D group (TAPR = Tucson Amateur Packet Radio on the web as
http://www.tapr.org).
The xntpd "plug 'n play" support is being worked on. Since the receiver
sends
NMEA messages and since the TAC makes the 1PPS signal available on the
DCD wire,
it is close to that which is already supported. One small bone of
contention
with the current xntpd implementations is that it is most proper to pick
up
the date/time from the $GPZDA NMEA message. [The present GGA and RMC
message
implementations fail when the receiver is placed in high accuracy timing
mode.
The GGA/RMC messages give the time of the last position fix, but to get
high
accuracy timing you disable the positioning modes. The GGA/RMC messages
then
refer to some nebulous time weeks or months ago! The ZDA message is the
correct,
proper message to be used since it reports the CURRENT time!]
As with most GPS receivers, the ONCORE sends out its NMEA (or binary)
messages
as the lowest priority task. They lag the actual time epoch by several
tenths
of a second. My approach (like in SHOWTIME) is to read the time on the
RS232
line, increment to the next second, and then wait to apply it until the
DCD
1PPS signal arrives. The receiver runs in the "At the tone, the time WAS
(hhmmss)" mode and we convert it to "At the tone, the time WILL BE
(hhmmss+1)".
If you are eager to work on xntpd'ing the ONCORE/TAC, keep in touch.
Regards, Tom Clark
From: Tom Mitchell <mitch@csd.sgi.com>
Date: Fri, 1 Nov 1996 16:09:05 -0800 [-/+]
Newsgroups: demon.tech.unix,comp.unix.admin,comp.protocols.time.ntp
Subject: Re: Porting timed [-/+]
X-Keywords: broadcast [-/+] multicast [-/+]
On 21 Oct 1996, Paul Civati wrote:
> Not sure why timed is not the trend these days, I guess it just doesn't
> work so well.
timed works very well. It however depends on the politics of the
network. As networks get large and multiple groups share nets
the notion of authority gets muddy. Nets are getting large.
At the roots of timed is a broadcast protocol and an election of
the master. The management of the net's broadcast domain must be
uniform.
NTP has the ability to configure hosts near or far... that is
good. It also has the notion of multiple good hosts as well as
levels of quality. If one is unavailable the next is consulted.
I like NTP to distribute time into work areas or building nets.
Then within the building or local net, I like timed because
people know it and NIS with netgroups let me change the
'authority' from a central place without touching config files on
hosts. NTP and its multicast support may tip me to only NTP in
the long run. I already use CNAMES in the local standard ntp
distribution packaged config file. With DNS changes the
authority/stratum layers can be modified again from a central
place without touching an individual work station config files.
It all ends up with what you know and politics. But it is
an election year.
--
Tom Mitchell -- mitch@sgi.com or mitch@relay.csd.sgi.com
"One is a forecast, the other a storm." When the time comes just do it.
From: add@is.rice.edu (Arthur Darren Dunham) [-/+]
Date: 3 Nov 1996 05:59:43 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Occaisionally updated ntp server?? [-/+]
X-Keywords: dial [-/+] update [-/+]
In article <4zu3rcu5vu.fsf@dingo.theplanet.co.uk>,
Nigel.Metheringham <nigel@theplanet.net> wrote:
>So what I'd like to do is have an ntp server on the box basically
>running off the local clock. Then a number of times a day (probably
>irregularly), I'd like to be able to use ntpdate (or some form of prod
>to the ntp server) to update the local clock. Ideally these updates
>would also apply an overall drift correction so that the local clock
>itself gets as good as it can - given the overall oscillator
>frequency.
1) ntpdate won't do any drift correction.
2) set up your ISDN bridge/gateway whatever so that when your box polls
via ntp (always done over udp/123) it doesn't dial if you can't do that,
then ignore the rest of this. Most gateways will allow you to set
filters for stuff that shouldn't bring up the link.
3) Set up xntp with remote servers and a local clock at a high
stratum. When your link is up, xntp will be hitting the remote sites,
and correcting the clock. When the link is down, the xntpd daemon will
be running, correcting the clock, and serving time to your local
machines.
--
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: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 4 Nov 1996 15:33:31 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help configuring stratum 1 w/ Traconex WWV clock
X-Keywords: fudge [-/+] peer [-/+] prefer [-/+]
robin@ecst.csuchico.edu (Robin - Girl Wonder) writes:
> I am unclear whether I really want
> "peer" as below, or if I should be using "server" instead.
>
>peer 127.127.3.1 prefer # Traconex radio clock /dev/wwv1 -> /dev/tty0
>fudge 127.127.3.1 time1 0.0059 stratum 1
>peer 128.115.14.97 # clock.llnl.gov stratum 1
>peer 134.55.6.83 version 1 # esnoc5.es.net stratum 1
The "peer" keyword is for use when you want time service from a
machine and are willing to offer time service to them in return.
It is usually reserved for arrangements that are worked out in advance
between the administrators of the two machines.
In the case you describe above, I would use
server 127.127.3.1 prefer # Traconex radio clock
fudge 127.127.3.1 time1 0.0059 stratum 1
server 128.115.14.97 # clock.llnl.gov stratum 1
server 134.55.6.83 version 1 # esnoc5.es.net stratum 1
unless you have an agreement with the owners of "clock" and "esnoc5"
to mutually provide time service with them.
Since the Traconex is not capable of receiving time service from your
machine, there is no point in using "peer" with it, though it probably
won't do any harm...
Rick
From: david@djwhome.demon.co.uk (David Woolley) [-/+]
Date: Sun, 3 Nov 1996 11:15:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Occaisionally updated ntp server?? [-/+]
X-Keywords: fudge [-/+] maxpoll [-/+] minpoll [-/+] poll [-/+]
In article <4zu3rcu5vu.fsf@dingo.theplanet.co.uk>,
Nigel.Metheringham <nigel@theplanet.net> wrote:
>
> I'd like to be able to provide NTP time service
>to the private network, without having the system bringing up the ISDN
>line to connect and resync at frequent intervals
Your real problem is that you must anticipate the NTP poll, so that the
ISDN setup is not included in the time measurement.
> (ISDN calls are
>expensive here).
This is relative. For this purpose they cost GBP 0.05, which is about
US$ 0.07. For a well synched clock, they would come to about GBP 0.50
a day, although one could try setting extremely high minpoll and maxpoll
values; the result might not be stable.
....
>I know I can just have the ntp server using the localclock as a ref
>source, however I cannot then use ntpdate to pull it back in, nor can
>I easly apply drift correction....
You can drift correct to half a second a week, in an air conditioned
environment, by simply reading the time with ntpdate -d and using the
fudge command to correct the frequency. You might even be able to
automate this.
There is support for modem clocks, which is designed to operate in your
sort of mode, although, unfortunately, it seems to have not properly
kept up with other changes so will less responsive to errors than the
comments imply. I submitted some changes to support the National Physical
Laboratory's premium rate service (about GBP 0.15 a call). If they
haven't made their way into the current code, they can be found at
http://www.djwhome.demon.co.uk/index.html#NTPStuff. This runs on non-error
corrected V.22bis modems, to minimise setup time and propagation delays
(a single sample can be read in less than the minimum call charge time,
but xntp reads 10 samples).
You can apparently get radio clocks for around GBP 100, which are
probably going to be as accurate as network time if you are trying to
keep polling rates low.
--
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: regebro@enklav.stacken.kth.se (Lennart Regebro) [-/+]
Date: 30 Oct 1996 22:33:51 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Seeking info on daylight dates worldwide. [-/+]
X-Keywords: daylight [-/+]
I'm in need for Information about daylight saving dates world-wide.
Does anybody know about some place to get information on this?
--
Posted by Lennart Regebro, Moderator of comp.os.netware.announce
E-mail: cona-request@stacken.kth.se
Home Page: http://www.stacken.kth.se/~regebro/
From: regebro@enklav.stacken.kth.se (Lennart Regebro) [-/+]
Date: 3 Nov 1996 22:17:48 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Seeking info on daylight dates worldwide. [-/+]
Thanks to all the emails I got pointing me to elsie.nci.nih.gov.
It seems to fill my needs.
--
Posted by Lennart Regebro, Moderator of comp.os.netware.announce
E-mail: cona-request@stacken.kth.se
Home Page: http://www.stacken.kth.se/~regebro/
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 05 Nov 1996 14:13:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: synchronization problem
X-Keywords: logconfig [-/+] loopstats [-/+] syslog [-/+]
Maybe add a line "logconfig all" to /etc/ntp.conf to produce some more
information. Maybe also check /etc/syslog.conf to make sure that the
messages go to somewhere. Also you could try to enable the "loopstats"
to capture some data about the synchronization. A common problem is a
overloaded machine and/or network.
Look into the HTML docs about debugging NTP.
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 28 Oct 1996 14:48:16 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP newbie question [-/+]
X-Keywords: DST [-/+] peer [-/+]
I'd buy at least one reference clock. If you have "rich" departments
that are geometrically spread it wouldn't be a bad idea to make them
pay a reference clock, too. Then I'd peer them. But still: One would
be fine, maybe even none, but with these things like power-fails, DST,
leap seconds, etc, I'd really get a reference clock.
From: jerry@arlut.utexas.edu (Jerry Heyman)
Date: 30 Oct 1996 23:54:58 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.unix.sco.misc,comp.unix.sco.programmer
Subject: Re: xntpd for SCO 5.2 ?!?!
X-Keywords: driftfile [-/+] SCO [-/+] syslog [-/+]
sfd@syseca-us.com wrote:
: Here's what I'm running:
: Dell w/ SCO 5.2
: Alpha 1000 w/ Digital Unix
: I'd like to configure xntpd, on the SCO box, to run as a client, getting it's
: time from the Alpha.
What version of xntpd is running under Digital Unix?
: I've tried some simple things that don't seem to work. Such as: Creating
: ntp.conf (SCO) with the driftfile and server key words, starting up xntpd
: (on both machines), going into xntpdc (SCO), typing "peers" I get:
: localhost: timed out, nothing received
: ***Request timed out
: In fact, when I start xntpd on the SCO box, I get the following in syslog:
: xntpd[2054]: xntpd version=3.2; Tue Sep 7 16:50:21 CDT 1993 (1)
: xntpd[2054]: tickadj = 250000, tick = 10000, tvu_maxslew = 750000
: xntpd[2055]: request keyid 65535 not found
: xntpd[2054]: system event 1 status c010
: Again, I have a dozen SCO boxes that I'd like to syncronize to the Alpha. Any
: ideas, please e-mail directly to sfd@syseca-us.com . TIA.
We recently found out that the ntpdate command on SCO Openserver (5.0.x) uses
version 3 protocol, but that the xntpd shipped with the OS uses version 2.
This required us to use the -o 2 option on ntpdate in order to get the
clocks to sink up correctly.
: --sfd
: sfd@syseca-us.com
: -----------------------------------------------------------------------
: This article was posted to Usenet via the Posting Service at Deja News:
: http://www.dejanews.com/ [Search, Post, and Read Usenet News!]
jerry
--
Jerry Heyman | jerry@arlut.utexas.edu O-
Combat System Simulation | http://www.arlut.utexas.edu/~jerry
Applied Research Laboratories of UT Austin | "Software is the difference
P.O. Box 8029, Austin, TX 78713-8029 | between hardware and reality"
From: vjs@calcite.rhyolite.com (Vernon Schryver) [-/+]
Date: 4 Nov 1996 15:26:42 -0700 [-/+]
Newsgroups: demon.tech.unix,comp.unix.admin,comp.protocols.time.ntp
Subject: Re: Porting timed [-/+]
In article <327E6567.30FD@ait.ac.nz>, Michael Mohr <mmohr@ait.ac.nz> wrote:
>Tom Mitchell wrote:
>
>> I like NTP to distribute time into work areas or building nets.
>> Then within the building or local net, I like timed because
>> people know it and NIS with netgroups let me change the
>> 'authority' from a central place without touching config files on
>> hosts.
>--
>Isn't there a compatibility problem running NTP and timed on the same
>machine? Or, have you got some other workaround?
For the fourth or fifth time in this thread, NO!
Tom Mitchell is writing about a corporate network with 10,000-20,000
hosts that use just such a combination of timed, NTP, and timeslave.
Vernon Schryver vjs@rhyolite.com
From: vjs@calcite.rhyolite.com (Vernon Schryver) [-/+]
Date: 4 Nov 1996 15:26:42 -0700 [-/+]
Newsgroups: demon.tech.unix,comp.unix.admin,comp.protocols.time.ntp
Subject: Re: Porting timed [-/+]
In article <327E6567.30FD@ait.ac.nz>, Michael Mohr <mmohr@ait.ac.nz> wrote:
>Tom Mitchell wrote:
>
>> I like NTP to distribute time into work areas or building nets.
>> Then within the building or local net, I like timed because
>> people know it and NIS with netgroups let me change the
>> 'authority' from a central place without touching config files on
>> hosts.
>--
>Isn't there a compatibility problem running NTP and timed on the same
>machine? Or, have you got some other workaround?
For the fourth or fifth time in this thread, NO!
Tom Mitchell is writing about a corporate network with 10,000-20,000
hosts that use just such a combination of timed, NTP, and timeslave.
Vernon Schryver vjs@rhyolite.com
From: bwb@etl.noaa.gov (Bruce (303) 497-6217) [-/+]
Date: 8 Nov 1996 17:24:32 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: auth problems with xntpd
X-Keywords: delay [-/+] driftfile [-/+] FAQ [-/+] poll [-/+] restrict [-/+]
Howdy,
A quick look confirms that you can send and receive chimes,
but that you aren't trusting them. Try removing all the reslist
stuff from ntp.conf and restart. I think you need a specific line
for EACH server in you reslist with the "no modify" (anti-"no trust"
is default) keword to get the server responses past your default
"no trust, no modify". I suggest starting wide open, and after it
cooks moving towards the level of restriction you want.
You are very close to having it cook !
Bruce Bartram bbartram@etl.noaa.gov
NOAA Boulder, CO usual disclaimers apply
-----
Great detail mondo shortened and hacked to be much smaller !
Only leaving one of the three servers to show how ntpq reports a
host response that doesn't go thru the reslist (it is really stealth!).
In article <3282B4F8.7C06F31@inlink.com> you wrote:
: I'm having no success getting xntpd to work for me. I've poured through
: the manuals, the NTP Debugging Techniques page, the FAQ, searched the
: web and this newsgroup, and nothing I've read addresses this
: particular problem, and I'm hoping someone can enlighten me.
: The problem: xntpd refuses to work, and it seems the reason is a
: failure to authenticate with the time servers. The only really
: indicative bit of info I have I got from using the readvar command
: in ntpq, which shows that flash=0x10<BAD AUTH>.
: # /usr/local/bin/xntpd -d
: ...
: sendpkt(fd=11 128.174.22.8, 0.0.0.0, ttl=-8, 48)
: input_handler: fd=14 length 48 from 80ae1608 128.174.22.8
: ---[ ntpq output ]---
: ntpq> pe
: remote refid st t when poll reach delay offset disp
: ==================================================================
: colt.gw.uiuc.ed 0.0.0.0 16 u 49 64 0 0.00 0.000 16000.0
: ---[ Firewall rules ]---
: access-list 101 permit udp 128.174.22.8 0.0.0.0 204.233.137.163 0.0.0.0
: eq 123
: ---[ /etc/ntp.conf ]---
: restrict default notrust nomodify
: restrict 204.233.137.0 mask 255.255.255.0 nomodify
: restrict 127.0.0.1
: authenticate no
: driftfile /etc/ntp.drift
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 28 Oct 1996 14:48:16 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP newbie question [-/+]
X-Keywords: DST [-/+] peer [-/+]
I'd buy at least one reference clock. If you have "rich" departments
that are geometrically spread it wouldn't be a bad idea to make them
pay a reference clock, too. Then I'd peer them. But still: One would
be fine, maybe even none, but with these things like power-fails, DST,
leap seconds, etc, I'd really get a reference clock.