HDTenEightyP/NetNews huggingface dataset:
From: cwk@irrational.ssc.gov (Carl W. Kalbfleisch)
Subject: Where is the NTP source archive?
Reply-To: cwk@irrational.ssc.gov
Organization: SSC Laboratory, Dallas, TX
Distribution: comp.protocols.time.ntp
Date: Tue, 8 Sep 1992 20:38:59 GMT


Would someone please e-mail me the address of the NTP source
code FTP site.

Thanks in advance.

Carl
--

+--------------------------------------------------------------------------+
|  Carl W. Kalbfleisch                              cwk@irrational.ssc.gov |
|  Superconducting Super Collider Laboratory                               |
|  2550 Beckleymeade Avenue, MS-4002                  Fax: (214) 708-4801  |
|  Dallas, Texas 75237                              Phone: (214) 708-3428  |
+--------------------------------------------------------------------------+
From: shibumi@joes.garage.com (Kenton A. Hoover)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Motorola GPS Receiver
Date: 15 Sep 92 07:03:02 GMT
Reply-To: shibumi@joes.garage.com
Organization: Joe's Garage, San Francisco, KA

glenn@herald.usask.ca (Glenn Hollinger) writes:
>2) The ascii timestamps have a variable delay from 0 to 50 milliseconds.
>This is not very good, but see point 3.

They have a pretty much constant 'pipeline' time, that is, the data you get
is marked by the beginning of its transmission, which is always during a 
certain period of the units operation.

| Kenton A. Hoover                                                            |
| P.O. Box 882643                                             +1 415 957 3614 |
| San Francisco, Kalifornia 94188-2643                shibumi@joes.garage.com |
|==============442.075+100=146.850+=444.625+131.8=440.900+114.8===============|
|  For instance, I'd say, 'What do you think those ham-radio buffs really     |
|  talked about?  Do you think some of them were secretly gay, and they left  |
|  their wives asleep and crept down to their finished basements in the       |
|  middle of the night to have long conversations with "friends" in New       |
|  Zealand or wherever?'                                                      |
|                            'VOX', Nicholson Baker                           |
Newsgroups: comp.protocols.time.ntp
From: fenner@postscript.cs.psu.edu (Bill Fenner)
Subject: Re: Setting the time when the system boots
Organization: Penn State Computer Science
Date: Sun, 6 Sep 1992 16:41:47 GMT

In article <1992Sep5.195717.13976@udel.edu> stewart@ra.cis.udel.edu (John Stewart) writes:
|	if [ -f /usr/local/bin/ntpdate ]; then
|		/usr/local/bin/ntpdate time_server
|	fi

This is what I do:

	if [ -f /etc/hosts.ntpdate ]; then
		/usr/local/bin/ntpdate `cat /etc/hosts.ntpdate`
	fi

That way, I can ntpdate to multiple machines in case the one I just happen
to pick is down.

  Bill
Newsgroups: comp.protocols.time.ntp
From: paulr@umbc4.umbc.edu (Paul Riddle)
Subject: Time synchronization on lots of SGI Indigos
Organization: Univ. of MD, Baltimore County
Date: Thu, 10 Sep 1992 23:31:20 GMT


Hi everyone,

I would like to use xntpd for time synchronization on several labs of
SGI Indigos.  There are a total of 115 machines.  I have built and
tested xntpd successfully, but it doesn't include kernel support for
setting tickadj on the Indigo.  I have tried tweaking tickadj by hand,
but no matter what I do it generates large volumes of syslog messages
saying that it is stepping the clock backwards (one every couple of
minutes).

I also considered running ntpdate periodically from cron to sync the
clock, either with our stratum-2 servers or with other various
stratum-3 machines around campus.  This worked well for keeping the
time in sync.  However, it turned out to be a major hassle trying to
set things up in such a way that no host got bombarded with ntp
requests.

So, my basic question is:  has anyone gotten xntpd to work well on an
Indigo?  If so, how did you do it?

In case it's important, most of our stratum-3 servers are DECstations
running version 1 ntpd.  This is mainly because DECs seem to have
reasonably good clocks, and ntpd is included with Ultrix.

Any help would be appreciated!
Paul

-- 
If found, please return to:         |
Paul Riddle                         | paulr@umbc3.umbc.edu
UMBC, Academic Computing Services   |
Baltimore, MD 21228                 | (410) 455-3929
From: wales@CS.UCLA.EDU (Rich Wales)
Newsgroups: comp.protocols.time.ntp
Subject: Host name changes at UCLA
Date: 11 Sep 92 05:33:20 GMT
Distribution: inet
Organization: The Internet

The UCLA CS Department's two stratum-2 NTP hosts are changing names (but
not addresses).

    gw1.cs.ucla.edu (131.179.128.2) will become ntp1.cs.ucla.edu.
    gw2.cs.ucla.edu (131.179.128.3) will become ntp2.cs.ucla.edu.

I trust this change will find its way into the "clock.txt" file in the
near future.

If you are referencing either of these hosts by name, please change to
the new name.  The current names (gw1 and gw2) will be reassigned next
week to a new gateway router box that does not support NTP.

If you are referencing us by numeric IP address, you don't need to do
anything at all, since the current addresses will not change.

It is OK for any site to peer with =one= of our stratum-2 hosts.  Please
choose one or the other randomly (e.g., flip a coin).  You do not need
to ask my permission first.  However, please do =not= peer with =both=
"ntp1" and "ntp2"; choose one or the other.

Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (310) 825-5683
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Refreshed clock.txt
Date: 10 Sep 92 00:13:21 GMT
Distribution: inet
Organization: The Internet

Folks,

Mike Iglesias noticed some tailing bits of the list of public NTP
chimers were missing, so I took the opportunity to update the file
and stash in the pub/ntp/doc/clock.txt file on louie.udel.edu.

Dave
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  Minor bug in GOES support (xntpd v3)
Date: 15 Sep 92 23:42:02 GMT
Distribution: inet
Organization: The Internet

Jeff,

I'll fix that refclock_goes.c. The code was built by Glenn Hollinger
and, so far as I can tell, has been running for some time. I suspect
he never compiled it without the clock discipline.

Dave
Newsgroups: comp.protocols.time.ntp
From: dundas@chip.Jpl.Nasa.Gov (John Dundas)
Subject: Looking for DTS spec
Organization: Information Systems Engineering Grp, JPL
Distribution: inet
Date: Fri, 11 Sep 1992 22:21:28 GMT

If anyone knows the title and document number of the document(s) that
describe DTS, I would like to know.  Thanks in advance.

John Dundas
dundas@salt.jpl.nasa.gov
From: rizzo@HUB.ENG.WAYNE.EDU (Frank Rizzo 7-0390)
Newsgroups: comp.protocols.time.ntp
Subject: Supscription
Date: 14 Sep 92 18:21:27 GMT
Distribution: inet
Organization: The Internet

Please add the following to your mailing list.

lists@hub.eng.wayne.edu

Thank You

+--------------------------------------------------------------------------+
| Frank F. Rizzo                               Rm. 2410                    |
| Network Manager, Postmaster                  Engineering Computer Center |
| Phone: (313) 577-0390                        Wayne State University      |
| FAX #: (313) 577-5969                        5050 Anthony Wayne Drive    |
| WSU-PROFS: frizzo                            Detroit, Michigan  48202    |
| Internet: Frank_Rizzo@eng.wayne.edu          USA                         |
+--------------------------------------------------------------------------+
Newsgroups: comp.protocols.time.ntp
From: kdenning@portal.hq.videocart.com (Karl Denninger)
Subject: XNTP3 on SVR4 (DELL Intel release)
Organization: VideOcart Inc.
Date: Wed, 9 Sep 1992 15:15:52 GMT

Has anyone ported xntp3 to the SVR4 releases?  I have a Dell machine which
runs ntpd just fine, but xntpd seems to have some problems getting going.
Before I go dive in, has anyone else done this?

--
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022
Newsgroups: comp.protocols.time.ntp
From: shibumi@joes.garage.com (Kenton A. Hoover)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Motorola GPS Receiver
Date: 15 Sep 92 07:01:26 GMT
Reply-To: shibumi@joes.garage.com
Organization: Joe's Garage, San Francisco, KA

glenn@herald.usask.ca (Glenn Hollinger) writes:
>3) There is a 1PPS output available.  The accuracy is described as "The 1
>PPS (when optionally installed) has a 1 sigma accuracy of +/- 75 nano-
>seconds plus a resolution of +/- 52 nanoseconds."  I don't know exactly
>what this means.  (Perhaps an expert can comment?)  It appears to be
>significantly better than the ascii timestamps and should produce a
>decent clock when coupled with a gadget box to the Xntp3 PPS code.

The box was designed to be usable in a differential GPS system as a 
monument source, and so can be told "you are here, and will always be
RIGHT HERE".  This increases the time accuracy to a certain extent.

| Kenton A. Hoover                                                            |
| P.O. Box 882643                                             +1 415 957 3614 |
| San Francisco, Kalifornia 94188-2643                shibumi@joes.garage.com |
|==============442.075+100=146.850+=444.625+131.8=440.900+114.8===============|
|            Ain't nothing in the world like a white skinned girl             |
|            Make your Union Jack and make your flag unfurl                   |
|                                           "Omnibus", XTC                    |
From: rizzo@HUB.ENG.WAYNE.EDU (Frank Rizzo 7-0390)
Newsgroups: comp.protocols.time.ntp
Subject: oops!
Date: 14 Sep 92 18:22:23 GMT
Distribution: inet
Organization: The Internet

Sorry.

I used the wrong alias by mistake.

Please, send no flames.  I know my error.

+--------------------------------------------------------------------------+
| Frank F. Rizzo                               Rm. 2410                    |
| Network Manager, Postmaster                  Engineering Computer Center |
| Phone: (313) 577-0390                        Wayne State University      |
| FAX #: (313) 577-5969                        5050 Anthony Wayne Drive    |
| WSU-PROFS: frizzo                            Detroit, Michigan  48202    |
| Internet: Frank_Rizzo@eng.wayne.edu          USA                         |
+--------------------------------------------------------------------------+
From: jcs@zoo.bt.co.uk (John C Sager)
Newsgroups: comp.protocols.time.ntp
Subject: Trimble & Rockwell GPS Receivers
Date: 10 Sep 92 09:26:30 GMT
Organization: British Telecommunications plc


I recently got a Trimble SVeeSix Plus GPS receiver. This is a 6-channel
receiver module aimed at the automotive market for vehicle navigation.
It has two serial I/O ports and a 1PPS pulse output. Trimble quoted me
$600 one-off for just the module but I purchased the development kit
which includes an antenna/preamplifier and support software. This cost
me about 530 UK pounds. I've only had the module a few days & I am
still exploring its features. I note, however, that there is
jitter on the time output messages relative to the 1PPS signal and they
go missing sometimes if the module is busy doing something else.
When I've quantified the jitter & interfaced it successfully to
xntp3, I'll post again.

I've also got the design guide for the Rockwell Navcore V GPS module.
This is more basic in functionality than the Trimble but is cheaper -
their rep said $450 in quantity for the Sensor version, which is
the module packaged together with an antenna & power conditioning
circuitry suitable for fixing up outdoors somewhere. The navigation
output message, including time, is emitted immediately after the
occurrence of the 1PPS pulse, though the guide says
"In some instances, the data will be delayed by a short period of time
due to bus contention by the OEM's application processor". It is also
not clear if the Rockwell device will continue sending accurate time
if the number of visible satellites drops below three. The Trimble can
continue to supply accurate time with only one visible satellite, as
long as it knows what its own position is.

I also received the customer handbook for the Motorola GPS Core receiver
today. Looks like accurate time & position is getting cheaper by the
day! Any bets on when the first GPS writwatch will appear?

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
Newsgroups: comp.protocols.time.ntp
From: prl@csis.dit.csiro.au (Peter Lamb)
Subject: Re: Export update
Organization: CSIRO Division of Information Technology
Date: Mon, 14 Sep 1992 23:52:32 GMT

Mills@udel.edu writes:

>Folks,

> ... I have reliable intel that a replacement
>authdes.c is available from offshore sources; however, I will
>leave to that source if/when to reveal it.

Yep, you are right. One does not have to be resident in the US to
read the standard and efficiently implement DES.

Good off(US)shore implementations are available from:
	Try:
		ftp.mq.edu.au		/pub/Sources/libdes
		psych.psy.uq.oz.au	/pub/DES
				for Eric Young's (eay@psych.psy.uq.oz.au)
				implementation.
	or
		kampi.hut.fi		/alo
				for Antti Louko's (alo@kampi.hut.fi)

Eric's version is designed to drop-in to the "bones" version of Kerberos.
Antti's version comes with an emulation of the Sun des(1) program.

I haven't tried putting DES into the new stripped-down version of xntpd, and
I probably won't, since I'm no longer Time Lord for anywhere.

-- 
Peter Lamb (prl@csis.dit.csiro.au)
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Date: 14 Sep 1992 11:55:06 -0700
Organization: Motorola MCG, Urbana Design Center
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)

In article <190k6vINN5g9@ftp.UU.NET> brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein) writes:
>   I wish POSIX would stop shooting off into the cosmos, come back to
>   earth, and spend some time documenting what UNIX systems actually *do*.

Funny, the POSIX meetings I've been to have tended to involve a lot of
discussion of existing practice and a lot of drudging through existing
documentation and rehashing it in the dullest possible language.  What
that drudging has generally led to is a realization that none of the
existing documentation specifies *anything* completely enough and that
every vendor's UNIX system is different.  So you have to write a
standard that specifies things nobody specified before and you have to
try to merge different versions of the same functionality.  And if
you're a responsible engineer, you have to resist standardizing bad
practice just because it is existing practice.

scott
--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550

Volume-Number: Volume 29, Number 35
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Date: 10 Sep 1992 16:40:00 -0700
Organization: U of Toronto Zoology
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

>Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
>The time-honored technique of using a directory as a semaphore and using
>mkdir() and rmdir() as lock and unlock works fairly well, although it's
>rather slow...

It isn't reliable, however.  The crucial point is that NFS does not provide
a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
have not seen details and don't have a reference -- that if you look hard
enough at the problem, and consider things like finite cache sizes, you
can prove that there is *no way* to do reliable locking through the NFS
protocol.  You have to use some sort of non-filesystem method, like
locking daemons (and I agree with John that writing your own is the best
method; the existing ones are garbage).

This is one reason (of many) why proposals to canonize NFS as a standard
weren't greeted with cries of delight from all directions...
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry


Volume-Number: Volume 29, Number 30
From: lebrun@ll.mit.edu ("Steven F. LeBrun")
Newsgroups: comp.std.unix,comp.unix.programmer
Subject: File Locking across NFS mounts
Followup-To: comp.unix.programmer
Date: 8 Sep 1992 14:04:45 -0700
Organization: MIT Lincoln Laboratory, Lexington, MA
Expires: 25 Sep 1992
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")

I am looking for a method of file locking what works across NFS
mounted directories and am interested on what methods other 
people are using.

I tried flock() and discovered a bug that only exists if the file 
being locked is a remote (NFS) file.  If a program terminates without 
unlocking an NFS file (due to a system reboot, user abort, program 
bug [this is how I discovered the problem -- bugs can be useful at 
times :-) etc.] the file remains locked so that no other programs 
can access the file.

The programs that access the file are running on different computers 
with the same file accessible via NFS mounts.  Currently, the programs 
are all running on SGI Indigo's (IRIX 4.0.1) and other computers of 
unknown type will be added later.  I would prefer staying with advisory 
file locking but manditory file locking is an option.  Since the file
being locked is a log/audit trail file that the programs append their
next entries, locking the entire file is acceptable.  Locking the next
local record (next entry) and the entire file will have the same 
effect on the programs accessing the file.


--
Steven F. LeBrun
lebrun@ll.mit.edu

[ Note crosspostings, and Followup line.  Feel free to post any followups
  here (comp.std.unix) if you feel it relevent. -- mod ]

Volume-Number: Volume 29, Number 21
From: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Date: 13 Sep 1992 16:51:59 -0700
Organization: IR
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)

Henry Spencer writes:
> You just canNOT find these problems without writing code from the spec.
> Nothing else works.

Seems about time to repeat this:

What makes standard-writing so attractive is that it strokes your ego.
You get to write down your musings about how the world should work, and
boom! Everyone does what you say. You don't have to waste time actually
*implementing* your ideas, or working out the problems, or competing
with people who were foolish enough to try their non-POSIX-approved
products on the market. You've got an _ego standard_.

This psychological explanation may sound a bit nasty, but it explains a
lot. It explains why POSIX members react emotionally to any hint that
their standards don't reflect the real world or are technically
inferior. It explains why no POSIX ``standard'' describes the state of
any actual system at the time of standardization. It explains why POSIX
people are so incredibly enthusiastic about writing standards, when in
the real world writing a standard means drudging through existing
documentation and rehashing it in the dullest possible language.

I wish POSIX would stop shooting off into the cosmos, come back to
earth, and spend some time documenting what UNIX systems actually *do*.

---Dan

Volume-Number: Volume 29, Number 34
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Date: 15 Sep 1992 13:47:34 -0700
Organization: Department of Chemistry, University of Toronto
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)

In article <193se9INN4h7@ftp.UU.NET> brnstnd@KRAMDEN.ACF.NYU.EDU
(D. J. Bernstein) writes:
>Ah, but you never _have_ to write a standard.
>
>You see that systems vary widely in, e.g., the output format of ``who'',
>and even the type of information stored in /etc/utmp (or whatever file
>``who'' reads). Does this mean you have to apply your imagination,
>specify what the market hasn't specified, merge what the market hasn't
>merged? No.  [...]

     This assumes that "the market" purchases systems based on the
format of the output of who.  This is not the case, but that is not to
say that purchasers of Unix systems would not like their machines to all
behave consistently.

>You shouldn't standardize ``who'' at all. Wait for market convergence.

     This will never happen.  Vendors have no incentive to standardize
who (among other things).  The only real leverage users can exert to obtain
properly standardized environments is through the standards process.
The power of the purse is essentially useless when it comes to little
things like the output of who and the command line switches of cc since
no one (to my knowledge) makes purchasing decisions based on these
criteria.  This sort of thing turns into just another annoyance in a
heterogeneous environment; it is however a pointless annoyance which standards
can essentially do away with.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca


Volume-Number: Volume 29, Number 39
From: johnl@iecc.cambridge.ma.us ("John R. Levine")
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Date: 10 Sep 1992 16:40:51 -0700
Organization: I.E.C.C.
Reply-To: std-unix@uunet.UU.NET
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: johnl@iecc.cambridge.ma.us ("John R. Levine")

>Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")
>I am looking for a method of file locking what works across NFS
>mounted directories and am interested on what methods other 
>people are using.

You aren't likely to get very satisfactory results using record locking.
Many versions of the locking daemon don't work at all, and the crash
recovery seems to me to be hopelessly amateurish.  I've worked on projects
that tried to use record locking and even after doing six backflips to try
and work around the record locking bugs, at least to get to the point that
we didn't just hang if the locking daemon wasn't working, the results
still were not great.

The time-honored technique of using a directory as a semaphore and using
mkdir() and rmdir() as lock and unlock works fairly well, although it's
rather slow.  Using link() and unlink() also works, at least on systems
that use the Unix semantics that you can't link on top of an existing
file.

If you're serious about having the locks work, in the long run you'll get
much better results if you write your own daemon that listens to a TCP/IP
socket and handles reserve and release messages, or maybe even manages the
file itself and accepts requests to atomically update and read from the
file.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 31