Subject: none (auto-inserted) [-/+]
From: Frank Kardel <Frank.Kardel@informatik.uni-erlangen.de> [-/+]
To: lichtin@olsen.ch
Date: Wed, 2 Jun 93 13:41:01 +0200 [-/+]
Please let the daemon run all the time. Then it will be able to keep
the time with 128ms and all is well. NTP is not designed for casual use.
============================================================================
Subject: none (auto-inserted) [-/+]
From: Mills@UDEL.EDU [-/+]
Date: 5 Jun 93 19:30:05 GMT [-/+]
X-Keywords: dosynctodr [-/+] implementation [-/+] jitter [-/+] NIST [-/+] reset [-/+] USNO [-/+] WWVB [-/+]
Rick & Co.,
A few comments on your faq compendium follow. Sorry I don't have the
photonic bandwidth to eyeball the ntp newsgroup directly.
All Sun4s I know of have the local oscillator frequency at least
100 ppm fast, so the -t 9999 argument to tickadj is almost always
required. It is a good idea to get this right, whether 9999 or
something else, as the residual error affects the actual jitter
of the clock, as well as the frequency error should the NTP daemon
be interrupted for some reason. It is always the case that dosynctodr
should be disabled. While I haven't laid paw to SunOS 4.1.3 yet,
I doubt it is any different than 4.1.1 in these areas.
Rob Ullmann mentions an untainted implementation ex spec. I would very
much like to hear of such adventures and what holes remain in the
spec. It will also help the case if and when the spec is advanced
beyond the present Draft Standard status. Frankly, my experience in
promoting the present status has left me rather disenchanted with
the standards process, so advancement is not high on my agenda.
I don't think you want to meddle with clkdrift; it causes the differenct
between the tod clock and system clock to be displayed, if more than
one tick apart. In fact, if dosynctodr is NOT reset, xntp will not work
at all.
Fixup on anachronisms: So far as I know, NIST is headquartered in
Gaithersburg, MD, WWV and WWVB transmitters are at Ft Collins, CO.
Conventional wisdom (as opposed to Politically Correct) is that
USNO keeps the time and NIST keeps the frequency, but each reads
each other's timekeeper's notices. As for GPS time relative to UTC
time, you need to be equally delicate on turf. GPS receivers keep
GPS time as coordinated within GPS and may not split the weenieseconds
with respect to UTC. Without the military codes, GPS users are not
expected to achieve accuracies much better than LORAN-C, allegedly
0.25 nm or well over a microsecond. Don't believe it; with a good
timing receiver, 5-7 satellite averaging, a decent local timebase
and occasional discipline to LORAN-C, I'm getting better than 100
ns almost all of the time. This is verified by cesium oscillator
calibrated to USNO and is much better than early civilian GPS
receivers.
Dave
============================================================================
Subject: none (auto-inserted) [-/+]
From: cjj@spdev.east.sun.com (Christopher Jackson - Special Projects) [-/+]
Date: 6 Jun 93 14:55:16 GMT [-/+]
Organization: Sun Microsystems, Columbia MD
X-Keywords: adjustment [-/+] bug [-/+] dosynctodr [-/+] jitter [-/+] Mills [-/+]
In article <9306051530.aa08395@huey.udel.edu> Mills@UDEL.EDU writes:
>All Sun4s I know of have the local oscillator frequency at least
>100 ppm fast, so the -t 9999 argument to tickadj is almost always
>required. It is a good idea to get this right, whether 9999 or
>something else, as the residual error affects the actual jitter
>of the clock, as well as the frequency error should the NTP daemon
>be interrupted for some reason. It is always the case that dosynctodr
>should be disabled.
This is not quite correct. While our oscillators are not perfect
(otherwise there'd be no need for NTP, right? :-) ), the consistent
100ppm error is due to software, rather than hardware. Previous
versions of SunOS 4.X had a bug where the real-time clock register was
initialized to one less than the proper value. The clock interrupt
thus fired one tick too early, and the system clock gained an extra
1us every 10 ms.
>While I haven't laid paw to SunOS 4.1.3 yet,
>I doubt it is any different than 4.1.1 in these areas.
This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which
the -t 9999 adjustment should no longer be necessary. (Yes, you
do still need to disable dosynctodr.)
Chris Jackson <cjj@sun.com>
============================================================================
Subject: none (auto-inserted) [-/+]
From: aegl@ossi.com (Tony Luck) [-/+]
Date: 8 Jun 93 17:42:11 GMT [-/+]
Organization: Fujitsu Open Systems Solutions, Inc.
X-Keywords: adjustment [-/+] FAQ [-/+]
gdonl@sunrise.ssi1.com (Don Lewis) writes:
>I'm not so sure it is fixed. Our two Sparc 2's are running 4.1.2,
>and with the -t 9999 adjustment, they are off by 19ppm and 34ppm.
>Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm.
>This is a small sample, but the 106ppm error is more than I would
>have expected.
A few more data points about how far out some Sun4's crystals can be. Most
of these are IPXen, with a couple of SPARCstation2's, and a 4/690 and 4/330.
All are running SunOS 4.1.2
ntp.drift tick
========= ====
-89.83615 10000
-73.36331 10000
-72.51350 9998
-66.32201 10000
-64.02086 10000
-62.21976 10000
-55.62454 10000
-54.74640 10000
-50.99059 10000
-6.39066 10000
-4.19466 9998
-1.12428 9999
9.57497 9999
12.04364 10000
22.07689 9999
39.67384 9999
51.66208 9999
>From these numbers, it looks to me like 106ppm is well within the range of
speeds that Sun4 crystals actually run.
A while back somebody posted a suggestion of running xntpd for a few days,
then look at the drift file. If the absolute value is too big (>100?) then
kill the xntpd daemon. If the drift value is negative, you should reduce
'tick', if it is positive, then increase 'tick' ... add/subtract 100 to the
value in the drift file for every point that you change tick, then start a
new xntpd daemon.
Sounds like the FAQ should tell people to start at "-t 9999" on pre-4.1.3
systems ... but be prepared to tune a point or two on all Suns.
============================================================================
Subject: none (auto-inserted) [-/+]
From: mrapple@quack.kfu.com (Nick Sayer) [-/+]
Date: 10 Jun 93 10:56:31 GMT [-/+]
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
X-Keywords: adjustment [-/+] bug [-/+] dosynctodr [-/+]
gdonl@sunrise.ssi1.com (Don Lewis) writes:
>In article <1ut0gk$sli@spdev.east.sun.com> cjj@spdev.east.sun.com (Christopher Jackson - Special Projects) writes:
>>This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which
>>the -t 9999 adjustment should no longer be necessary. (Yes, you
>>do still need to disable dosynctodr.)
>I'm not so sure it is fixed. Our two Sparc 2's are running 4.1.2,
>and with the -t 9999 adjustment, they are off by 19ppm and 34ppm.
>Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm.
>This is a small sample, but the 106ppm error is more than I would
>have expected.
I think the bug was sun4c specific, but the fix was applied to all
Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3
need to have tick incremented by one. sigh.
The best thing to do is do it on an individual basis. If your clock
is off by more than 50 ms, increment/decrement tick until it isn't.
============================================================================
Subject: none (auto-inserted) [-/+]
From: cjj@spdev.east.sun.com (Christopher Jackson - Special Projects) [-/+]
Date: 13 Jun 93 15:26:00 GMT [-/+]
Organization: Sun Microsystems, Columbia MD
X-Keywords: bug [-/+] release [-/+]
In article <f4oiA#N@quack.kfu.com> mrapple@quack.kfu.com (Nick Sayer) writes:
>I think the bug was sun4c specific, but the fix was applied to all
>Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3
>need to have tick incremented by one. sigh.
Well, it turns out that Mr. Sayer is correct; the bug is not completely fixed
for sun4m machines.
The clock initialization for sun4, sun4c, and sun4m platforms was broken in
4.1.2. A fix was made to all three platforms for 4.1.3. Unfortunately, the
sun4m clock is a little different from the sun4/sun4c clock, and the fix needs
to be a little different as well. The result is that in 4.1.2, sun4 and sun4c
were 100ppm fast, while sun4m was 50ppm fast; in 4.1.3, sun4 and sun4c are no
longer broken, but sun4m is 50ppm slow. (Since it's 50ppm, not 100ppm, you
can't really fix this with the -t flag.)
A bug has just been filed on this, and it will hopefully be fixed in a future
release of SunOS. In the meantime, the exceptionally brave may wish to try
the following patch.
Notes:
This patch is for sun4m machines running 4.1.3 only; sun4s and sun4cs
don't need it, and applying it to earlier 4.X releases will probably
result in a crash.
THIS IS NOT AN OFFICAL SUN PATCH; if it trashes your system, melts
your disks, or turns your hair green, don't complain to me or to the
Answer Center. Caveat Emptor.
The patch:
cp /vmunix /vmunix.bak
adb -w /vmunix
startrtclock+2c?W 110007a0
startrtclock+34?W 90122480
startrtclock+3c?W 912a2009
startrtclock+40?W 1000000
startrtclock+44?W 1000000
$w
$q
reboot
If anyone actually tries this, I would be interested to hear how much it helps.
Chris Jackson <cjj@sun.com>
============================================================================
From: amoss@picton.cs.huji.ac.il (Amos Shapira) [-/+]
Subject: Re: help with ntp
Date: 26 Jun 93 16:04:34 GMT [-/+]
Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel
X-Keywords: DES [-/+] release [-/+]
jm@TAO.UNIV-PARIS8.FR (Jean Mehat) writes:
I would like which version of ntp, xntp etc... is the most current one?
We are running a small network of sun4 on the internet (< 10 machines).
I have been said that time synchronisation is an important issue in
security. I am somewhat lost between various releases of Network Time
Protocol. Can you give me a pointer to the most recent release (like a
ftp site & directory) ?
--
Jean Mehat, universite de Paris 8 Vincennes a Saint Denis,
jm@tao.univ-paris8.fr, (1) 49 40 64 03, (1) 49 40 67 83 (fax)
As far as I followed it, the most recent *released* version is 3.1, the
"home site" of xntp is louie.udel.edu directory /pub/ntp.
You will find there also some alpha releases of a newer version.
The drawback of this site is that it is located inside the U.S. and therefore
you can't take advantage of the DES code it can use (you still can have the
MD5 code). A release with DES which is located outside the U.S. is available
on ftp.csc.liv.ac.uk file /hpux/Networking/xntp-3.1.tar.Z. This is the one
I'm running a few months by now and it seems to work greate.
Cheers,
--Amos
============================================================================
From: mrapple@quack.kfu.com (Nick Sayer) [-/+]
Subject: Re: NTP for Mac?
Date: 6 Jun 93 16:40:17 GMT [-/+]
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
mrapple@quack.kfu.com (Nick Sayer) writes:
>I remember hearing some time ago about an NTP control panel or INIT
>for Macs. Is this true? What's it called and where can I ftp it?
>Thanks in advance.
Thanks to Randy Bush who not only pointed me towards, but mailed
me a copy of "Network Time", a control panel that does exactly
that.
============================================================================
From: Mills@UDEL.EDU [-/+]
Subject: Re: Leap second?
Date: 30 Jun 93 20:00:25 GMT [-/+]
X-Keywords: CHU [-/+] update [-/+] WWVB [-/+]
The fuzzballs are now so overloaded that I can't reach in and set the
leap bits manually. Between the smoke and steam of the xntp-alpha
stuff, new radio drivers and busted radios, not to mention new kernels
with leap stuff built in, I decided my bandwidth for this particular
leap event had been exceeded. Most of the radio services you mention
already have leap-warning bits and at least some of the clocks (CHU and
WWVB) do decode them in xntp-alpha. The problem here is that I haven't
completed the xntp-kernel interface for the kernels I have modified to
handle the leap event correctly. Standard kernels will of course not
bump the time until at least one update has been seen from the source.
Dave
============================================================================
From: warb@tgf.tc.faa.gov (Dan Warburton)
Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715 [-/+]
Date: 7 Jul 93 16:28:08 GMT [-/+]
Organization: FAA Technical Center, Pomona, NJ
X-Keywords: adjtimed [-/+] FAQ [-/+] firewall HP-UX [-/+] TCP
warb@tgf.tc.faa.gov (Dan Warburton) writes:
>ringi@x.co.uk (Ian Ringrose) writes:
>>I having problems getting "ntpdate" to work on a HP-UX 9 system, I have not
>>set up any config files, but have started "adjtimed".
>>When I do:
>> # ./ntpdate 128.175.7.4
>>I get:
>> ./ntpdate: no server suitable for synchronization found
>>When I do:
>> # ./ntpdate -d 128.175.7.4
>Yes, it seems that is might work. I have the same problem. I have
>just tested with my Internet firewall down and things seem to work.
>There must be a back socket that needs access.
>Is there any one out there that Knows what port and protocal TCP or UPD
>this back channel might be? I'll check the sources, but would like
>confirmation of my guess.
OK, here's my answer: ntp uses a udp back port of 123 on my Internet fire
wall (a cisco router) my access list needed the following:
!ntp network time protocal
access-list 101 permit udp 0.0.0.0 255.255.255.255 155.178.0.0 0.0.255.255 eq 123
This allows udp access to port 123 from anywhere on the internet to any host
on my Class B address space.
P.S. Maybe this should go into the FAQ?
--
Dan Warburton warb@faa.gov warb@tgf.tc.faa.gov warb@pilot.njin.net
============================================================================
From: dunigan@thdsun.epm.ornl.gov (Tom Dunigan)
Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715 [-/+]
Date: 7 Jul 93 20:44:37 GMT [-/+]
Organization: Oak Ridge National Laboratory
X-Keywords: UDP
In debug mode, ntpdate uses a non-privileged port number for its "source
UDP port" to do the query. When not in debug mode, ntpdate uses port 123
as its source port. Some systems (Ultrix), or maybe its the xnptd version,
refuse to reply to the 123-port request.
--
Tom Dunigan
dunigan@msr.epm.ornl.gov
============================================================================
From: feigin@iis.ee.ethz.ch (Adam W. Feigin)
Subject: Re: syslog() bogosity
Date: 29 Jul 93 13:32:36 GMT [-/+]
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
X-Keywords: syslog [-/+]
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
>emcguire@intellection.com (Ed McGuire) writes:
>>The virtually identical syslog code found in each
>>of these processes should be consolidated, but before I do that, has
>>it been cleaned up already in the alpha?
>Why not in the main ntp*.h include file do a:
> #ifdef LOG_DAEMON
> #undef LOG_DAEMON
> #endif
> #define LOG_DAEMON LOG_LOCAL0
>Or maybe put this in Config...
Ugh. Its in there already as of xntp-alpha. All you need to do is to
change the DEFS line in your config file, and add the following:
-DLOG_NTP=LOG_(insert your favorite syslog facility here)
Its not really documented in the Config file anywhere, and I can't
remember where I came across it, but it does work. I just checked, and
it looks like I gleaned this from the code in xntpd/ntp_control.c
(line 1724) and xntpd/ntpd.c (line 190).
/AWF
============================================================================
From: ntp-adm@inria.fr
Subject: NTP FAQ: update for Sony
Date: Thu, 05 Aug 1993 10:31:25 +0200 [-/+]
Sender: Alain.Durand@inria.fr
X-Keywords: DST [-/+] FAQ [-/+] Mills [-/+] TAI [-/+] timezone [-/+]
A little while ago I posted a request for help to run xntdp on Sony News.
Everybody agreed the answer was worth an entry in the FAQ.
This is a summary of the answers I got:
The problem is that Sony boxes do not take care of leap seconds correctly.
xntpd seems to synchronize well, but the date program pretends the clock
is 14 seconds off.
The solution is to remove the MET file in /etc/zoneinfo with all its links
and to replace it with a good one (sun's for example) and then to
restart inetd.
If you are in another time zone, you might have to change some other files.
Thanks to:
Heiko Trautwein <trautwyn@fb3-s7.math.tu-berlin.de>:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> hello,
> on our SONY Workstations ( mips and mc68030 ) we had this problem too,
> the clock differs 14 or 15 seconds from all the other clocks, if
> timezone is MET, if you change the timezone to e.g. GMT the clocks
> are in time.
> So I think the GMT timezone is corrupt and copied the MET file from
> one of our Sun's on the Sony, and clocks where synched.
>
> Heiko
jcs@zoo.bt.co.uk (John C Sager) & aegl@ossi.com (Tony Luck)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In article <230vca$h66@nym.ossi.com>, aegl@ossi.com (Tony Luck) writes:
> > durand@nuri.inria.fr (durand alain denis) writes:
> >
> > >I'm trying to install xntp-alpha on various machine on our network.
> > >It's just fine for sun's, but for sony mips, it's really wierd.
> >
> > I think that this was discussed a couple of months ago ... as far as I recall
> > the problem is that the Sony systems have a table of the leap seconds so that
> > that can try to be really clever about telling you the time. As a result,
> > they have a different idea of how many seconds there have been since 1970.
> > This confuses xntp somehow (maybe its date conversion code doesn't match the
> > libc ctime() stuff?) ... and the net result is that xntp sets the time to
> > a value that ctime() says is some number of seconds out (depending on how
> > many leap seconds ctime() is trying to account for).
>
> NTP ticks UTC, as do most Unix boxes, so at each leap second, it, and the
> Unix clock, get stepped appropriately. This is explained at length by Dave
> Mills in rfc1305 pages 76-79.
> There was some discussion on this group some time ago as to whether NTP
> should tick TAI, and the corrections done for leap seconds in the same
> manner as timezone & DST corrections are currently done (as the Sony
> box seems to do). At the time I argued that the current system is more
> convenient for most users, and the small number who need TAI can do the
> reverse correction at their own expense.
>
> >
> > Can't recall whether anyone had a fix for this though ... if anyone does, its
> > probably worth an entry in the FAQ.
>
> I would agree an entry in the FAQ migh prevent future puzzlement.
- Alain Durand.
============================================================================
From: barrett@lucy.ee.und.ac.za (Alan Barrett)
Subject: Re: NTP for Novell????????
Date: 10 Aug 93 00:44:36 GMT [-/+]
Organization: Elec. Eng., Univ. Natal, Durban, S. Africa
X-Keywords: FAQ [-/+] implementation [-/+] Novell [-/+] RFC
MVICKERS@fhcrc.org (Mark F. Vickers) writes:
> Is there an NTP client for Novell???
This question should be in the FAQ, but is not there. I usually email
replies to this question, but will post this time.
I don't know of an NTP implementation for Novell, but I do know of two
ways of synchronising the times of Novell servers using the RFC 868
time protocol (commonly called "rdate").
* There is an RDATE NLM from Murkworks that allows the Novell fileserver
to synchronise its time from an rdate server. Available from
ftp://netlab2.usu.edu/misc/rdate.zip
* Brad Clements' Charon mail/lpr gateway can synchronise its time
from an rdate server, and can set the times of the attached Novell
fileservers using some Novell method. Available from
ftp://omnigate.clarkson.edu/pub/cutcp/charon
--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za
============================================================================
From: aegl@ossi.com (Tony Luck) [-/+]
Subject: Re: Problems with xntpdc and ntpq in xntp(3.1) [-/+]
Date: 12 Aug 93 17:19:07 GMT [-/+]
Organization: Fujitsu Open Systems Solutions, Inc.
cmoore@corazon.mit.edu (Christopher B. Moore) writes:
>well under control. But I'm having trouble running ntpq and xntpdc to
>get a look at what's going on. Both programs fail with the message:
>ntp/udp: unknown service. Can someone suggest what I might have done
>wrong?
I think that "ntp" is one of the well known services that Sun forgot to
put in /etc/services. Just add the line:
ntp 123/udp # Network Time Protocol
to /etc/services (For some bizarre reason this file is controlled by
NIS (formerly yellow pages), so if you are in the unfortunate situation
of using NIS you need to add this line to /etc/services on your server
and run ypmake/yppush/whatever).
-Tony Luck <aegl@ossi.com>
============================================================================
From: schoo@cs.rulimburg.nl (Patrick Schoo)
Subject: Re: Problems with xntpdc and ntpq in xntp(3.1) [-/+]
Date: 16 Aug 93 10:08:16 GMT [-/+]
Organization: University of Limburg, Maastricht
X-Keywords: bug [-/+]
aegl@ossi.com (Tony Luck) writes:
>I think that "ntp" is one of the well known services that Sun forgot to
>put in /etc/services. Just add the line:
>ntp 123/udp # Network Time Protocol
>to /etc/services (For some bizarre reason this file is controlled by
>..
>-Tony Luck <aegl@ossi.com>
Sun didn't forget to put ntp in /etc/services, they just use the wrong
protocol (tcp instead of udp). In my original services file this line
was included (SunOS 4.1.1).
ntp 123/tcp # Network Time Protocol
Does anyone know if this is a bug, or if there is a specific reason for
this?
Patrick Schoo (schoo@cs.rulimburg.nl)
============================================================================
Subject: none (auto-inserted) [-/+]
From: geertj@ica.philips.nl (Geert Jan de Groot) [-/+]
Date: 13 Aug 93 20:48:26 GMT [-/+]
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands
X-Keywords: bug [-/+] Mills [-/+]
Mills@UDEL.EDU writes:
>The offset looks too high. Note the frequency slowly climing, which
>suggests the usual problem with SPARCs. Your /etc/rc.local file should look
>something like this:
>if [ -f /usr/local/bin/tickadj ]; then
> /usr/local/bin/tickadj -t 9999 -a 5 -s & echo -n ' tickadjusted'
>fi
>if [ -f /usr/local/bin/xntpd ]; then
> /usr/local/bin/xntpd & echo -n ' xntpd'
>fi
>This assumes SunOS 4.1.1. I am told, but have not confirmed, that 4.1.3
>has a bugfix which removes the necessity for the -t 9999 above. Then,
>I am told that Sun 5.x has a new bug which requires -t 10001. Your
>mileage may vary.
I found the offset to be CPU-specific. That means, when I needed
to have one CPU replaced, I had to re-find the right 'tick' value
for that specific board. It looks like the clocks are just
made with a larger tolerance than NTP can handle.
For each box running xntp, I build a file /etc/ntp.tick that contains
the tick value. I have values between 9997 and 10001, just to keep
the offset between +- 100 ppm on 4/280, 4/490, 4/690, 4/60, 4/65..
For a new CPU, I just set ntp.tick to 9999, let xntp run a day,
change ntp.tick if the offset is out of range, re-start xntp,
and retry. This usually stabilizes withing a few days.
If the offset is much too high (>250ppm), I found that xntp does
not obtain lock at all. These are all 4.1.3 machines.
Geert Jan
============================================================================
From: mose@ns.ccsn.edu (Russell Mosemann)
Subject: Re: NTP for VMS [-/+]
Date: 24 Aug 93 19:32:28 GMT [-/+]
Organization: Concordia College, Seward, NE
X-Keywords: VMS [-/+]
irv@ccstat.mc.duke.edu writes:
>I have been reading this group for a few months now and have never seen
>mention of a version of NTP for VAX/VMS. I also checked the archives at
>UDEL.EDU. Did I miss is or is there no version for VAX/VMS?
There is no version that I know of unless you use Multinet. I am
finishing a port of ntpdate to VMS. I need to smooth out the code in
a couple of places and document it, but for the most part it is done.
When it is complete, I will submit it to the archives. Watch this space
for further news.
If I get really exicted some day, I might try to port xntpd to VMS,
but that won't happen for at least a year.
--
Russell Mosemann Concordia College Voice: (402) 643-7445
Computing Center Seward, NE 68434 Fax: (402) 643-4073
============================================================================
From: iglesias@draco.acs.uci.edu (Mike Iglesias) [-/+]
Subject: Re: NTP for VMS [-/+]
Date: 24 Aug 93 23:02:37 GMT [-/+]
Organization: University of California, Irvine
X-Keywords: VMS [-/+]
Both Wollongong and Multinet support NTP for VMS. Wollongong is ntp v1,
and I believe that Multinet is also.
--
Mike Iglesias Internet: iglesias@draco.acs.uci.edu
University of California, Irvine BITNET: iglesias@uci
Office of Academic Computing uucp: ...!ucbvax!ucivax!iglesias
Distributed Computing Support phone: (714) 856-6926
============================================================================
From: Mills@UDEL.EDU [-/+]
Subject: Re: xntp problem
Date: 25 Aug 93 00:00:22 GMT [-/+]
X-Keywords: implementation [-/+]
Wesley,
The ntpdc works with NTP Version 1 implementations (ntpd) and not
Version 2 nor Version 3 implementations (xntp, xntp3, xntp-jones).
The equivalent program for the latter implementation is xntpdc included
in the xntp3, xntp-jones distributions. This program also works with
the Version 2 implemenation. Having said this, the program of choice
to fondle v2 and v3 implementations is ntpq in the xntp3, xntp-jones
distribution. This program conforms to the NTP Version 2/3 specifications
rfc-1119, rfc-1305, respectively and should work with other implementations
now coming online. The xntpdc program is very implentation dependent and
nto likely to work with any other implementation.
Dave
============================================================================
From: dkatz@CISCO.COM (Dave Katz)
Subject: churchy.udel.edu
Date: 6 Sep 93 20:32:42 GMT [-/+]
X-Keywords: monitoring peer [-/+]
I did a little monitoring of churchy (a cisco IGS) which is filling in
at a peer address that was idle for some months.
In 20 minutes, 650 NTP requests were received from 106 hosts.
Three sites had seven peers chiming with churchy.
A number of the peers are running version 1 NTP.
Looks like mucho cruft out there...
============================================================================
From: JDB6@psuvm.psu.edu
Subject: Novell server time module available
Date: 14 Sep 93 17:58:24 GMT [-/+]
Organization: Penn State University
X-Keywords: DTS implementation [-/+] Novell [-/+]
There is now a directory on FTP.OTC.PSU.EDU which contains
information and software for synchronizing time on Novell
Netware servers with a Network Loadable Module (NLM) that
uses the unix "rdate" protocol. This NLM will allow Netware
servers to synchronize their time to time servers (eg:
CLOCK.PSU.EDU) within one second of accuracy.
This is not an implementation of Network Time Protocol (NTP),
which could provide better accuracy. Novell has committed
to that effort through the Distributed Time Service (DTS)
portion of OSF's Distributed Computing Environment (DCE).
An announcement on that from Novell will probably not happen
before the first quarter of 1994. Delivery schedule is even
more uncertain at this point.
(Feel free to correct me if you know something more current. :-)
*I don't speak for Penn State, Novell, or anyone else... *
The following is an information file included in the directory:
--- enclosed file follows ---
Info on files in /pub/ntp/ms_dos/novell on ftp.otc.psu.edu.
rdatenlm.txt This file. ASCII text.
rdatenlm.zip PKZIPed (tm) RDATE.NLM and README.TXT. Binary file.
--- beginning of README.TXT (extracted from RDATENLM.ZIP) ---
This package contains an RDATE NLM for Novell Netware 386 (tm)
+-------------------------------------------------------------------+
|Permission is hereby granted for this archive to be distributed via|
|BBS, Compuserve, Anonymous FTP and any other means so long as no |
|fee is charged for distribution and all components of this archive |
|remain together. |
+-------------------------------------------------------------------+
The RDATE NLM is Copyright (c) 1992 MurkWorks, All Rights Reserved.
RDATE.NLM - 10/12/92
** This is free software **
MurkWorks has provided this NLM to the Novell user community at no charge.
Purpose:
The RDATE NLM allows the supervisor to synchronize the time
of a Novell NW386 file server with the time of a nearby
Unix host (or any other host which supports the time protocol).
[...]
[eof]
============================================================================
From: jcs@zoo.bt.co.uk (John C Sager) [-/+]
Subject: Re: any reason for ntp/tcp service?
Date: 21 Sep 93 09:19:07 GMT [-/+]
Organization: BT Laboratories, Martlesham, Ipswich, UK
In article <27l3svINNb67@srvr1.engin.umich.edu>, darrin@engin.umich.edu (Darrin P Cardani) writes:
> Several of our /etc/services files listed ntp as a tcp service only, or
> as a udp and tcp service. The ones that listed it as tcp only, didn't work,
> so I fixed them by changing it to udp. Is there any reason to include tcp
> service, though? I have seen it on 2 platforms so far.
SunOS 4 /etc/services files are/were all like this, probably due to a misunderstanding at Sun. Dunno about other manufacturers. As you say,
a change to udp will fix it.
John C Sager Mail: B67 G18, BT Labs
Email: jcs@zoo.bt.co.uk Martlesham Heath
Tel: +44 473 642623 IPSWICH IP5 7RE
Fax: +44 473 637614 England
Disclaimer: This is me, not BT.
============================================================================
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: Puzzled about leap seconds
Date: 22 Sep 93 02:29:03 GMT [-/+]
Organization: Twin Sun Inc, El Segundo, CA, USA
X-Keywords: synchronized [-/+] TAI [-/+] timezone [-/+]
t.d.g.sandford@bradford.ac.uk (Thomas Sandford) writes:
I think it means that ntp maintains the clock as though leap
seconds do not exist.
I'm not quite sure what you mean, but if you mean that NTP forgets
past leap seconds, you're correct.
Therefore on a system running ntp your timezone file must *not*
contain any leap second entries.
That depends on what you mean by ``your timezone file''. If you're
maintaining an astronomical application synchronized with NTP, there's
a good chance you will need a leap second database (if NTP suffices at
all). But if you're merely maintaining a Unix (or, more precisely, a
Posix.1) host, then you probably don't need leap second entries, since
Posix.1 pretends that leap seconds don't exist and this maps
conveniently into NTP's fire-and-forget leap second handling.
Also could you enlighten my ignorance. What exactly is TAI?
The quick answer is that TAI is Temps Atomique International, i.e.
International Atomic Time. UTC = TAI + (integral leap second corrections).
The exact answer is a bit much to cover in a Usenet article, but here's
my best shot. TAI is established on the basis of clock comparison data
supplied to the Bureau International des Poids et Mesures by
timekeeping labs around the world. It is a coordinate time scale
defined in a geocentric reference frame with the SI second as realized
on the rotating geoid as the scale unit, i.e. it is not a proper time
scale if you take relativity into account. To find out exactly what
TAI is, see B. Guinot and C. Thomas, ``The establishment of
International Atomic Time'', BIPM Annual Report of Time Section 1, part
D (1989). More accessible reports appear in Metrologia 24, 195-198
(1987), Metrologia 28, 57-63 (1991), and Proc IEEE 79, 894-905 (1991).
============================================================================
From: beland@ireq.hydro.qc.ca (Jean Beland)
Subject: Re: NTP-client for MAC [-/+]
Date: 24 Sep 93 14:38:48 GMT [-/+]
Organization: Hydro-Quebec
Another NTP client for Macintosh is "Network Time 2.0", from Peter
Resnick. Available by anonymous FTP at sumex (shareware).
--
Jean Beland | Institut de Recherche d'Hydro-Quebec
Chercheur / Research Worker | 1800 Montee Ste-Julie,
tel: (514) 652-8076 | Varennes, Quebec, CANADA. J3X 1S1
fax: (514) 652-8424 | Internet: <beland@ireq.hydro.qc.ca>
============================================================================
From: mingo@panix.com (Charlie Mingo)
Subject: Re: NTP-client for MAC [-/+]
Date: 26 Sep 93 04:56:50 GMT [-/+]
X-Keywords: FAQ [-/+]
In article <Sep.21.14.29.17.1993.11392@frogpond.rutgers.edu>,
Rick Thomas <rbthomas@frogpond.rutgers.edu> wrote:
>
>Seriously, could somebody put it up for anonymous FTP? If I had a place
>to point to, I'd put a notice of it in the FAQ.
I posted a copy to mac.archive.umich.edu. It should appear in a few days.
============================================================================