HDTenEightyP/NetNews huggingface dataset:
From: meekj@pt.Cyanamid.COM (Jon Meek)
Newsgroups: comp.protocols.time.ntp
Subject: Re:  PC-bus time cards -- Loran C
Date: 30 Dec 92 01:30:31 GMT
Reply-To: meekj@pt.Cyanamid.COM
Organization: American Cyanamid Company

About six years ago Sitex supplied us with a low-cost marine Loran
receiver which had a BNC connector that provided pulses at the "group
repetition interval". I used the GRI signal in a system to monitor
oscillator drift in some of our equipment for precision frequency
measurement. I think that Scitex charged just the list price (~600. at
the time) for this. With this starting point, one only needs digital,
rather than RF, talent.

Jon Meek
Newsgroups: comp.protocols.time.ntp
From: heather@wuee1.wustl.edu (Heather A. Drury)
Subject: xntp on sgi's
Organization: Washington University, St. Louis Mo.
Distribution: na
Date: Wed, 30 Dec 1992 00:18:10 GMT


I am new to the ntp world, so bear with me...

I am trying to get xntp to run on an SGI Indigo.  The daemon xntpd 
exits right away, apparantly because "tickadj" and "tick" are not 
used in the kernel.  Is there any way around this or am I out of luck?

Also, does anyone know if I can succesfully synchronize two Indigo 
clocks running at 1200Hz to within 5 (or less) milliseconds, or am
I dreaming?

Any input would be greatly appreciated.

**************************************************************************
* Heather Drury                           Internet: heather@v1.wustl.edu *
* Research Scientist                      Phone: 314-362-4325            *
* Department of Anatomy & Neurobiology    FAX: 314-362-3446              *
* Washington University, St. Louis, MO                                   *
**************************************************************************
Newsgroups: comp.protocols.time.ntp
From: rhill@dale.ksc.nasa.gov (Russ Hill)
Subject: Wanted: xntpd for CX_UX 6.1
Organization: NASA
Distribution: usa
Date: Mon, 21 Dec 1992 14:13:18 GMT


looking for anyone who has ported xntpd to CX_UX 6.1 harris nighthawk.
thanks


-- 

Russ Hill
rhill@dale.ksc.nasa.gov
(407) 633-3950
From: tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
Newsgroups: comp.protocols.time.ntp
Subject: Wireless time services -- standards?
Date: 2 Jan 93 14:53:18 GMT
Organization: Norwegian School of Economics

This is not really related to NTP as such, but since there is no other
group where postings regarding time services fit, as far as I can
tell...

There were a few television programs broadcast during the Christmas
holidays that I wanted to see.  Since I prefer to watch TV at my own
convenience, I programmed my VCR to record them for me, so that I
could watch them when I pleased.  However, we had a couple of power
outages, and each time I had to set my VCR clock manually, and
reprogram the darn thing to record those programs.  Stupid!

Of course, one could argue that the VCR ought to have a battery backup
for its clock, but I've got one of the cheaper models, and of course
this is a feature that they reserve for people who can shell out
bigger bucks for the thing than I can.

However, I got to thinking about this: Why the heck doesn't my VCR
automatically find out what the current time is?  Why doesn't my clock
radio and other appliances that have clocks do the same thing?  It
seems to me that something essential is missing here...  There are
radio stations and TV stations all over the place, transmitting a lot
of stuff on different channels at the same time, so why don't we
already have a standard for time information transmittal that these
appliances can utilize?

And even without a general time broadcast system, the following could
be done: Since a VCR has a TV receiver, there ought to be info
contained within the normal TV broadcast signal telling the current
time (probably specified as UTC, with the local time zone switch
settable on the VCR), so that the VCR can keep its internal clock
running correctly.

Does anyone know anything about standardization work for such
services?  I can hardly believe that it's not being worked on...?

-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
Postmaster for domain nhh.no.   Internet mail: tih@barsoom.nhh.no
From: scotth@oniboshi.corp.sgi.com (Scott Henry)
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntp on sgi's
Date: 30 Dec 92 01:48:29 GMT
Distribution: na
Organization: Silicon Graphics Inc, Mountain View, CA


>>>>> In article <1992Dec30.001810.21990@wuecl.wustl.edu>, heather@wuee1.wustl.edu (Heather A. Drury) writes:


heather> I am trying to get xntp to run on an SGI Indigo.  The daemon xntpd 
heather> exits right away, apparantly because "tickadj" and "tick" are not 
heather> used in the kernel.  Is there any way around this or am I out of luck?

Some time ago, I ported xntp (NTP V2) to the SGI platform. Patches are
available for anonymous FTP on sgigate.sgi.com, in the directory
~ftp/net-services/xntp. In addition is a compressed tar file
containing a set of binaries built with those patches. Since I'm an
SGI employee, I gotta give the full disclaimer (copied out of the
README file in that directory):

THIS CODE IS COMPLETELY UNSUPPORTED.

This software is provided without support and without any obligation on the
part of Silicon Graphics, Inc. to assist in its use, correction, modification 
or enhancement.  There is no guarantee that this software will be included 
in future software releases, and it probably will not be included.

THIS SOFTWARE IS PROVIDED "AS IS" WITH NO WARRANTIES OF ANY KIND INCLUDING THE
WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.

Disclaimer disclaimer: I will, as my time permits, help you if you
have problems compiling or installing this software. I am also
interested in bug reports that apply to the SGI port. Please address
bugs/problems/questions to "scotth@sgi.com".


heather> Also, does anyone know if I can succesfully synchronize two Indigo 
heather> clocks running at 1200Hz to within 5 (or less) milliseconds, or am
heather> I dreaming?

We use a mix of xntpd and timed internal to SGI, and offsets are
mostly less than 30 msec. Most of these are not managed to minimize
offset (and in fact most are using timed off of an xntpd time master).
Especially with fast clocks on (and precision adjusted accordingly),
with careful tuning you could probably keep mostly 1-2 msec offsets
within a small group of hosts. Remember that default clock precision
is 10msec, the dispersions seen on the local net (I'm just checking as
I type) are on the order of one clock tick, or they are way off (hmm,
lots of hosts to check for missing time daemons....).

Good luck on your project!

=-=-=-=-=
Newsgroups: comp.protocols.time.ntp
From: mrapple@quack.sac.ca.us (Nick Sayer)
Subject: Re: more info requested on dosynctodr
Keywords: xntp3, dosynctodr
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 3 Jan 1993 22:04:09 UTC

rstevens@noao.edu (W. Richard Stevens) writes:

>> Just wondering if anyone can give any additional information on
>> just what the "dosynctodr" kernel flag does in SunOS, and why
>> it should be set to 0.

>OK, I can answer some of my own question after finding the code in
>ntp_util.c that handles this case.  BUT, the code says that setting
>synctodr to 0 is not what you want (as a reboot will start off with
>a wacky time),

No, that's not really what I meant.

Setting dosynctodr to 0 is what you want to do. The wackiness after
reboot is a consequence of setting dosynctodr to 0, but it is far
more desirable to do it than not.

>but the tickadj(8) man pages says you should set it
>to 0 for SunOS 4.0.  Also, the distributed Config.sun file does not
>set DOSYNCTODR_SUCKS, which goes against the source code comments.

I disagree slightly with the comment in the Config file about
DOSYNCTODR_SUCKS. I recommend doing it on all Suns. I have heard
arguments that it causes a 800 us jitter when it happens. This
too is true, but I know of no other documented way to set the battery
clock than to call settimeofday() (though I have heard that
doresettodr is a possibility, I haven't been able to confirm that
it works as advertised).

>I'm confused as to how I should set it, both in the Config file and
>using tickadj.

Use both tickadj and DOSYNCTODR_SUCKS.

>Lastly, the man page doesn't say so, but I assume that Sun's settimeofday(2)
>system call is what syncs the battery clock to its argument?

Yes. That's the whole point behind DOSYNCTODR_SUCKS.

-- 
Nick Sayer <mrapple@quack.sac.ca.us> | "You see it. You hear it.
N6QQQ @ N0ARY.#NOCAL.CA.USA.NOAM     |  You want to turn away.
+1 408 249 9630, log in as 'guest'   |  BUT YOU CAN'T!!!"
PGP 2.1 public key on request        | 	 -- Ren & Stimpy add
From: ellozy@FARBER.HARVARD.EDU (Mohamed Ellozy)
Newsgroups: comp.protocols.time.ntp
Subject: nbstime
Date: 23 Dec 92 01:14:38 GMT
Distribution: inet
Organization: The Internet

Dave and other chimers,

I remembered long ago there was a program (in source form) to get time
from the NBS on louie, and looking around sure enough I found a source
directory called nbstime.  A problem: all source files include
nbstime.h which, alas, is nowhere to be found.

I want to compile nbstime on my home PC (with suitable phone number)
and, looking at the code, see what it expects of the machine it will
be dialing in.  It should then be easy to get time at home from my
true-chiming work computers.

But first I need nbstime.h.  Any idea where that beast might reside?
Any additional hints would be much appreciated.

Thanks.

Mohamed
From: rouilj@dl5000.bc.edu (John P. Rouillard)
Newsgroups: comp.protocols.time.ntp
Subject: Strata 2 timeserver timeserver.cs.umb.edu warning
Date: 30 Dec 92 16:12:03 GMT
Article-I.D.: dl5000.ROUILJ.92Dec30111203
Organization: Institute for Space Research, Boston College


U-Mass Boston has changed from a class C to a class B address.
timeserver.cs.umb.edu is no longer at 192.12.26.23. It's new address
is 158.121.104.23. 

Please make note of this change, and change your NTP configuration
files accordingly. If you are using the DNS to get the address for
timeserver.cs.umb.edu then you should not be affected.

A notification was sent out to all known users of that NTP server
about a week ago. If you should have received a notice, and did not,
please send me email. This will be important since we are planning on
changing timeserver.cs.umb.edu over to a DECstation running a version
3 NTP server at the end of January, and the IP numbers will change
again. 

We were hoping to make both changes at the same time, but sadly the
clock ran out on us 8-).

Thanks.

-- John
Newsgroups: comp.protocols.time.ntp
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Re: xntpd and timed, etc
Organization: /usr/local/lib/news/organization
Distribution: na
Date: Wed, 23 Dec 1992 01:59:24 GMT

atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>  NTP version 1 is really old.  They should upgrade from using ntpd(8)
>to using xntpd(8) using the freely distributable sources available via
>anonymous ftp from /pub/ntp on louie.udel.edu (the official xntp3
>archive site).

Its hard for people who need the code to work as advertised to do
this. I'm one of those poor schlubs out there who actually needs to
use a particular machine's internal clock as a master because we don't
have a radio clock or a suitable direct internet connection --
instead, I sync certain machines every few hours to NIST by phone.
This isn't perfect, but getting my machines synced to each other is
more important than getting them to within milliseconds of real time;
a fiftieth of a second off the world (what I get in practice) is fine.
Unfortunately, xntp3 has a bug that prevents the local clock as time
source option from working, and no one out there seems to have a fix.
Thus, I can't use xntp3, in spite of the fact that I'd like to.

--
Perry Metzger		pmetzger@shearson.com
--
Laissez faire, laissez passer. Le monde va de lui meme.
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: xntpd/clock.txt
Date: 31 Dec 92 06:25:11 GMT
Distribution: inet
Organization: The Internet

Folks,

An updated version of the NTP public servers file clock.txt has been
stashed in the pub/ntp/doc directory on louie.udel.edu. Only minor
changes.

An updated version of the NTP Version 3 daemon for Unix xntp3.tar.Z
has been injected in the pub/ntp directory on that same fossil.

The latest xntp3 includes fixes from the patch gang to the local-clock
feature of xntp3. Those of you without radios or Internet connectivity
may find nominal joy of that patch.

Dave
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: xntpd and timed
Newsgroups: comp.protocols.time.ntp
Organization: University of California, Irvine
Keywords: xntpd, timed
Date: 22 Dec 92 06:18:12 GMT

In article <1992Dec17.145434.199386@ipgaix.unipg.it> peppe@ipgaix.unipg.it (G. Vitillaro) writes:
>We are currently using <timed> on our (still little,
>but growing) network. We are planning to start to use 
>xntpd.
>
>May I suppose that I have to stop timed on all the machines
>where I'm going to start xntpd? May they coexist in some way?

The following was posted a few months ago; it should help you thru your
transition.


Mike


Article 2005 of comp.protocols.time.ntp:
Newsgroups: comp.protocols.time.ntp
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Subject: Re: Wanted  timed for SUN
Organization: Univ. Natal, Durban, S. Africa
Date: Sat, 22 Aug 1992 12:05:09 GMT

In article <VD95JFV@mailgzrz.tu-berlin.de>,
gentz@zrz.tu-berlin.de writes:
> So I want to run both (xntpd and timed-master) on my SUN.

You need your ntp server to run a master timed which knows that the local
clock is correct (due to the NTP synchronisation) and that refuses to
believe any of the slave timed's.  Ask archie about ntp-timed.patch,
or grab hippo.ru.ac.za:/pub/network/timed+ntp.tar.Z, which is a timed
that has the patch already applied.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett


Newsgroups: comp.protocols.time.ntp,comp.unix.aix
From: Christopher.Vance@adfa.oz.au (Christopher JS Vance)
Subject: Re: xntpd and timed
Originator: cjsv@ccadfa.cc.adfa.oz.au
Organization: Computer Science, University College, UNSW/ADFA, Canberra, Australia
Date: Mon, 21 Dec 1992 22:41:31 GMT

In article <1992Dec18.175438.16954@Arco.COM> Matt Mannhardt <lasmtm@Arco.COM> writes:
| >We are currently using <timed> on our (still little,
| >but growing) network. We are planning to start to use 
| >xntpd.
| >
| >May I suppose that I have to stop timed on all the machines
| >where I'm going to start xntpd? May they coexist in some way?
| 
| I have been looking into this question myself because of being in a
| sum-what
| similar position and I am interested in other peoples experiences.  We
| have a 

[ etc. ]

| The end result is that I'll probably run a mix of 'timed' and 'xntp' with
| new installs
| going to 'xntp' (by adding the appropiate code to our "localization
| scripts" that we
| run for new installs) and leaving the current 'timed' clients as they are
| till their
| next OS upgrade.
| 
| Comments anyone?

We use both ntpd (v1) and timed on a mixed network (Sun, Pyramid,
Convex, Apollo, DEC).  Pyramid and Apollo ship timed, Sun ships
nothing, I'm not sure what we did to the DEC.  We compiled and run
ntpd on a small number of Suns, each with some contact off-campus and
communicating with each other on-campus.  Each ntpd machine is also a
potential timed master (started with -M option).  But we compiled for
these machines a version of timed that does not alter the master's
clock.  So on these machines, ntp makes the decisions.  The other
machines, which don't run ntpd, all run timed in slave mode.  It seems
to work well.  Part of the reason for doing this was that ntpd
required a configuration file on each host; I should check out a newer
version of xntp which apparently does not require this.

-- Christopher
From: philipp@res.enst.fr (Philippe-Andre Prindeville)
Newsgroups: comp.protocols.time.ntp
Subject: PC-bus time cards
Date: 28 Dec 92 20:41:51 GMT
Distribution: inet
Organization: Ecole Nationale Superieure des Telecommunications, Paris

Does anyone know of an ISA or EISA bus card for receiving either GPS
or Long Wave time signals?  We are looking at the TrueTime PC-GPS
card, but it's a bit expensive.  Have any ideas on a cheaper version?

I need something that will give me microsecond accurate time, but
don't have a lot to spend.  RS-232 interface-based cards are probably
out of the question, since reading from them is slow...

Please respond to me directly.

Thanks,

-Philip
From: makey@VisiCom.COM (Jeff Makey)
Newsgroups: comp.protocols.time.ntp
Subject: Leap second?
Date: 29 Dec 92 21:01:44 GMT
Organization: VisiCom Laboratories, Inc., San Diego, California

Will there be a leap second at the end of this year (i.e., about 51
hours from now)?  Thanks in advance.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Domain: makey@VisiCom.COM    UUCP: nosc!visicom!makey
Newsgroups: comp.protocols.time.ntp
From: ado@elsie.nci.nih.gov (Arthur David Olson)
Subject: Wanted: scoop on an old TV script
Organization: National Institutes of Health
Date: Mon, 21 Dec 1992 14:11:41 GMT

If you know who has the script for the 1950's TV episode of "Superman"
hinging on time standards, I'd appreciate hearing from you by electronic
mail.  (Executive summary:   Supe gets NBS broadcast jiggered to foil a
statute-of-limitations waitout.)
-- 
		Arthur David Olson	ado@elsie.nci.nih.gov
		ADO and Elsie are Ampex and Borden trademarks
Organization: Penn State University
Date: Wed, 23 Dec 1992 09:12:29 EST
From: <JDB6@psuvm.psu.edu>
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp or xntp for VAX/VMS?
Distribution: na

Check out MultiNet from TGV.
It has an NTP process that you can easily start (even I can do it).

John Balogh, Penn State, For a good time: telnet clock.psu.edu 13
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  PC-bus time cards
Date: 29 Dec 92 18:17:13 GMT
Distribution: inet
Organization: The Internet

Philip,

Try Bancomm Division of Datum, Inc. Their address is in the clock.txt file in
the usual place. They were alleged to be working on such a beast, but I'm
sure it will not be cheap.

Austron makes LORAN-C timing receivers, but they cost $20K up. Cheapest thing
known to me for submillisecond time is the Motorola MX4200, for which there
is even an xntp3 driver. There are conflicting reports on its price, which
I thought was in the $3K range. This is a GPS receiver.

The most stable time I know, and this includes GPS, comes from a LORAN-C
timing receiver, at least as long as the GPS wiggle machine is running, which
is probably forever. I have built a couple of these things, which amount
to a plug-in PC card and fancy control program. While the latest version is
not real hard to duplicate and I do have etched PC boards, I don't recommend
it unless there is some local talent for radio construction and alignment.

Dave
Newsgroups: comp.protocols.time.ntp
From: rstevens@noao.edu (W. Richard Stevens)
Subject: Re: more info requested on dosynctodr
Keywords: xntp3, dosynctodr
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Sun, 3 Jan 1993 18:05:46 GMT

> Just wondering if anyone can give any additional information on
> just what the "dosynctodr" kernel flag does in SunOS, and why
> it should be set to 0.

OK, I can answer some of my own question after finding the code in
ntp_util.c that handles this case.  BUT, the code says that setting
synctodr to 0 is not what you want (as a reboot will start off with
a wacky time), but the tickadj(8) man pages says you should set it
to 0 for SunOS 4.0.  Also, the distributed Config.sun file does not
set DOSYNCTODR_SUCKS, which goes against the source code comments.
I'm confused as to how I should set it, both in the Config file and
using tickadj.

Lastly, the man page doesn't say so, but I assume that Sun's settimeofday(2)
system call is what syncs the battery clock to its argument?  [Don't you
love the BUGS section of Sun's gettimeofday(2) man page saying there should
be some way to set the time for a set of systems to millisecond accuracy ...
I wonder if Solaris 2.1 includes NTP :-) ]

	Rich Stevens  (rstevens@noao.edu)
Newsgroups: comp.protocols.time.ntp
Newsgroups: comp.protocols.time.ntp
Subject: NTP Client for Macintosh
From: pmurray@watson.lib.muohio.edu (Peter Murray)
Date: 3 Jan 93 14:05:29 -0500
X-Newsreader: TIN [version 1.1 PL6]

I'm looking for an NTP client for network-connected Macintoshes.  I 
know about Network Time 1.1.1, but it doesn't seem to work with 
XNTPD version 3 servers.

Any help would be appreciated (even source code).  I'll summarize
e-mail messages back to comp.protocols.time.ntp.

Peter
--
Peter Murray, Library Systems Manager        pmurray@watson.lib.muohio.edu
King Library Technical Support                      pemurray@miavx1.bitnet
Miami University, Oxford, Ohio                              W:513/529-2884
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.protocols.time.ntp
Subject: xntp3 and local clock
Date: 23 Dec 1992 10:07:19 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
Distribution: inet
NNTP-Posting-Host: daisy.ee.und.ac.za

In article <1992Dec23.015924.19111@shearson.com>,
pmetzger@snark.shearson.com (Perry E. Metzger) writes:
> Unfortunately, xntp3 has a bug that prevents the local clock as time
> source option from working, and no one out there seems to have a fix.

It works for me, after some small modifications (which I have reported
to Dave Mills).  Take the following explanation with a grain of salt,
because I am really not an expert on NTP.  It would be nice if somebody
who knows what he is talking about could confirm or refute this.

The problem is that the test for (peer->synch <= NTP_MAXDISTANCE) in
ntp_proto.c fails.

For local clocks, in which the peer->delay and peer->rootdelay are zero,
peer->synch ends up being approximately equal to (peer->rootdispersion
+ peer->dispersion).  It's only approximately equal because of the
difference between sys_clock and sys_lastselect.

In both xntp2 and xntp3, the local clock's dispersion is 1 second and
the rootdispersion is 5 seconds, making the synch distance approximately
6 seconds.  In xntp2, NTP_MAXDISTANCE was 16 seconds, so the local
clock worked.  In xntp3, NTP_MAXDISTANCE is 1 seconds, so it doesn't work.

To make synchronisation from the local clock work again in xntp3,
one could either increase NTP_MAXDISTANCE (in ntp.h) or decrease the
LCLDISPERSION and LCLROOTDISPERSION in refclock_local.c.  I have done
both: I increased NTP_MAXDISTANCE back to the 16 seconds that was used in
xntp2, and I added a couple of fudge factors to control the LCLDISPERSION
and LCLROOTDISPERSION at run time instead of at compile time.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
Newsgroups: comp.protocols.time.ntp,comp.unix.aix,comp.protocols.tcp-ip