From: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 13 Aug 1996 08:38:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Servers [-/+]
X-Keywords: Datum [-/+] Garmin [-/+] NMEA [-/+]
In article <x6n30089ls.fsf@claudia.teleport.com>, Darrell Fuhriman <darrell@teleport.com> writes:
: hpa@transmeta.com (H. Peter Anvin) writes:
:
: > Let's see, when I called Datum they wanted some $3,000 for their
: > low-end product. Sorry, not in my budget. Went out and picked up a
: > Garmin GPS-45 handheld GPS receiver and plugged the NMEA output into
:
: Xntp has support for NMEA, but it's not documented. Is there
: any tweaking that needs to be done to xntp or Garmin, or does it
: pretty much work "out of the box"?
Don't expect too much in the way of time accuracy. The NMEA output timing
is unlikely to have been designed to give low and repeatable offsets
of known reference strings in the message from the time indicated. After
all a second or two is quite adequate for small boat navigation and
autopilots.
J
From: bpenrod@truetime.com
Date: 12 Aug 1996 22:21:18 GMT [-/+]
Newsgroups: comp.os.os2.announce,comp.protocols.time.ntp,comp.os.os2.networking.tcp-ip,comp.os.os2.scitech
Subject: FREEWARE: OS2_NTPD V1.0, Network Time Protocol Client for OS/2
X-Keywords: implementation [-/+] poll [-/+]
~Reply-to: bpenrod@truetime.com
---------------------------------------------------------------------
[ Followups directed to comp.protocols.time.ntp ]
OS2_NTPD V1.0 is an implementation of the Network Time Protocol client for
OS/2. It is a 32-bit, multi-threaded, text mode application which will poll up
to 22 NTP servers to maintain the local system clock to within 31.25 ms of
UTC.
OS2_NTPD 1.0 is distributed in the archive zip file os2ntp10.zip currently
located in the /incoming directory at the HOBBES FTP site:
ftp://hobbes.nmsu.edu/incoming/os2ntp10.zip
It should eventually find its way to the os2/network/tcpip directory:
ftp://hobbes.nmsu.edu/os2/network/tcpip/os2ntp10.zip
OS2_NTPD is FREEWARE!
However, I ask that those who find it useful please register it by E-Mailing
your name and address to truetime@nbn.com.
=====================================================================
-- To submit to c.o.os2.announce: POST (or email os2_ann_req@bix.com)
-- For comments to the moderator: email lfirrantello@bix.com.
- for posting guidelines see: http://www.bix.com/pub/os2ann/pindex.htm
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 15 Aug 1996 16:45:59 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: adjustment [-/+] dial [-/+] synchronized [-/+]
In article <4uq0of$eq$1@montespan.pasteur.fr> bortzmeyer@pasteur.fr (Stephane Bortzmeyer) writes:
> So, how to run a xntpd for synchronizing local clients
> while updating it with outside servers when *I* want (from
> a cron job which knows when the link is up, for instance)?
This question comes up frequently in various forms, and at the
moment, I don't think there is a 100% solution. The first part of
the solution (running a server for local clients) is done by
building xntpd with the "Local Clock" reference clock driver
(driver1). That lets you serve time to your local network from a
single machine, but it does nothing to keep the server
synchronized.
It's important to note that you can give a parameter to the "local
clock" in the ntp.conf file which applies a fixed adjustment to
its rate. That is, if you find that the clock is running N ppm
fast, you can apply a base correction of N to remove any and all
consistent long-term drift.
I've done this by simply running ntpdate once a day when connected
to a good time server, noticing how much correction is, and
tweaking N appropriately. After a few days, the average daily
correction was down to less than 1 ppm and that's plenty good
enough for non-critical applications.
Unfortunately, you have to shut off xntpd briefly when running
ntpdate. This is only a small bother however; it doesn't perturb
the local clients.
What is needed is a local clock driver that combines the two
things -- using the local clock with a long-term correction value,
AND polling an external server at arbitrary times when available.
In the meantime, I suppose you could make a cron job that runs
when you dial in to the net and:
1. shuts down xntpd
2. runs ntpdate
3. starts xntpd
Yes, I know it's ugly, but, after calibrating your local clock
appropriately, it should give you pretty good short- and long-term
accuracy.
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Fri, 16 Aug 1996 22:19:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: adjustment [-/+] DCF [-/+] dialup [-/+] dispersion [-/+] fudge [-/+] maxpoll [-/+]
In article <DLM.96Aug15124559@firebird.osf.org>,
Dan Murphy <dlm@firebird.osf.org> wrote:
>
> It's important to note that you can give a parameter to the "local
> clock" in the ntp.conf file which applies a fixed adjustment to
> its rate. That is, if you find that the clock is running N ppm
> fast, you can apply a base correction of N to remove any and all
> consistent long-term drift.
The correction in the ntp.conf isn't very useful, because one ought to
be using a drift file, and this correction will be cumulatively applied
to the drift file. When I've been doing this (against a DCF watch -
procedure take several samples of "netdate localhost" after phase
locking the finger on the return key to the seconds - accurate to better
than 100ms, possibly 50ms [+]) I have used xntpdc to fudge time2 to compensate
for drift, with no phase steps. I can usually keep within 1 second with
frequency corrections at intervals of two or more weeks.
Note, it is important to note that ppm are really parts per 2**20; you
can measure the error to sufficient accuracy that this makes a real
difference.
> Unfortunately, you have to shut off xntpd briefly when running
> ntpdate. This is only a small bother however; it doesn't perturb
No you don't: run it with the -d parameter and it won't use the normal
socket.
If you are going to use ntpdate, on a dialup connection, you really need
to idle the link whilst you are doing it. Many dialup links are run
flat out, with the result that the round trip delays, and their dispersion,
are unnacceptably large, and asymmetric. The same applies to leaving
a server configure, although the need to get several samples may make
things worse - at the least you may need to limit maxpoll.
[+] Beware: some "domestic" radio clocks appear to round to the nearest
second, so the second hand steps on the half second. The watch, a
digital one, was cross-checked against stratum 2 and 3 servers on an
quiet dialup connection, and appeared to round down.
--
David Woolley, London, England david@djwhome.demon.co.uk
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 19 Aug 1996 20:13:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: adjustment [-/+]
> In article <Dw94nw.9M9@djwhome.demon.co.uk> David Woolley <david@djwhome.demon.co.uk> writes:
> In article <DLM.96Aug15124559@firebird.osf.org>,
> Dan Murphy <dlm@firebird.osf.org> wrote:
> > Unfortunately, you have to shut off xntpd briefly when running
> > ntpdate. This is only a small bother however; it doesn't perturb
> No you don't: run it with the -d parameter and it won't use the normal
> socket.
Except that -d doesn't actually adjust the local clock. It only
reports what adjustment is needed. So, yes, it lets you see how
much you've drifted since the previous synchronization, but it
doesn't re-synch you. I run in a steady-state where ntpdate does
adjust and synchronize the local clock about once/day, and I
eyeball the log from time to time to see if the drift number needs
to be changed. So far, it hasn't since the initial calibration.
dlm
From: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 13 Aug 1996 08:38:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Servers [-/+]
X-Keywords: Datum [-/+] Garmin [-/+] NMEA [-/+]
In article <x6n30089ls.fsf@claudia.teleport.com>, Darrell Fuhriman <darrell@teleport.com> writes:
: hpa@transmeta.com (H. Peter Anvin) writes:
:
: > Let's see, when I called Datum they wanted some $3,000 for their
: > low-end product. Sorry, not in my budget. Went out and picked up a
: > Garmin GPS-45 handheld GPS receiver and plugged the NMEA output into
:
: Xntp has support for NMEA, but it's not documented. Is there
: any tweaking that needs to be done to xntp or Garmin, or does it
: pretty much work "out of the box"?
Don't expect too much in the way of time accuracy. The NMEA output timing
is unlikely to have been designed to give low and repeatable offsets
of known reference strings in the message from the time indicated. After
all a second or two is quite adequate for small boat navigation and
autopilots.
J
From: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 14 Aug 1996 10:40:12 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: dialup [-/+] Linux [-/+] update [-/+]
In article <4uq0of$eq$1@montespan.pasteur.fr>, bortzmeyer@pasteur.fr (Stephane Bortzmeyer) writes:
:
: I'm trying to get in synch a whole LAN (a few dozens of MS-DOS
: and MacOS machines with two Linux servers).
:
: This LAN has only a dialup-IP link to the Internet which
: is not always up. On the other side of the link, we can find
: time servers.
:
: I would like to use of one the Linux boxes as a time server
: for the LAN. And I would like it to stay in touch with the
: outside time. Because of the dialup link, normal synchronization
: is not an option. I can run xntpd on the PC, but, if I try to
: update the clock with ntpdate, I have:
:
: 13 Aug 15:37:44 ntpdate[7207]: the NTP socket is in use, exiting
:
: (which makes sense since xntpd is running)
:
: So, how to run a xntpd for synchronizing local clients
: while updating it with outside servers when *I* want (from
: a cron job which knows when the link is up, for instance)?
Set up one of your linux servers to point to a couple of external
time servers, but also set it to sync from a local clock (you need
-DLOCAL_CLOCK as one of the settings for CLOCKDEFS in the Config file
when you compile). Set the local clock stratum fairly low, say 6.
When the dial-up link is active, the server will sync automatically from the
Internet and develop a measurement of its own drift. You won't need a cron
job. When the link goes away the local server will drop to stratum 6 and
become the reference for the LAN, correcting its own drift based on the
measured drift when connected.
J
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 15 Aug 1996 16:45:59 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: adjustment [-/+] dial [-/+] synchronized [-/+]
In article <4uq0of$eq$1@montespan.pasteur.fr> bortzmeyer@pasteur.fr (Stephane Bortzmeyer) writes:
> So, how to run a xntpd for synchronizing local clients
> while updating it with outside servers when *I* want (from
> a cron job which knows when the link is up, for instance)?
This question comes up frequently in various forms, and at the
moment, I don't think there is a 100% solution. The first part of
the solution (running a server for local clients) is done by
building xntpd with the "Local Clock" reference clock driver
(driver1). That lets you serve time to your local network from a
single machine, but it does nothing to keep the server
synchronized.
It's important to note that you can give a parameter to the "local
clock" in the ntp.conf file which applies a fixed adjustment to
its rate. That is, if you find that the clock is running N ppm
fast, you can apply a base correction of N to remove any and all
consistent long-term drift.
I've done this by simply running ntpdate once a day when connected
to a good time server, noticing how much correction is, and
tweaking N appropriately. After a few days, the average daily
correction was down to less than 1 ppm and that's plenty good
enough for non-critical applications.
Unfortunately, you have to shut off xntpd briefly when running
ntpdate. This is only a small bother however; it doesn't perturb
the local clients.
What is needed is a local clock driver that combines the two
things -- using the local clock with a long-term correction value,
AND polling an external server at arbitrary times when available.
In the meantime, I suppose you could make a cron job that runs
when you dial in to the net and:
1. shuts down xntpd
2. runs ntpdate
3. starts xntpd
Yes, I know it's ugly, but, after calibrating your local clock
appropriately, it should give you pretty good short- and long-term
accuracy.
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Fri, 16 Aug 1996 22:19:07 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: adjustment [-/+] DCF [-/+] dialup [-/+] dispersion [-/+] fudge [-/+] maxpoll [-/+]
In article <DLM.96Aug15124559@firebird.osf.org>,
Dan Murphy <dlm@firebird.osf.org> wrote:
>
> It's important to note that you can give a parameter to the "local
> clock" in the ntp.conf file which applies a fixed adjustment to
> its rate. That is, if you find that the clock is running N ppm
> fast, you can apply a base correction of N to remove any and all
> consistent long-term drift.
The correction in the ntp.conf isn't very useful, because one ought to
be using a drift file, and this correction will be cumulatively applied
to the drift file. When I've been doing this (against a DCF watch -
procedure take several samples of "netdate localhost" after phase
locking the finger on the return key to the seconds - accurate to better
than 100ms, possibly 50ms [+]) I have used xntpdc to fudge time2 to compensate
for drift, with no phase steps. I can usually keep within 1 second with
frequency corrections at intervals of two or more weeks.
Note, it is important to note that ppm are really parts per 2**20; you
can measure the error to sufficient accuracy that this makes a real
difference.
> Unfortunately, you have to shut off xntpd briefly when running
> ntpdate. This is only a small bother however; it doesn't perturb
No you don't: run it with the -d parameter and it won't use the normal
socket.
If you are going to use ntpdate, on a dialup connection, you really need
to idle the link whilst you are doing it. Many dialup links are run
flat out, with the result that the round trip delays, and their dispersion,
are unnacceptably large, and asymmetric. The same applies to leaving
a server configure, although the need to get several samples may make
things worse - at the least you may need to limit maxpoll.
[+] Beware: some "domestic" radio clocks appear to round to the nearest
second, so the second hand steps on the half second. The watch, a
digital one, was cross-checked against stratum 2 and 3 servers on an
quiet dialup connection, and appeared to round down.
--
David Woolley, London, England david@djwhome.demon.co.uk
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 19 Aug 1996 20:13:49 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronizing a dialup network [-/+]
X-Keywords: adjustment [-/+]
> In article <Dw94nw.9M9@djwhome.demon.co.uk> David Woolley <david@djwhome.demon.co.uk> writes:
> In article <DLM.96Aug15124559@firebird.osf.org>,
> Dan Murphy <dlm@firebird.osf.org> wrote:
> > Unfortunately, you have to shut off xntpd briefly when running
> > ntpdate. This is only a small bother however; it doesn't perturb
> No you don't: run it with the -d parameter and it won't use the normal
> socket.
Except that -d doesn't actually adjust the local clock. It only
reports what adjustment is needed. So, yes, it lets you see how
much you've drifted since the previous synchronization, but it
doesn't re-synch you. I run in a steady-state where ntpdate does
adjust and synchronize the local clock about once/day, and I
eyeball the log from time to time to see if the drift number needs
to be changed. So far, it hasn't since the initial calibration.
dlm
From: bortzmeyer@pasteur.fr (Stephane Bortzmeyer)
Date: 14 Aug 1996 11:49:31 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: SUMMARY: Synchronizing a dialup network
X-Keywords: broadcast [-/+] configuration [-/+] documentation [-/+] driftfile [-/+] fudge [-/+] Linux [-/+]
In article <4uq0of$eq$1@montespan.pasteur.fr>, bortzmeyer@pasteur.fr (Stephane Bortzmeyer) writes:
>
> I'm trying to get in synch a whole LAN (a few dozens of MS-DOS
> and MacOS machines with two Linux servers).
>
> This LAN has only a dialup-IP link to the Internet which
> is not always up. On the other side of the link, we can find
> time servers.
OK, here is the configuration which seems to work:
1) Set up one server on the LAN as a NTP server with a local clock
(xntpd must have been compiled with LOCAL_CLOCK which is the default).
Here is my /etc/ntp.conf:
# Synchronize on myself (127.127 = myself, 1 = local clock)
server 127.127.1.0
# Stratum 10 (arbitrary)
fudge 127.127.1.0 stratum 10
broadcast 10.0.2.255
driftfile /usr/local/etc/ntp.drift
The server can now be used by other machines (simple clients or
other xntpd which will be in stratum 12).
2) Synchronize it to the outside world when the link is up:
ntpdate -u my-time-server-1 my-time-server-2
('-u' : use an other, unpriviledged port)
This seems to work. Of course, accuracy is probably rather low
but I just want correct time stamps in mail and news headers.
HTML files to read in the documentation:
clockopt.html and specially driver1.html which explains that
solution.
ntpdate.html
Thanks to Hannes Boehm <e9427404@student.tuwien.ac.at> for the
solution and to Tom Lane <tgl@netcom.com> and John Sager
<jcs@zoo.bt.co.uk> for helpful suggestions.
From: add@is.rice.edu (Arthur Darren Dunham) [-/+]
Date: 14 Aug 1996 16:26:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: fix for badly drifting clock on solaris? [-/+]
X-Keywords: nsec_per_tick [-/+]
In article <4uj4io$ef5@mwrns.boulder.noaa.gov>,
Bruce Bartram 303-497-6217 <bwb@mickey.etl.noaa.gov> wrote:
> Below are the bottom few lines of my /etc/system that modify
>the setsynctodr and ns_per_tick. /etc/system is only read on bootup
>so changes and fiddles are best done with some thought to avoid extra
>cycles. As I remeber, a machine loosing time will show a + drift
>and need value added to ns_per_tick of 10*ppm. For example, your
>9000 ppm would make the machine slow by 13 minutes/day and you
>should :
> set ns_per_tick = 10090000
>If your machine is fast by 9000ppm use 9910000.
Good idea, but beware. Such lines seem to have NO effect on Ultra
machines running Solaris 2.5. I can't seem to fix any of mine in this
manner.
Actually, upon looking, I have been using 'nsec_per_tick'. Is
ns_per_tick better (correct)? The one I was using worked until the 2.5
Ultras.
--
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: bbartram@netcom.com (Bruce W. Bartram)
Date: Thu, 15 Aug 1996 17:59:27 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: fix for badly drifting clock on solaris? [-/+]
X-Keywords: nsec_per_tick [-/+]
Arthur Darren Dunham (add@is.rice.edu) wrote:
: Actually, upon looking, I have been using 'nsec_per_tick'. Is
: ns_per_tick better (correct)? The one I was using worked until the 2.5
: Ultras.
Woops, the only thing that I've tried is nsec_per_tick. Trust
the snip from the /etc/system and not my fuzzy memory.
Bruce Bartram bbartram@etl.noaa.gov or bbartram@netcom.com
NOAA Boulder, CO
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Sun, 25 Aug 1996 11:54:17 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd Stops Running
X-Keywords: implementation [-/+] SCO [-/+]
In article <321CDA8E.15DE@ix.netcom.com>,
Aaron M. Renn <arenn@ix.netcom.com> wrote:
>I've got a problem. I'm using xntpd 3.1 in broadcastclient mode on
>SCO Unix 3 to sync clocks. I have an HP running xntpd 3.1 broadcasting
>NTP over satellite. The latency is high, but I don't think there are
>any specific congestion or reliability problems.
SCO Unix requires a kernel patch to prevent it resynching to the time of
day clock. This was last published on comp.unix.sco.misc within the last
two weeks, although I can dig it out from my archive, if you can't find
it. (Some day I'll get clearance to include it on my web site.)
Incidentally, whilst you are looking in that newsgroup, there is someone
else asking how to port xntpd 3.5. It sounds like you have got round
SCOs weak implementation of tickadj, so they might appreciate a reply from
you.
--
David Woolley, London, England david@djwhome.demon.co.uk
From: lea@mickey.etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Date: 28 Aug 1996 21:16:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Newbie xntpd question on /etc/ntp.drift
X-Keywords: update [-/+]
Robert Bannocks (cc_s551@kingston.ac.uk) wrote:
: I have recently installed xntpd on a soleris 2.3 machine. and the
: /etc/ntp.drift keeps becomming world writable with permissions -rw-rw-rw
: How can I stop this?
Howdy,
I use xntp3.5c on Solaris 2.5. My drift file is -rw-r--r--
and stays that way.
The drift file is written hourly, into ntp.drift.TEMP, then
a rename is called to replace ntp.drift with the new version.
(see xntpd/ntp_util.c)
I don't see any code to suggest that the old permissions should
be carried over the the new copy.
This leads me to believe that the controlling detail is the
xntpd processes umask (see man umask ...). In my world, the
default umask is 022 set in /etc/profile which sets up most
sh processes, including the rc scripts run during init / bootup.
Testing my theory:
grep umask /etc/profile in my system returns umask 022
and I think in yours it will either be blank or umask 000.
put a umask 022 in your xntpd startup script and see if
changes the way your ntp.drift permissions behave.
chmod 644 ntp.drift and chmod 664 ntp.drift and watch to
see if they change when the file is re-created. When I
chmod 664 ntp.drift, I find it is 644 after the next update.
I think that the /etc/profile umask 022 is the best idea, as
this is a good default. Users of sh that want another
answer can make their own .profile with a different value.
Bruce Bartram bbartram@etl.noaa.gov
NOAA Boulder, CO, USA usual disclaimers apply
From: gene@michelob.wustl.edu (Gene Schmidt)
Date: 28 Aug 1996 22:44:01 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Choosing Internet NTP servers
X-Keywords: USNO [-/+]
You should be net-conscious in selecting
NTP servers. It is poor form to select ALL open access
servers regardless of net distance. The best strategy
is to get a mix of 3-4 of the nearer servers (max).
You don't gain much with many servers but you do
generate unnecessary net traffic.
Rich Schmidt, Directorate of Time, USNO
res@tuttle.usno.navy.mil
From: tgl@netcom.com (Tom Lane) [-/+]
Date: Thu, 29 Aug 1996 05:35:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp configuration questions
X-Keywords: configuration [-/+] poll [-/+]
gapalbrs@worldaccess.nl writes:
> The configuration I have in mind is to run xntpd
> on our 'time server'. All other hosts in the network
> can poll the time server for the right time.
I'd recommend running xntpd on *all* your hosts. It's not so much of
a resource hog that this is unreasonable. Set up the "master" machine
to use its local clock as a reference source, and configure all the
rest to refer to the master.
Actually, the most robust solution is to set up all the hosts to use
their local clocks as reference --- this keeps any xntpd from deciding
that it has totally lost sync if it can't contact the master. The
master uses only its local clock, the rest are given their local
clocks and the address of the master. You make the master masterful
by giving its clock a lower stratum number than the rest --- say,
stratum 10 for the master's clock and stratum 13 for the rest. (This
assumes you don't have a real radio time receiver on the master,
otherwise you'd be justified in assigning it a better stratum number.)
> * The applications on the hosts (time clients) don't
> like big time steps. In fact, in the past I did
> something alike with rdate every day, and one of
> our applications looped like hell! In the manuals I
> read something about a way to slow down or speed up
> the system clock (tickadj syscall?).
That's exactly what xntpd does. No reason you should
reinvent the wheel.
> * When is time stepping being used and when is slowing
> down/speeding up being used?
IIRC, a step is used to recover from a time difference of more than
127 msec. As long as you stay within that range of your reference
source, tickadj manipulations are used.
I think that ntpdate uses the same cutoff point, but you'd have to
check the manual.
> * When I use xntpd for the time server and ntpdate for
> the time clients to poll the server (say every hour),
> can it be guaranteed that time is never stepped on
> the clients?
No. This is riskier than the all-xntpd solution for two reasons:
* If a machine's local clock is so bad that it gains or loses more
than 127 msec/hour, ntpdate will happily step the clock every time.
xntpd will complain loudly and eventually give up, thereby motivating
you to fix the clock ;-).
* ntpdate takes a few closely spaced measurements and believes the
result. A short-term network overload might skew the measurement
enough to persuade ntpdate to step the clock. xntpd does long-term
averaging and so is much less troubled by one bad measurement.
regards, tom lane
From: jcs@zoo.bt.co.uk (John Sager) [-/+]
Date: 30 Aug 1996 11:28:30 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: what does a negative delay mean?
X-Keywords: delay [-/+] resolution [-/+] SCO [-/+]
In <504539$alh@murphy2.servtech.com>, rchandra@hal9000.buf.servtech.com (Joe
Philipps) writes:
: I have recently built xntpd and friends (3.5f) on SCO ODT 3. Whenever
: I get a status w/ xntpdc -s, my main synch source shows up with a
: negative delay. Ummm....a packet arriving before it's sent? :^) Does
: this mean anything? I thought at one time I saw something on this,
: but for days (over a span of weeks) I've been poring over FAQs and
: such, with no results...so I thought I'd post here and see what comes
: up.
This is caused by low resolution on either client or server clocks. If
gettimeofday() only has 10 or 20ms resolution, then it is possible
to get timestamp sequences back at the client which translate into
negative delay when you do the sums.
J
From: dalton@cup.hp.com (David Dalton) [-/+]
Date: 30 Aug 1996 19:31:23 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problem with xntpd ver3.4x and HP_UX 9 [-/+]
X-Keywords: adjtimed [-/+] adjustment [-/+] HP-UX [-/+]
Christoph Badura (bad@ora.de) wrote:
: Why Distribution: inet?
: In <32268A9F.41C6@indy.gctc.rssi.ru> Peter Shlyaev <peter@indy.gctc.rssi.ru> writes:
: >Here is a log file from xntp ver3.4x :
: >30 Aug 10:18:52 xntpd[226]: Can't do time adjustment: No such file or
: >directory
: Install adjtimed.
It sounds like you forgot to turn on the adjtimed daemon. It must be
started prior to starting the NTP daemon, every time. I recommend
something like this is the local_rc() function of /etc/rc :
/usr/local/etc/adjtime/adjtimed -r # use your own path
/usr/local/etc/xntpd/xntpd
There have been reports that adjtimed sometimes fails to start when
activated from a script like this, so look for the active process whenever
you see the "Can't do time adjustment:" message, like this:
# ps -ef | grep adj
root 1737 1 0 Aug 15 ? 0:00 /tmp/NTP/adjtime/adjtimed -r
It is hard for me to work on things in the HP-UX 9.x world these days, so
if anyone can enlighten me about the adjtimed startup problems I would
appreciate hearing about it.
If you think there is good in everyone, you haven't met everyone.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.com 408/447-3016
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 03 Sep 1996 12:14:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problem with xntpd ver3.4x and HP_UX 9 [-/+]
X-Keywords: adjtimed [-/+]
I also needed a sleep after adjtimed. Seems the program forks first
and then opens the socket. Maybe the parent should wait a bit...
From: Metod Kozelj <metod.kozelj@rzs-hm.si> [-/+]
Date: Tue, 03 Sep 1996 13:14:27 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problem with xntpd ver3.4x and HP_UX 9 [-/+]
X-Keywords: adjtimed [-/+] adjustment [-/+] HP-UX [-/+]
Hello,
David Dalton wrote:
>
[ snip ]
>
> : >30 Aug 10:18:52 xntpd[226]: Can't do time adjustment: No such file or
> : >directory
>
> : Install adjtimed.
>
> It sounds like you forgot to turn on the adjtimed daemon. It must be
> started prior to starting the NTP daemon, every time. I recommend
> something like this is the local_rc() function of /etc/rc :
>
> /usr/local/etc/adjtime/adjtimed -r # use your own path
> /usr/local/etc/xntpd/xntpd
>
> There have been reports that adjtimed sometimes fails to start when
> activated from a script like this, so look for the active process whenever
> you see the "Can't do time adjustment:" message, like this:
[ snip ]
> It is hard for me to work on things in the HP-UX 9.x world these days, so
> if anyone can enlighten me about the adjtimed startup problems I would
> appreciate hearing about it.
I've had such problems. It seems to me, that when the first request to
do something somehow disturbed adjtimed and hence it died. Now in my
startup scripts I have the following lines:
| /usr/local/bin/adjtimed -r
| /usr/local/bin/ntpdate some.server.domain
| /usr/local/bin/xntpd
| /usr/local/bin/adjtimed -r
xntpd daemon is not fast enough peeking adjtimed, so the second adjtimed
peeks the first one. The first one gets disturbed and dies, the second
one lives happily forever.
The second adjtimed is needed only on one of our HP-UX 9.0 machines,
(the oldest one) so it seems that I was supposed to apply some patch
that I don't know about.
With kind regards,
Metod
--
Metod Kozelj
e-mail: Metod.Kozelj@rzs-hm.si
WWW: http://www.rzs-hm.si/people/Metod.Kozelj/
From: bad@ora.de (Christoph Badura) [-/+]
Date: Tue, 3 Sep 1996 12:43:37 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd and dynamic IP addresses [-/+]
X-Keywords: dial [-/+] FreeBSD [-/+]
In <322B9FD9.41C67EA6@hiwaay.net> David Kelly <dkelly@hiwaay.net> writes:
>Running FreeBSD 2.1.0 and xntpd 3.4e (the one in FreeBSD's package
>collection) on a dial-up internet connection with dynamic IP addresses
>assigned each time I dial in.
If you run "netstat -f inet" you'll see that xntpd binds it's sockets
to the IP addresses of the interfaces of the machine. If such an
interface later changes it's IP address, xntpd probably doesn't do "the
right thing".
--
Christoph Badura
O'Reilly/International Thomson Verlag
From: bad@ora.de (Christoph Badura) [-/+]
Date: Tue, 3 Sep 1996 12:43:37 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd and dynamic IP addresses [-/+]
X-Keywords: dial [-/+] FreeBSD [-/+]
In <322B9FD9.41C67EA6@hiwaay.net> David Kelly <dkelly@hiwaay.net> writes:
>Running FreeBSD 2.1.0 and xntpd 3.4e (the one in FreeBSD's package
>collection) on a dial-up internet connection with dynamic IP addresses
>assigned each time I dial in.
If you run "netstat -f inet" you'll see that xntpd binds it's sockets
to the IP addresses of the interfaces of the machine. If such an
interface later changes it's IP address, xntpd probably doesn't do "the
right thing".
--
Christoph Badura
O'Reilly/International Thomson Verlag
From: add@pecos.is.rice.edu (Arthur Darren Dunham) [-/+]
Date: 4 Sep 1996 16:38:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd and dynamic IP addresses [-/+]
In article <Pine.HPP.3.93.960902225235.7191A-100000@bluejay.creighton.edu>,
L. F. Sheldon, Jr. <lsheldon@creighton.edu> wrote:
>On Mon, 2 Sep 1996, David Kelly wrote:
>> Noticed my system ran 8 seconds fast in 24 hours no matter the
>> /etc/ntp.drift values but holds within 100 ms if I leave xntpd running
>> while not online. But once reconnected typing "peers" to ntpq the modem
>> lights flash appropriately but the values reported never change. Nor
>> does my system time. Killing xntpd and starting a new one appears to be
>> the thing I need to do.
>Probably should wait for somebody who actually know waht they are talking
>about, but this looks like a Bad Thing for the peers--I am guessing that
>xntpd "remembers" your IP address at the time it was started, and ntpq
>uses that IP addres for its queries--which result (still guessing) in
>the server getting a "no route to host" or "connection refused" depending
>on whether somebody else is now using the IP address you had or not. Or
>the one now using that IP address is getting bizarre updates, if it too
>is running xntpd.
>What to do? Really off the edge here, but I am going to guess that you
>should kill xntpd before you reconnect, then run ntpdate and restart
>xntpd.
Probably. Yes, the xntpd process does bind() to the IP address the
machine has at the time. If the addresses changes, the xntpd process
will not notice.
If your address doesn't change, but just goes up and down, you shouldn't
have much trouble.
If it changes a lot, you'd probably want to write a script to kill and
restart your xntpd when the network comes up.
--
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 Sep 1996 18:12:13 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: Using NTP with Windows NT
X-Keywords: Windows [-/+]
Terje Mathisen <Terje.Mathisen@hda.hydro.com> writes:
>Alan Cashin wrote:
>>
>> Has anyone had much experience with (a) The Windows NT port of NTP
>> and (b) NTP over WANs.
I write:
No experience here with NT, but NTP over WANs can be a major headache.
If your network delays are highly asymmetric (time to send packet from
client to server != time to send reply from server to client), and
highly variable (degree of asymmetry at one point in time != that at
another point in time.) you will have a hard time keeping close
synchronization.
What happens is that NTP assumes that transit times are symmetric. If
they are asymmetric, but always by the same amount, this is OK: your
client will be a constant number of microseconds off from the server,
but it will never know. If the asymmetry varies, what the client sees
is that one set of samples shows one offset from the server, while the
next set shows a different offset. If the apparent disparity is too
large (order 100 milliseconds) it will step the local clock to agree
with the new set of samples.
One suggestion is to try fooling around with the "ALWAYS_SLEW"
compile-time variable (I may not have the exact spelling of the
parameter name, but you get the idea) it will make NTP try to avoid
stepping the clock, even if the apparent offset is over 100 ms.
It's probably a good idea (if you do something like this) to have only
one machine that talks to the internet over the WAN, and sync all the
rest of your machines (on the LAN) to it. That way you don't get a
situation of having two (or more) machines with wildly differing and
slowly varying clocks that present equal strata to the machines on the
LAN.
Rick
From: dalton@cup.hp.com (David Dalton) [-/+]
Date: 4 Sep 1996 23:39:34 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: help ! [-/+]
X-Keywords: configuration [-/+] fudge [-/+] peer [-/+] restrict [-/+]
Jean-Francois Zwobada (zwobada@apogee-com.fr) wrote:
: I need help from you, time gurus !
: I only have one machine connected directly to the Internet. This machine
: will be talking with 3 Internet time servers.
: I need to know if the following configuration is valid:
: 2 internal machines with their local clock as 'server':
: internal computer "A":
: server 127.127.1.0
: server B
: fudge 127.127.1.0 stratum 12
: internal computer "B":
: server 127.127.1.0
: peer Internet
: fudge 127.127.1.0 stratum 10
: My Internet machine talking with Internet time servers:
: computer "Internet":
: server Internet_servers
: restrict ...
: What do you think of this ????? Many thanks for your help.
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.
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.
These are the objectives in your search for a good configuration:
1. Get time from from an accurate source (Internet_servers)
2. Bother the public timeservers as little as possible
3. Distribute the accurate time to your internal subnets
For your situation this means that your one computer connected to the
outside world will use "Internet_servers" as its servers and all your other
machines will use "Internet" as _their_ server. This would look like:
# computer "Internet"
server Internet_servers
# internal computer "A"
server Internet
# internal computer "B"
server Internet
stratum N stratum N+1 stratum N+2
--------- ----------- -----------
Internet_servers -> Internet -> computer A
-> computer B
-> computer C
Notice how everything flows in one direction, from the higher strata to the
lower strata. I am unable to draw a simple ASCII picture of the
configuration you proposed because it is too complex and too circular. It
is often very useful to draw a diagram of your own proposed setup this way,
making sure that everything is always flowing (generally) downhill.
This is less than ideal because it lacks redundancy, but it will work. You
are forced into this less than ideal situation because you have only a
single machine, "Internet", that talks to the outside world and so that
machine must be the server for all of your other internal machines. As long
as your accuracy needs are modest (say 100 milliseconds, fine for most people)
and your connection to the outside world does not disappear frequently then
you should have no problem. If you need better accuracy then you must
purchase an external clock of some kind, and for redundancy you really should
have three or more of them in different timezones. But this gets expensive,
and usually causes people to think harder about how much accuracy they really
need.
==> My own $.02 only, not an official statement of HP
If you think there is good in everyone, you haven't met everyone.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.com 408/447-3016