From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 27 Oct 1997 19:10:12 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP HP/UX Version
X-Keywords: ACTS [-/+] Bancomm [-/+] CHU [-/+] Datum [-/+] DCF [-/+] DCF77 [-/+] dialup [-/+] HP-UX [-/+] IRIG [-/+] Meinberg [-/+] MSF [-/+] NIST [-/+] NMEA [-/+] PARSE [-/+] PPS [-/+] Spectracom [-/+] synchronized [-/+] Trimble [-/+] TrueTime [-/+] USNO [-/+] WWV [-/+] WWVB [-/+]
Eric L. Sammons (esammons@ccnotes.ccity.com) wrote:
:>As most of us should know HP/UX 10.20 comes with ntp, man pages and all. I
:>wonder if anyone knows if there is a patch for this version of ntp which
:>will allow me to use driver 18 (NIST dial-up)? And if there is no patch
:>does anyone know if there are plans for HP to support driver 18 in the
:>future?
:>I have spoken with HP support and they claim they do not support driver 18,
:>modem dial-up to NIST. And so no one says, "why not use the public domain
:>copy?" well because there is NO official support for this and our company
:>has a problem with running software which is not vendor supported. But not
:>to threat if HP won't support driver 18, Solaris 2.6 does, nice!
It is sad but true that the version of NTP that comes with HP-UX 10.x is
very old and quite limited. The manpages are not great either, but
excellent info can be obtained from the NTP web pages:
http://www.eecis.udel.edu/~ntp
But PHNE_11019 brings us up to version 3.5f and adds a lot of reference
clocks, including the #18 NIST dialup. I can't offer official HP support
for most of these clocks because I don't have the hardware to test them out
right now, but they should work.
I have persuaded my own 10.20 workstation to use driver #18 and make phone
calls to NIST in the middle of the night, but some details of the full
synchronization are currently escaping me. I think you must define both
the modem (#18) and the local clock (#1) in /etc/ntp.conf and then make
enough short phone calls to achieve the synchronized state. Perhaps
someone who has made this work (on any system, not just HP-UX) could fill
us in on the details. My own late-night experiments will continue.
--
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
ACTS - use NIST dialup clock as reference
AS2201 - Austron 2200A or 2201A GPS receiver
DATUM - use Datum Programmable Time System
HEATH - HeathKit GC-1000 Most Accurate Clock
HPGPS - HP 58503A GPS Time & Frequency receiver
LEITCH - Leitch CSD 5300 Master Clock System Driver
LOCAL_CLOCK - use local clock as reference
MOTO - Motorola GPS clock
PARSE - GENERIC refence clock driver
DCF77:
Meinberg DCF U/A 31, PZF 535
Schmid DCF77 receiver
ELV DCF7000
Raw DCF77 signal (100/200ms pulses)
HOPF 6021
GPS:
Meinberg GPS 166
Trimble GPS (TAIP Protocol)
Trimble GPS (TSIP Protocol)
[no kernel support yet]
MSF:
Radio Clock RCC8000 MSF Receiver
PST - PST/Traconex 1020 WWV/H receiver
PTBACTS - use PTB dialup clock as reference
TRAK - TRAK 8810 GPS station clock
TRUETIME - Kinemetrics/TrueTime (generic) receiver
WWVB - Spectracom 8170 or Netclock/2 WWVB receiver
This is a short overview for the reference clocks currently supported
by xntp V3. (Ultimate wisdom can be obtained from xntpd/refclock_*.c
this file was derived from that information - unfortunately some comments
in the files tend to get stale - so use with caution)
Refclock address Type
127.127.0.x no clock (fails to configure)
127.127.1.x local clock - use local clock as reference
127.127.2.x no clock (fails to configure)
127.127.3.x PSTI 1010/1020 WWV Clock
127.127.4.x SPECTRACOM WWVB receiver 8170 and Netclock/2
127.127.5.x Kinimetric Truetime 468-DC GOES receiver
127.127.6.x IRIG audio decode (not on HP-UX)
127.127.7.x CHU Timecode (not on HP-UX)
127.127.8.x PARSE (generic driver for a bunch of DCF/GPS clocks
can be extended for other clocks too)
8.0-3 Meinberg PZF535/TCXO
8.4-7 Meinberg PZF535/OCXO
8.8-11 Meinberg DCF U/A 31
8.12-15 ELV DCF7000
8.16-19 Walter Schmid DCF receiver (Kit)
8.20-23 Conrad DCF77 receiver module + level converter (Kit)
8.24-27 TimeBrick (limited availability ask
time@informatik.uni-erlangen.de)
8.28-31 Meinberg GPS166
8.32-35 Trimble SV6 GPS receiver
127.127.9.x MX4200 GPS receiver (not on HP-UX)
127.127.10.x Austron 2201A GPS Timing Receiver
127.127.11.x Kinemetrics Truetime OM-DC OMEGA Receiver
127.127.12.x KSI/Odetecs TPRO-S IRIG-B / TPRO-SAT GPS
127.127.13.x Leitch: CSD 5300 Master Clock System Driver
127.127.14.x MSFEES (not on HP-UX)
127.127.15.x TrueTime GPS/TM-TMD (aliased to #5)
127.127.16.x Bancomm GPS/IRIG Ticktock
127.127.17.x Datum Programmable Time System
127.127.18.x NIST Modem Time Service (not on HP-UX 9.x)
127.127.19.x Heath WWV Receiver (not on HP-UX)
127.127.20.x NMEA (GPS?) Receiver
127.127.21.x VME GPS Receiver (not on HP-UX)
127.127.22.x PPS Clock Discipline (not on HP-UX)
127.127.23.x PTB Modem Time Service
127.127.24.x USNO Modem Time Service
127.127.25.x aliased to #5 TrueTime
127.127.26.x Hewlett Packard 58503A GPS Receiver
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 29 Oct 1997 11:20:01 GMT [-/+]
Newsgroups: comp.os.unix.internals,comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Re: Unix timekeeping and xntp [-/+]
X-Keywords: adjtimex [-/+] resolution [-/+] specification [-/+]
In article <m2sotl7j5f.fsf@isnogud.escape.de> Urs Thuermann <urs@isnogud.escape.de> writes:
> 5. Until recently I naively thought, that at each 100Hz interrupt an
> internal struct timeval is simply incremented by 10000 us, and that
> the 10000 can be adjusted up or down to slow or speed up the clock
> a little. But then I noticed that the values returned by
> gettimeofday() in Linux increase in much smaller steps, i.e. around
> 15 us. However, surely the internal clock isn't updated by a
> 1/(15us) = 66kHz interrupt. So, how is it really done?
Besides the time quantity that is incremented every timer interrupt
there are some hardware facilities to help to interpolate the time
between individual interrupts. For Linux 2.0 Pentium or better use the
processor's cycle counter for a very fine resolution (below 1
microsecond), while other CPU's on arch i386 use the registers of the
timer chip that generates periodic interrupts.
>
> 6. What exactly do adjtime() in SVR4 and adjtimex() in Linux? What
> does BSD have?
In Linux adjtime() has been implemented first I guess. The someone
decided to add the additional NTP functionality to that function,
thereby changing the name to adjtimex. Meanwhile you can even do some
more things like changing the value of "tick".
>
> 7. How does xntp use those system calls?
In Linux the ntp_adjtime and ntp_gettime (I hope I remember the names
right) are mapped to adjtimex. So ntp_gettime will return all values
in Linux, not just a few as suggested in the specification.
I only know the Linux details well...
Ulrich
From: "Brian K. Garrett" <bkg@user1.teleport.com> [-/+]
Date: 28 Oct 1997 17:42:33 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: WWVB or RS; whos hosed?
X-Keywords: daylight [-/+] DST [-/+] NIST [-/+] reset [-/+] WWV [-/+] WWVB [-/+]
Jim Pennino <specsol@primenet.com> wrote:
: I recently bought one of the Radio Shack clocks that sets itself via WWVB;
: seemed to work just fine for $39.99 (they are on sale - I can't pass up
: electronic gizmos on sale).
: Some time in the afternoon of 24 Oct it set itself back one hour. Thinking
: maybe it was a signal problem (WWVB is not particularly strong in this
: part of Calif), I force a reset. The clock stayed an hour early. The next
: thought was that RS screwed up in the daylight savings time algorithim
: and it was changing early. However, later that night, the clock was back
: to the correct time and has stayed so since, including the auto switch to
: PST.
: So, did anyone else notice anything funny about WWVB on Saturday afternoon,
: or is this an "undocemented feature" of the RS clock?
: --
: -------------------------------------------------------------------------------
: Jim Pennino
: jimp@specsol.com
: -------------------------------------------------------------------------------
I noticed a similar effect that afternoon with my radio-controlled clock
fromm Oregon Scientific. The clock sets itself four times a day, at 9:00
am and pm local time. When my clock reset itself at 3:00 pm Saturday
afternoon in set itself back an hour, to 2:00 pm. Since there is no
transmitter-call button on the Time Machine as there is with the Junghans
Mega, I had to reinitialize the clock by taking out the batteries and
putting them back in, in order to get it to Do The Right Thing.
What I suspect happened is that the clock saw the date for the time-change
approaching and reset itself without first checking to see if local time
(Pacific in my case) was after 2:00 am on October 26. This explanation
doesn't satisfy me fully because the UTC date would not have become the
26th until 5:00 pm PDT, and the clock reset itself at 3:00 pm. But for
reasons I will state below, I'm reluctant to blame WWVB for the error.
There might also have been some local interference that kept the clock
from properly receiving the DST bit in the WWVB time code, but in that
case why did the clock receive the time properly after being
reinitialized?
I had a similar problem in 1993 with a Junghans Mega, and wrote to NIST
asking for info about error-trapping in the WWVB time code. I received a
prompt and clear response from James Maxton, the engineer-in-charge of
time and frequency services, in which he explained that the WWVB code is
monitored continuously by four separate encoders, as well as three for the
WWV audio signal. There are therefore seven independent systems
constantly tracking the performance of the WWVB time-code generator, any
of which would detect an error in the signal and trip an alarm. For this
reason I'd be quicker to suspect a defective chip or buggy algorithm
in the clock than an error in the signal from WWVB as the cause of a
radio-controlled clock's showing an incorrect time.
Brian Garrett <bkg@teleport.com>
From: Urs Thuermann <urs@isnogud.escape.de> [-/+]
Date: 28 Oct 1997 21:00:12 +0100 [-/+]
Newsgroups: comp.os.unix.internals,comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Unix timekeeping and xntp [-/+]
X-Keywords: adjtimex [-/+] delay [-/+]
Hi,
I'd like to understand time keeping in UNIX systems and I have many
questions on this, some of which may be somewhat offtopic in some
groups.
A short answer to each of these questions would probably give an
easier start reading sources and/or other documents. Pointers are
also welcome. I am especially interested in the way things are
implemented in Linux but also in other Unices.
So here it goes:
1. Interrupts:
- What periodic interrupts are used in UNIX systems?
- Is time keeping and process scheduling done in the same interrupt
or is that separate?
- Are these interrupts generally generated by an RTC or are other
timers used?
2. Can the interrupts used to step the clock be lost, e.g., at times of
high i/o load with many other, maybe higher priority interrupts?
Or are they executed with some delay when the higher priority
interrupt routine has finished?
3. Do the hardware RTC and the UNIX software clock run independently,
or do they some common clock. I think the RTC is often built using
an RC oscillator while other clocks are quartz bases.
4. Is the RTC used at boot time only, i.e. to set the UNIX internal
clock, or is it also used at later times?
5. Until recently I naively thought, that at each 100Hz interrupt an
internal struct timeval is simply incremented by 10000 us, and that
the 10000 can be adjusted up or down to slow or speed up the clock
a little. But then I noticed that the values returned by
gettimeofday() in Linux increase in much smaller steps, i.e. around
15 us. However, surely the internal clock isn't updated by a
1/(15us) = 66kHz interrupt. So, how is it really done?
6. What exactly do adjtime() in SVR4 and adjtimex() in Linux? What
does BSD have?
7. How does xntp use those system calls?
urs
From: James Youngman <JYoungman@vggas.com>
Date: 29 Oct 1997 10:36:38 +0000 [-/+]
Newsgroups: comp.unix.internals,comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Re: Unix time keeping and xntp
X-Keywords: adjtimex [-/+] delay [-/+] FAQ [-/+]
>>>>> "Urs" == Urs Thuermann <thuerman@ibr.cs.tu-bs.de> writes:
Urs> - What periodic interrupts are used in UNIX systems? - Is
Urs> time keeping and process scheduling done in the same interrupt
Urs> or is that separate? - Are these interrupts generally
Urs> generated by an RTC or are other timers used?
The RTC can provide an interrupt but it isn't generally used. If you
compile in the RTC clock driver, I think you can use it.
Urs> 2. Can the interrupts used to step the clock be lost, e.g., at
Urs> times of high i/o load with many other, maybe higher priority
Urs> interrupts? Or are they executed with some delay when the
Urs> higher priority interrupt routine has finished?
Usually the latter.
Urs> 3. Do the hardware RTC and the UNIX software clock run
Urs> independently, or do they some common clock. I think the RTC
Urs> is often built using an RC oscillator while other clocks are
Urs> quartz bases.
They're independent.
Urs> 4. Is the RTC used at boot time only, i.e. to set the UNIX
Urs> internal clock, or is it also used at later times?
If you use the RTC driver you can use it later.
Urs> 5. Until recently I naively thought, that at each 100Hz
Urs> interrupt an internal struct timeval is simply incremented by
Urs> 10000 us, and that the 10000 can be adjusted up or down to slow
Urs> or speed up the clock a little. But then I noticed that the
Urs> values returned by gettimeofday() in Linux increase in much
Urs> smaller steps, i.e. around 15 us. However, surely the internal
Urs> clock isn't updated by a 1/(15us) = 66kHz interrupt. So, how
Urs> is it really done?
It reads the downcount value from the 8253 to find out hpow long it
will be until the next timer interrupt.
Urs> 6. What exactly do adjtime() in SVR4 and adjtimex() in Linux?
Urs> What does BSD have?
Urs> 7. How does xntp use those system calls?
See the FAQ for comp.protocols.ntp
Urs> urs
From: hjj@news1.tele.dk (Hans J Jakobsen) [-/+]
Date: 29 Oct 1997 10:25:45 +0100 [-/+]
Newsgroups: comp.os.unix.internals,comp.os.linux.development.system,comp.protocols.time.ntp
Subject: Re: Unix timekeeping and xntp [-/+]
X-Keywords: resolution [-/+] stability [-/+]
Urs Thuermann <urs@isnogud.escape.de> writes:
> - Is time keeping and process scheduling done in the same interrupt
> or is that separate?
In better systems you can read a counter running at a high rate to get
the time. Ie clock resolution is not tied to interrupt.
> - Are these interrupts generally generated by an RTC or are other
> timers used?
Other.
>3. Do the hardware RTC and the UNIX software clock run independently,
> or do they some common clock. I think the RTC is often built using
> an RC oscillator while other clocks are quartz bases.
The RTC is often the most stable. Quartz stability can be from 10^-5 to
maybe 10^-8. The oscilators found in the computers is not the most stable.
>4. Is the RTC used at boot time only, i.e. to set the UNIX internal
> clock, or is it also used at later times?
In Solaris (Sparc) the stability of the internal clock is so lousy that
Sun are stepping it to match the RTC from time to time.
When you start xntpd you will have to disable this.
>5. Until recently I naively thought, that at each 100Hz interrupt an
> internal struct timeval is simply incremented by 10000 us, and that
> the 10000 can be adjusted up or down to slow or speed up the clock
> a little. But then I noticed that the values returned by
> gettimeofday() in Linux increase in much smaller steps, i.e. around
> 15 us. However, surely the internal clock isn't updated by a
> 1/(15us) = 66kHz interrupt. So, how is it really done?
In some system they even count in nano seconds.
In the PC architecture there is a register that is incremented every 0.82us.
The code to read the register take about 16us to execute because it has to
do several IOinstructions and sometimes do the reading twice.
I think Sparc has a similar register but in SunOs 4 it was not standard to
use it for timing (In the source to xntp there is somthing about installing
a module for better clock resolution under SunOs 4)
In the Intel pentium there is a register(counter) running at the processors clockrate
that you can read easily.
Ultra Sparc also have such a register and can even schedule an interrupt
n cycles later.
/hjj
--
Tele Danmark Erhverv, Data Divisionen TLF: +45 8947 3339
Hans J Jakobsen FAX: +45 8947 3308
Skanderborgvej 234 st tv
DK 8620 Viby J Danmark Internet:hjj@datacom.dk400.dk
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 30 Oct 1997 22:08:29 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: "synchronization lost" problem [-/+]
X-Keywords: ACTS [-/+] dialup [-/+] firewall [-/+] reset [-/+] synchronized [-/+]
Ross Parker (parker@bctm.com) wrote:
:>I'm using the ACTS dialup clock driver to get my time due to firewall
:>restrictions.
:>I have a problem where xntpd will hook up fine and run for a number of
:>hours, then I'll get the following in my ntp log file:
:>30 Oct 09:41:12 xntpd[22380]: time reset (step) 0.309577 s
:>30 Oct 09:41:12 xntpd[22380]: synchronisation lost
:>I get the 'synchronization lost' EVERY TIME there's a time reset.
This is the normal behavior of xntpd. Whenever you make a step change
(bigger than 128 milliseconds) you are no longer synchronized to the source
BY DEFINITION. All of the filters and accumulators are cleared, and you
must go through the synchronization process from scratch again. This takes
several queries to the timeserver, as you have noticed. This is why the
modem/dialup service is not considered as good as a true network
connection.
How often are you making the calls to the timeserver?
The underlying problem is that your local system clock has drifted by more
than 128ms in the interval between phone calls to the timeserver. You will
need to go a few hours (or maybe even days) making more frequent calls
until xntpd stabilizes and gets a good idea of your system clock's steady
drift rate. BTW, this only works if you keep xntpd alive full time, 24
hours a day. Don't reboot! But after things have stabilized then you can
adjust the call interval to longer and longer periods. One call per day
(typically at 3am) should be more than enough (unless you have a
tremendously drifty Sun manchine).
--
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]
Date: 1 Nov 1997 00:35:28 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: ACTS modem time #18
X-Keywords: ACTS [-/+] delay [-/+] dispersion [-/+] fudge [-/+] HP-UX [-/+] maxpoll [-/+] minpoll [-/+] poll [-/+] PPS [-/+]
I'm trying to get the ACTS modem time service (driver #18) working
on HP-UX 10.20, and am having mysterious problems. The daemon xntpd is
talking to the modem and making the calls, and xntpdc shows that the
reachability is rising. But no time statistics ever appear for this
source, and dispersion stays pegged at 16.0000. What do I need to fix
here?
from /etc/ntp.conf:
-------------------
server 127.127.1.0 # local clock
server 127.127.18.1 mode 0 minpoll 4 maxpoll 6
fudge 127.127.18.1 time2 64
phone atdt9-1-303-4944774
I tried connecting to the modem with "cu" and dialing the number by hand.
Connection was successful, and I got reasonable looking time strings from
ACTS. When the daemon xntpd is running I can hear through the modem
speaker the tone dialing, the carrier connection, the things you would
expect from a modem.
This is probably not a specific HP-UX problem. Can anyone that has made
this work on any system give me some advice?
Also, does anyone know what the "=" in the first column of xntpdc "peers"
output stands for? I am used to seeing these designations from ntpq
"peers":
"*" selected for synchronization
"#" selected for synchronization but distance exceeds maximum
"o" selected for synchronization, PPS signal in use
"+" included in the final selection set
"x" designated falsticker by the intersection algorithm
"." culled from the end of the candidate list
"-" discarded by the clustering algorithm
"blank" discarded due to high stratum and/or failed sanity checks
--
-> My $.02 only. Not an official statement from HP.
--
As far as we know, our computer has never had an undetected error.
---------------------------------------------------------------------------
David Dalton dalton@cup.hp.deletethis.com 408/447-3016
xntpdc> peers
remote local st poll reach delay offset disp
=======================================================================
=LOCAL(0) 127.0.0.1 3 64 377 0.00000 0.000000 0.01001
*hpisrhw.cup.hp. 15.13.108.10 1 64 377 0.00201 -0.000205 0.00049
=NIST_ACTS(1) 127.0.0.1 0 1024 1 0.00000 0.000000 16.0000
=cupertino.cns.h 15.13.108.10 2 64 377 0.00334 -0.003938 0.00186
=hpntcyh.cup.hp. 15.13.108.10 3 64 377 0.00725 -0.003880 0.00076
remote local st poll reach delay offset disp
=======================================================================
=LOCAL(0) 127.0.0.1 3 64 377 0.00000 0.000000 0.01001
*hpisrhw.cup.hp. 15.13.108.10 1 256 377 0.00272 -0.000333 0.00023
=NIST_ACTS(1) 127.0.0.1 0 1024 3 0.00000 0.000000 16.0000
=cupertino.cns.h 15.13.108.10 2 256 377 0.00317 -0.003321 0.04410
=hpntcyh.cup.hp. 15.13.108.10 3 1024 377 0.00441 -0.004740 0.00061
remote local st poll reach delay offset disp
=======================================================================
=LOCAL(0) 127.0.0.1 3 64 377 0.00000 0.000000 0.01001
*hpisrhw.cup.hp. 15.13.108.10 1 512 377 0.00198 -0.001210 0.00040
=NIST_ACTS(1) 127.0.0.1 0 1024 7 0.00000 0.000000 16.0000
=cupertino.cns.h 15.13.108.10 2 512 377 0.00465 -0.002547 0.00819
=hpntcyh.cup.hp. 15.13.108.10 3 1024 377 0.00388 -0.004094 0.00041
remote local st poll reach delay offset disp
=======================================================================
=LOCAL(0) 127.0.0.1 3 64 377 0.00000 0.000000 0.01001
*hpisrhw.cup.hp. 15.13.108.10 1 512 377 0.00197 -0.001964 0.00060
=NIST_ACTS(1) 127.0.0.1 0 1024 17 0.00000 0.000000 16.0000
=cupertino.cns.h 15.13.108.10 2 1024 377 0.00320 -0.003174 0.00070
=hpntcyh.cup.hp. 15.13.108.10 3 1024 377 0.00375 -0.005322 0.00104
From: "Doug Hogarth" <DougHo@niceties.com> [-/+]
Date: 31 Oct 1997 02:55:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NIST or USNO modem configs [-/+]
X-Keywords: AIX [-/+] NIST [-/+] USNO [-/+]
As far as I know, the WinNT port of xntpd doesn't include "reference clock"
support such as the one you mention.
I'm not sure if it suits your needs, but for WinNT another alternative is to
look at the TimeServ program as described at
http://home1.gte.net/dougho/TimeServ.html - note that I recommend dialing
NIST rather than USNO because USNO's remode digital loopback feature
sometimes causes compatibility problems with non-Hayes modems (you have to
be sure to configure them correctly, etc).
William R. Pennock wrote in message <3457C5FF.BE1C3F2@transquest.com>...
>I have tried both Unix (AIX) and NT 4.0, and I am unable to get a modem
>to call out and get the time. What am I missing here? Is there some
From: "William R. Pennock" <bill.pennock@transquest.com>
Date: Wed, 29 Oct 1997 18:25:51 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: NIST or USNO modem configs [-/+]
X-Keywords: ACTS [-/+] AIX [-/+] delay [-/+] fudge [-/+] NIST [-/+]
I have tried both Unix (AIX) and NT 4.0, and I am unable to get a modem
to call out and get the time. What am I missing here? Is there some
script that needs to be written? Under unix, I need to link a device
with the right name to the serial port with the modem attached, is there
a similar procedure on NT? The following is from the ntp.conf file. I
get no noise from the modem at all; there are no attempts made to use
the modem. What gives?
Bill Pennock
Delta Technology, Inc.
(404) 773-8923
ntp.conf:
#
# NIST Automated Computer Time Service. This driver calls a special
# telephone number in Boulder, CO, to fetch the time directly from the
# NIST cesium farm. The details of the complicated calling program are
# in the README.refclock file. The Practical Peripherals 9600SA modem
# does not work correctly with the ACTS echo-delay scheme for
# automatically calculating the propagation delay, so the fudge flag2 is
# set to disable the feature. Instead, we add a fudge time1 of 65.0 ms
# so that the driver time agrees with th e1-pps signal to within 1 ms.
# The phone command specifies three alternate telephone numbers,
# including AT modem command prefix, which will be tried one after the
# other at each measurement attempt. In this case, a cron job is used to
# set fudge flag1, causing a measurement attempt, every six hours.
#
server 127.127.18.1
fudge 127.127.18.1 time1 0.0650 flag2 1
phone atdt813034944774 atdt813034944785 atdt813034944774
From: Ross Parker <parker@bctm.com>
Date: Thu, 30 Oct 1997 10:40:42 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: "synchronization lost" problem [-/+]
X-Keywords: ACTS [-/+] dialup [-/+] dispersion [-/+] firewall [-/+] NIST [-/+] reset [-/+]
Hi,
I have a Solaris 2.5.1 system running xntpd version 3-5.90.
I'm using the ACTS dialup clock driver to get my time due to firewall
restrictions.
I have a problem where xntpd will hook up fine and run for a number of
hours, then I'll get the following in my ntp log file:
30 Oct 09:41:12 xntpd[22380]: time reset (step) 0.309577 s
30 Oct 09:41:12 xntpd[22380]: synchronisation lost
I get the 'synchronization lost' EVERY TIME there's a time reset.
At this point, dispersion goes back up to 16 and it takes a number of
good calls back to NIST (5 or 6?) before the clock is considered sane
again.
It'll then work fine for a few hours and will die again.
The reset occurs at the same time as a call to NIST, and my clock stats
show that the call was successful and generates what appears to be a
decent-looking time.
The step time is the same as the clock offset (filtoffset using ntpq's
rv command).
xntpd believes it has a good time from the clock, is trying to correct
for it, and
this sends things out of whack.
So... is this something that can be corrected? Is it normal and just
looks strange
due to the large polling interval with the dialup clock?
Thanks,
Ross
--
Ross Parker | UNIX Sys Admin, PERL and C toolsmithing,
Systems/Network Admin | Networking and security, CGI applications.
BC Tel Mobility |
| Words to live by:
parker@bctm.com | You're never too old to have a happy
childhood!
From: John Balogh <JDB@psu.edu>
Date: Thu, 30 Oct 1997 10:25:16 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Literature
X-Keywords: configuration [-/+] implementation [-/+] Mills [-/+] RFC-1305 specification [-/+]
Frank W. Mortensen wrote:
> Can anyone recommend any good literature and/or URLs on NTP v3? I'm
> mainly concerned about the behaviour of the NTP in general, and not so
> much about configuration specifics for particular NTP software.
>
> Something that describes various topological scenarios, how the
> correct time is deduced in such scenarious, the criteria for
> declaring other servers "insane" when sources at various Stratum
> levels are available etc., would be ideal.
>
> Thanks,
> Frank W Mortensen
> Telenor Nett AS
> Oslo, Norway
From the time server page:
http://www.eecis.udel.edu/~ntp/
follow the link to "Introduction to NTP"
then only link in the first full paragraph:
http://www.eecis.udel.edu/~ntp/database/html_xntp3.5f/biblio.html
has text (and links provided) stating:
"The formal specification of the NTP Version 3 protocol is
contained in:
Mills, D.L. Network Time Protocol (Version 3) specification,
implementation and analysis. Network Working Group Report RFC-1305"
Hope this helps!
John Balogh
http://jdb.psu.edu/john.html
From: "Bob Vance" <Bob_Vance@sbm.com> [-/+]
Date: 3 Nov 1997 18:11:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: want source [-/+]
X-Keywords: bug [-/+] filter [-/+] GNU RFC [-/+] syslog [-/+]
Bob Vance <Bob_Vance@sbm.com> wrote
> Where can I get source to ntp daemon for port to an
> old Unix system.
Thanks to:
Ulrich Windl <ulrich.windl@rrzc1.rz.uni-regensburg.de>
and Bruce Bartram <bwb@etl.noaa.gov>
for pointing me to
http://www.eecis.udel.edu/~ntp
Bruce also mentioned
ftp://ftp.udel.edu/pub/ntp/
and also supplied the following helpful info:
It is likely that any BSD derived un*x has the required network
features and the adjtime() call required and has already been
"ported". With the GNU autoconf, things might be as simple as:
gunzip -c xntp3-5.91.tar.gz | tar xf -
cd xntp3-5.91
./configure
make
The latest version is 3-5.91, but it gave me a few gcc warning messages
(which I think can be ignored, but I haven't tested any of these very
new versions). [...] If your un*x has one of the standard flavors
of sockets and has something like the BSD adjtime(), there is hope.
All versions of NTP at the same main level work fine together. Version
3 is RFC 1305, and supports version 1 and 2 clients and servers contacted
can be flagged in the ntp.conf file to talk the old flavor.
... 3.5f (a good stable version).
The code had a major rework to make it much more portable and to clean
up lots of details and became 3-5.86. AVOID 3-5.86 through 3-5.89.7
as there were some serious troubles. I started running 3-5.89.8 last
winter (Feb ?) and am fairly happy. 3-5.90.2 has some improvements I
want, but I haven't cranked it up yet.
I wouldn't work very hard to upgrade a working 3.5f. It might have a
few new tricks that will only help the first few hours of a new xntpd
installation, a slightly improved filter and an important bug fix for
a very obscure bug (daemon dies with syslog message "step too large
###" where the ### is like 2^30 seconds) that has only been triggered
by one broken public stratum 1 server.
( [...] version 4 is coming very soon).
-----------------------------------------------
Tks | bobv@sbm.com
BV | bobvance@alumni.caltech.edu
Bob Vance
VP Technical Consulting, SBM
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
===============================================
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 04 Nov 1997 14:53:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP and authentication
X-Keywords: controlkey DES [-/+] FAQ [-/+] keytype password [-/+] requestkey reset [-/+] trustedkey
In article <63n14p$8hn@ultra1.samart.co.th> poon@ultra1.samart.co.th (Poon Rojanasoonthon) writes:
> Hi all,
> I'm running xntp3-5.91, I tried to use xntpdc to reset allpeers
> but everytime I tried, xntpdc always say "permission denied".
> Below is a part of my cfg.
>
> /etc/ntp.conf
> -----
> keys /usr/local/etc/ntp.keys # path for keys file
> trustedkey 3 4 5 6 14
> requestkey 15
> controlkey 14
> -----
>
> /usr/local/etc/ntp.keys
> -----
> 14 A keys
> 15 A password
> -----
>
> I used xntpd with keyid "14" and password of MD5 "keys", is it rigt ?
> Any idea please ?
It seems to be a candidate for the FAQ: Default keytype has changed
form "DES" to "MD5" recently (due to strange US export laws, etc.).
You should try "keytype des" in xntpdc...
>
> Regards,
> Poon Rojanasoonthon
From: james.davis@pobox.com
Date: 4 Nov 1997 21:47:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd on Solaris 2.6
X-Keywords: checksum
Jason Ahrens <jason.ahrens@fulcrum.com> wrote:
> I am attempting to use Sun's supplied verision on xntpd with Solaris 2.6
> I cannot find something similar to 'tickadj' that comes with the source
> distribution of xntpd...
> Does anyone know of any special steps then that needs to be taken to get this
> working?
> Jason
Search for xntp on http://docs.sun.com in the Solaris 2.6 docs area.
--
James Davis, Sr. UNIX Systems Engineer/Administrator/Webmaster
mailto:james.davis@pobox.com http://pobox.com/~james.davis
.sig 64 bit checksum: 0xFEEDFACEDEADBEEF
From: Harlan Stenn <stenn@whimsy.udel.edu> [-/+]
Date: 05 Nov 1997 13:22:02 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: ntp-4.0.70a is available for Wizards.
X-Keywords: documentation [-/+]
ntp-4.0.70a is available for WIZARDS ONLY at:
ftp://ftp.udel.edu/pub/ntp/testing/
Please don't download this unless you're willing to FIX and SUPPLY
PATCHES to any problems you find.
There's a new script in the top-level directory called "build", which
will build the package in a subdir named something like:
A.`config.guess`
or A.`config.guess`-$CC
Nobody's keeping the ChangeLog up-to-date at the moment, and the
documentation hasn't been updated.
The "x" is gone from the distribution name, and xntpd is now called
ntpd, and xntpdc is now called ntpdc.
Tick and tickadj are No More. There's still cruft that must be removed
from configure.in and various Makefile.am's .
H
From: Tony Scholes <tonys@beacon.co.uk>
Date: Sat, 01 Nov 1997 09:19:42 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: want source [-/+]
Bob Vance wrote:
>
> Where can I get source to ntp daemon for port to an
> old Unix system.
> -----------------------------------------------
> Tks | bobv@sbm.com
> BV | bobvance@alumni.caltech.edu
> Bob Vance
> VP Technical Consulting, SBM
> Vox 770-446-0404 11455 Lakefield Dr.
> Fax 770-409-3112 Duluth, GA 30097-1511
> ===============================================
Here :-
http://www.eecis.udel.edu/~ntp/
--
Tony Scholes
Technical Manager
===============================================================================
___ ___ ___ ___ ___ ___ Beacon Computer Services
/__/ /__ /__/ / / / / / The Friars, 82 High Street South
/__/ /__ / / /__ /__/ / /. Dunstable, Beds. UK
LU6 3HD
Tel: +44 (0)1582 478888 Email: tonys@beacon.co.uk
Fax: +44 (0)1582 478810 Compuserve: 72660,207
===============================================================================
From: "Doug Hogarth" <DougHo@niceties.com> [-/+]
Date: 5 Nov 1997 15:41:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Configuring NTP on NT help
X-Keywords: configuration [-/+] Spectracom [-/+] Windows [-/+] WWV [-/+]
No refclocks are currently supported under Windows NT.
Since you mention my TimeServ program, one approach is to keep that running
to set the machine's time from the Spectracom, and then just use xntpd on
the same machine as a server (not a client).
David J. Effa wrote in message <63l5o5$1fd2@fizban.pprd.abbott.com>...
>I got a NT ported version of NTP today (V3.5-90-3) and I started to
>configure NTP on this server. I have a Spectacom Netclock/2 WWV clock
radio
>that I am trying to use. It's connected to COM1. In the NTP.CONF file I
>used server 127.127.4.1 (clock type =4 = Spectacom, unit number = 1 = COM1)
>hoping this will work. It did not. Is there any NTP configuration that I
>can use to get the time from this clock? The server will be used on our
>intranet only. I did try using TIMESERV from the NT resource kit and that
>was able to read the clock off of COM1 but that is not a true blue V3 NTP
>server and I really don't want to use this. I am new at configuring NTP
and
>the configuration help I have found is 99% UNIX based which does not help.
>
>Any tips will be greatly appreciated!!!!
>
>Regards,
>
>David Effa
>
>
>
From: Wernke zur Borg <wzb@AniteSystems.de>
Date: Wed, 05 Nov 1997 09:55:38 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Need help with simple xntp configuration [-/+]
X-Keywords: broadcast [-/+] configuration [-/+] fudge [-/+]
We need some help to setup ntp.conf for our very simple configuration.
We have one server (SPARC 10 or Ultra 1, Solaris 2.5) connected via
serial port to an external time code reader. We use a "private" driver
reading that time information every second and doing adjtime()
periodically to synchronise the system clock to the external time
source. This used to work fine.
We now got a workstation (same architecture and OS) connected to our
server on a private LAN such that only the two systems make up a
network. There is no connectivity to the outside world. Eventually we
will get more workstations in the network.
The plan is to use xntp to synchronise the workstation(s) with the
server. We have installed xntp on both systems. The problem is that as
soon as xntp is started on the server, our own driver no longer
succeeds to set the time. Apparently xntp also does adjtime() and
starts fighting with our driver. This we can see from the 'olddelta'
field returned by the system in the call to adjtime(). Even if we have
called adjtime() with a delta of several seconds, the olddelta is set
to zero in the seconds field one second later.
The ntp.conf of the server has the 'broadcast' line enabled. I have
tried with and without a 'server 127.127.1.0' line but have not
noticed any difference. I had assumed taking out the 'server' line
would prevent xntp to set the time on the local host. There was also a
line 'fudge 127.127.1.0 stratum 9' in the file but I don't know what
it is good for.
The ntp.conf on the workstation has only the 'broadcastclient' line
enabled.
The main question is how can we prevent xntp to touch the system time
on the server? We just want it to read and forward the time but not to
change it.
I hope the description is clear enough to allow somebody helping us in
setting up the configuration correctly.
Any response will be appreciated.
______________________________________________________________________
Wernke zur Borg Tel: +49-6155-8717-22
Anite Systems GmbH Fax: +49-6155-8717-87
Im Leuschnerpark 4 email: wzb@AniteSystems.de
D-64347 Griesheim / Germany
From: ckc@dmi.min.dk (Casper K. Clausen) [-/+]
Date: 05 Nov 1997 11:41:59 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Need help with simple xntp configuration [-/+]
X-Keywords: adjustment [-/+] broadcast [-/+] documentation [-/+] fudge [-/+]
>>>>> "W" == Wernke zur Borg <wzb@AniteSystems.de> writes:
W> The ntp.conf of the server has the 'broadcast' line enabled. I have
W> tried with and without a 'server 127.127.1.0' line but have not
W> noticed any difference. I had assumed taking out the 'server' line
W> would prevent xntp to set the time on the local host. There was also a
W> line 'fudge 127.127.1.0 stratum 9' in the file but I don't know what
W> it is good for.
This last line would be good if you had a very unreliable local clock,
and only wanted ot use it as a fallback when nothing else worked. Look
in the documentation, where all the keywords used in ntp.conf are
explained in detail.
W> The main question is how can we prevent xntp to touch the system time
W> on the server? We just want it to read and forward the time but not to
W> change it.
The docs will also tell you about using the 'disable' keyword to
disable specific features of xntpd, e.g. adjustment of the local clock.
Regards,
Kvan.
--
-------Casper Kvan Clausen------ | 'Ah, Warmark, everything that passes
----------<ckc@dmi.dk>---------- | unattempted is impossible.'
Lokal 544 |
I do not speak for DMI, just me. | - Lord Mhoram, Son of Variol.
From: Greg Schueman <schueman@ix.netcom.com>
Date: Thu, 06 Nov 1997 22:10:03 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpd for MVS or OS/390???
X-Keywords: mainframe [-/+] MVS [-/+]
In so much as I generally ignore OS/390 stuff (being a non-mainframer),
I have noticed a number of postings that indicate that you need to use
the IBM Sysplex timers hooked to an OS/2 box for a masterclock, which
can then be running NTP to get it's time. Hopefully, someone will
correct my ramblings with the correct details for your purposes.
NTP doesn't run native on the mainframe.
-Greg
adennis@swp.com wrote:
> Is there a ntpd or simillar process available for
> MVS or OS/390?
>
> adennis@swp.com
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Fri, 07 Nov 1997 13:25:19 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: How can i set the pool interval of the client part?
Pascal Schirrmann - MAI France wrote:
>
> I'm a new user of xntpd. This works very fine on my Network.
>
> We don't have a local clock so i want to chek the time on internet.
> This also works fine, but too fine:
> We have acces to Internet via an RNIS Link. So i want to synchronise
> my local(s) ntp server(s) only one time (or two) a day.
> This, of course will not give us a nuclear time, but should be
> suffisiant for our need.
Use ntpdate instead, it was designed to do single polls of NTP servers.
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: j.b.swenker@ptt-telecom.nl (johan swenker) [-/+]
Date: Mon, 10 Nov 97 14:02:53 MET [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Connection Refused? [-/+]
In article <34642D61.C7D1EB2A@ucsd.edu>, drees@ucsd.edu says...
>
>I get the following error in my logs. However, xntpd seems to be
>working OK. What does that error message mean?
>
>Nov 8 00:13:47 dt6h3n26 xntpd[81]: recvfrom() fd=4: Connection refused
This indicates some kind of network problem. Probably a server to which
xntpd wants to connect does not allow such a connection. Reasons are
firewalls, filtering routers or just a system which does nit run xntpd.
If you have an other server available, xntpd works. If the only (real)
server doesn't work, xntpd doesn't (really) work.
Remark: fd=4 means filedescriptor 4. This is a tcp/ip socket to another
system. To find out more about this file descriptor, start xntpd with
strace xntpd -d 2>&1 | less
(I'm not sure about the -d, I use it to prevent xntpd to become a deamon).
Succes Johan
--
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: rnews@whirlpool.river.com (Richard Johnson) [-/+]
Date: Sun, 09 Nov 1997 16:49:37 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp,sci.geo.satellite-nav
Subject: Inexpensive GPS clock for NTP? [-/+]
X-Keywords: antenna [-/+] Garmin [-/+] NMEA [-/+] prefer [-/+]
I'm seeking an inexpensive GPS clock for my NTP servers. I'd prefer a
solution under $200, but I haven't been able to get there yet.
The main features I need are a weather-proof antenna enclosure to live on
the roof, NMEA messages with date and time, and 1pps timing +/- at most
500us.
I'm considering the following options.
1) Ashtech G8 board [1] with misc. fittings and Lowe antenna [2].
~$350?
2) Garmin GPS 31 TracPak [3].
~$300?
Are there any show-stoppers with those you want to warn me about? What
about other hardware I should look at?
Richard
[1] <http://www.ashtech.com/>
[2] <http://www.lowe.co.uk/gpsant.html>
[3] Garmin doesn't have any info on their site about this model, but
NavTech sells it <http://www.navtechgps.com/>
--
To reply via email, make sure you don't enter the whirlpool on river right.
From: samsvl@nlr.nl (storm van leeuwen s.)
Date: 10 Nov 1997 07:51:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Inexpensive GPS clock for NTP? [-/+]
X-Keywords: antenna [-/+] Garmin [-/+] NMEA [-/+] prefer [-/+]
Richard Johnson (rnews@whirlpool.river.com) wrote:
: I'm seeking an inexpensive GPS clock for my NTP servers. I'd prefer a
: solution under $200, but I haven't been able to get there yet.
: The main features I need are a weather-proof antenna enclosure to live on
: the roof, NMEA messages with date and time, and 1pps timing +/- at most
: 500us.
: I'm considering the following options.
: 1) Ashtech G8 board [1] with misc. fittings and Lowe antenna [2].
: ~$350?
: 2) Garmin GPS 31 TracPak [3].
: ~$300?
: Are there any show-stoppers with those you want to warn me about? What
: about other hardware I should look at?
: Richard
: [1] <http://www.ashtech.com/>
: [2] <http://www.lowe.co.uk/gpsant.html>
: [3] Garmin doesn't have any info on their site about this model, but
: NavTech sells it <http://www.navtechgps.com/>
: --
: To reply via email, make sure you don't enter the whirlpool on river right.
Hi Richard,
More alternatives on my pages at http://callisto.worldonline.nl/~samsvl.
Hope it helps.
Sam
--
Sam Storm van Leeuwen phone +31-20-5113562
National Aerospace Laboratory NLR fax +31-20-5113210
P.O. Box 90502 e-mail samsvl@nlr.nl
1006BM Amsterdam - The Netherlands
From: ckc@dmi.min.dk (Casper K. Clausen) [-/+]
Date: 10 Nov 1997 10:54:13 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: local clock ignores NTP [-/+]
X-Keywords: dosynctodr [-/+]
>>>>> "T" == Tiaan van Aardt <tvaREMOVE@REMOVEwasp.co.za> writes:
T> NTP itself runs fine, and other systems can synch to this system, only,
T> the system's own local clock doesn't seem to listen to ntp's
T> adjustments. Is this a problem with how the system's cmos clock
T> interacts with the system clock?
'tickadj -s' will disable dosynctodr, which will stop your local clock
from being modified by the CMOS clock. See the man page for tickadj;
you might want to look into its other options.
Regards,
Kvan.
--
-------Casper Kvan Clausen------ | 'Ah, Warmark, everything that passes
----------<ckc@dmi.dk>---------- | unattempted is impossible.'
Lokal 544 |
I do not speak for DMI, just me. | - Lord Mhoram, Son of Variol.