HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Client for Macintosh
From: pmurray@watson.lib.muohio.edu (Peter Murray)
Date: 11 Jan 93 13:16:02 -0500
X-Newsreader: TIN [version 1.1 PL6]

Peter Murray (pmurray@watson.lib.muohio.edu) wrote:
: 
: 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.

I got a response back from the author of Network Time 1.1.1 that said he
was working on version 2.0 with System 7 and NTP version 3 support.  Thanks
to everyone that responded.

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: thorinn@DIKU.DK (Lars Henrik Mathiesen)
Newsgroups: comp.protocols.time.ntp
Subject: bug in util/tickadj.c on MIPS RISCos
Date: 6 Jan 93 08:53:12 GMT
Distribution: inet
Organization: The Internet

Guntram,

I am not quite sure what has happened in the tickadj source, but in my
older copy that error message is inside '#ifdef sun' --- in fact, on
non-Suns it gives an error if you use the -p option. I am almost
certain that this is _not_ a local change.

There is a considerable amount of unnecessarily complex AUX hackery
involving the kernel namelist. I do not see the why there has to be a
differently named, but essentially identical list of offsets to use
with the AUX namelist --- it just leaves out K_DOSYNC and K_NOPRINTF,
and includes an **unused** X_V. The static initializer evidently
works, so why not just use '#ifdef' to get the right names in there?
There is no harm in looking for extra stuff, and if the "v" variable
really is necessary, it can be added to the global list and ignored on
all other systems.

Could the person that sent in the AUX changes enlighten us as to the
reasons? And where did the '#ifdef sun's go?

Can anybody confirm, by the way, that frobbing the kernel _noprintf
variable is interesting iff defined(sun)?

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  Problems with xntp and MIPS RISC/os 5.01
Date: 13 Jan 93 04:56:00 GMT
Distribution: inet
Organization: The Internet

Alan,

First, make sure your clock has a resolution at least in the 10-20 ms
range; if not, forget it. Then, start xntpd and watch the offsets right
after startup. If there is a large frequency offset in your CPU, you
will see a definite trend in offsets for the first few. If the difference
in (smoothed) offsets from one sample to the next is more than one
millisecond, your frequency is out of tolerance. Run your CPU for a
day without outside synchronization and, using a wristwatch and deft
fingers, try to estimate the frequency error in parts per million.
Then, tickle adjtime to compensate for it, about one part in 10,000
for each 100 ppm. You get to guess the sign - I forget. Repeat the process
until the frequency error is less than 100 ppm.

This is all the help I can give. If your frequency error is less than
100 ppm and the stock code still jumps around, you need an operating-
system guru, not a simple clockwatcher.

Dave
Newsgroups: comp.protocols.time.ntp
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: XNTP - NTP config Problem
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Fri, 8 Jan 93 20:58:12 GMT


In article <1993Jan8.111729.1@cudnvr.denver.colorado.edu>, sasurguine@cudnvr.denver.colorado.edu writes:
|>
|>I Need Config Info for the following Network Configuration.
|>I have a Micor Vax running NTP. This has been running for a while <since
|>I am quite new and didn't actually set it up, I don't know exactly how long:
|>Thus, I don't know what version I am running.
|>
|>I would like to utilize XNTP to get 4 SPARCS in sync with the Micro Vax running
|>NTP.  The Vax gets its clock info from NCAR/UCAR in Boulder.  I have tried to
|>install XNTP on 1 of the SPARCS using the following conf info:
|>
|>Peer 192.140.221.60        version1           #Our Vax
|>
|>Peer 192.140.221.60                           #Our Vax
|>
|>To the best of my knowledge niether of these entries in ntp.conf are
|>working < after all I still see my time as MST not UTC/GMT >
|>
|>I'm obviously missing something here.  Do I need to alter any config info
|>on the Micro Vax < The NTP server >.  ARGHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!
|>
|>Thanks For Your Help:
|>
|>Scott A. Surguine

Scott,
	You might want to contact you VAX TCP vendor.. if you are running
Wollongong software drop me a line with your configuration file in it, and I
will see what I can do..

-Larry.
From: sanders@cs.ubc.ca (Michael Sanderson)
Newsgroups: comp.protocols.time.ntp
Subject: NTP version 3 on Apollo DOMAIN/OS
Date: 4 Jan 1993 09:32:44 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Distribution: inet
NNTP-Posting-Host: warsteiner.cs.ubc.ca
Summary: What should the tickadj and tick be?
Keywords: NTPv3, apollo, domain/os

I have about 40 Apollo 3000 and 3500 machines running DOMAIN/OS 10.2.  I'm
currently running ntp version 1 on the machines and they are keeping time quite
well.  However, I would like to upgrade the software to the xntp package kept
on louie.udel.edu so that I can run the same software on those machines and
the rest of the machines in our department.

I would like to know if anyone has done this and experimented with values for
the variables tickadj and tick.  DOMAIN/OS doesn't have kmem or libkvm, so I
defined NOKMEM and used the default values.  However, on the one machine that
I am testing the software on, the hourly log information displays increasingly
larger values for freq, until it finally dies with the message

Drift exceeds +371ppm, cannot cope.

I don't know that much about the code, so perhaps I'm off track believing that
this error results from poor values for tickadj and tick.

Someone running the version 2 xntp package had some patches for DOMAIN/OS
however I don't have them.  I'm willing to try them out if someone will send
them to me and I'll post my results.
-- 

Michael Sanderson                   sanders@cs.ubc.ca
                                    ubc-cs!sanders

Newsgroups: comp.protocols.time.ntp
From: rbrand@usasoc.soc.mil (Raymond S. Brand)
Subject: Re: SLEWALWAYS [was-> Re: Problems with xntp and MIPS RISC/os 5.01]
Organization: is a nice thing
Distribution: inet
Date: Tue, 12 Jan 1993 15:40:49 GMT

In article <9301121521.AA22049@tyr.diku.dk>, thorinn@DIKU.DK (Lars Henrik Mathiesen) writes:
> Alan,
> 
> I am not sure that the SLEWALWAYS code has ever been tested. (I
> certainly didn't do so when I was hacking xntp to version 3.) On the
> other hand, it does seem like it ``ought to'' work --- it's not that
> complicated. 

SLEWALWAYS works fine (at least on the mob of Suns here).

> Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)

						rsbx

-------------------------------------------------------------------------------------
Raymond S. Brand						rbrand@usasoc.soc.mil
-------------------------------------------------------------------------------------
Newsgroups: comp.protocols.time.ntp
From: dglattin@trirex.com (Dennis Glatting)
Subject: Where can I find Version 3 source?
Keywords: 3 NTP
Organization: Trirex Systems Inc.
Distribution: usa
Date: Wed, 6 Jan 1993 05:02:05 GMT


Where can I find both public domain and commercial implementations of  
Version 3 NTP?

--
Dennis P. Glatting / Sr. Technical Manager / Trirex Systems Inc.
315 Post Road West / Westport, Connecticut 06880 / (203)221-4600
dennis_glatting@trirex.com (NeXTmail Ok)
Member League for Programming Freedom
From: kozowski@ohsu.edu (Eric Kozowski)
Newsgroups: comp.protocols.time.ntp
Subject: xntp3 on SVR4.1ES
Date: 7 Jan 93 00:48:53 GMT
Article-I.D.: ohsu.1993Jan7.004853.14129
Organization: Oregon Health Sciences University


I have ported xntp3 to SVR4.1ES on an AT&T 3B2/1000.  When I start xntpd I get  
the following message in the syslog:

Jan  6 11:43:58 sellwood xntpd[15260]: system event 1 status c010

What does this mean?

xntpd appears to be working ok and every couple of hours I get a syslog message  
similar to the following:

Jan  6 11:18:51 sellwood xntpd[13188]: offset 0.000000 freq 0.76137 comp 0

Also, xntpdc and ntpq compiled ok, but when I try to run ntpq -p or xntpdc -p
I get the following error:

localhost: timed out, nothing received
***Request timed out

I realize this menas that it is trying to connect with the local xnptd and is  
failing.  I can't seem to figure out why it is doing this.  Any ideas?

Thanks.

--
Eric Kozowski                | System/Network Administrator
kozowski@ohsu.edu            | Oregon Health Sciences University
                             | 840 SW Gaines Rd GH113
503/494-4537                 | Portland, Oregon 97201
Xref: sparky comp.protocols.time.ntp:1152 comp.unix.aix:13032 comp.protocols.tcp-ip:5808
From: valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
Newsgroups: comp.protocols.time.ntp,comp.unix.aix,comp.protocols.tcp-ip
Subject: Re: xntp3 socket problem with UDP datagrams from INADDR_ANY.
Keywords: xntp3,AIX/370,UDP,socket
Date: 6 Jan 93 00:33:23 GMT
Followup-To: comp.protocols.time.ntp
Organization: Virginia Tech, Blacksburg, VA

In article <1992Dec29.115408.103086@ipgaix.unipg.it> peppe@ipgaix.unipg.it (G. Vitillaro) writes:
>
>I had this problem with xntp3 (in xntpd) under AIX/370 1.2.1 (1400).
>I'm interested to understand if I met a bug and
>if there is any way to go over the problem.

Oh.. *that* little bug.  It drove me bonkers while trying to get
AIX/370 and xntp to cooperate.  Here's the fix I used to work
around it:

*** ntp_io.c.dist       Tue Mar 17 16:39:15 1992
--- ntp_io.c    Tue Mar 17 16:40:26 1992
***************
*** 688,693 ****
--- 688,694 ----
                printf("sendpkt(%s, %s, %d)\n", ntoa(dest),
                        ntoa(&inter->sin), len);
  #endif
+       if (inter == any_interface) inter++;

        for (slot = ERRORCACHESIZE; --slot >= 0; )
                if (badaddrs[slot].port == dest->sin_port &&


This basically prevents xntpd from "seeing" the 'wildcard' interface.

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  bug in util/tickadj.c on MIPS RISCos
Date: 7 Jan 93 05:14:24 GMT
Distribution: inet
Organization: The Internet

Guntram,

There seems to be a version problem. Your patch fails in an ugly way.
There have been a number of patches applied to tickadj.c recently.
You should fetch the latest version of xntp3 now on louie.udel.edu
and try again. Sorry for the inconvenience.

Dave
From: ajudge@maths.tcd.ie (Alan Judge)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problems with xntp and MIPS RISC/os 5.01
Date: 12 Jan 93 16:33:09 GMT
Distribution: inet
Organization: The Internet

Lars> I am not sure that the SLEWALWAYS code has ever been tested. (I
Lars> certainly didn't do so when I was hacking xntp to version 3.) On the
Lars> other hand, it does seem like it ``ought to'' work --- it's not that
Lars> complicated.

I'm a little worried about what happens if the clock drifts too far
for adjtime to be able to cope reasonably.

Lars> It does seem that you need something like SLEWALWAYS, or perhaps a
Lars> variant that uses gettimeofday to get to the nearest second and leaves
Lars> the residue in sys_offset. Since it is you who needs the feature, it
Lars> is probably up to you to get it to work.

This is what I was thinking of doing.  I'm willing to do the coding,
but I'm worried about breaking NTP in the process, as I don't really
understand how it works.

For example, if I use a variant of settimeofday to get to the nearest
second, will xntp be able to deal with the rest of the offset with
adjtime?  As the code is now, it looks like it will attempt to step
for any offset greater than 128ms, and may never get in sync.  Also,
the comments warn about increasing CLOCK_MAX above 500ms, which is the
minimum that I would need (and, even then, I could end up stepping a
lot).

What sort of tickadj values are reasonable if one is reliant on
adjtime? 

Have you any hints about what I might try, or things to avoid?
What is the best way of testing an NTP server?  (I don't want to start
running a flaky Stratum 2.)
--
Alan
Newsgroups: comp.protocols.time.ntp
From: maj@cl.cam.ac.uk (Martyn Johnson)
Subject: Re: xntp3 refuses to talk from little-endian to big endian machines
Organization: U of Cambridge Computer Lab, UK
Distribution: inet
Date: Tue, 12 Jan 1993 17:32:01 GMT

In article <1iukkuINNhmg@wintermute.phys.psu.edu>, kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
...
|>                      It _looks_ like there is a byte-order problem, but
|> I have not gone that far into the problem.  Does anyone else run xntpd on
|> a little endian machine?  If so, please let me know what you did to get it
|> to work!
...

xntp2 had SEVERAL byte order problems in the xntpdc interface, though I
did not find any in the main protocol. It was fairly obvious that whoever
wrote the code had been fairly sloppy about hton and ntoh functions. In
some places the wrong one of the pair was used, which doesn't cause anything
to go wrong, but is an indication of carelessness.

I sent off patches for these problems to somebody who was collecting them,
but I have no idea whether they ever made it into the definitive sources.

I haven't yet done the exercise for xntp3, so I cannot verify your assertion,
but it would not surprise me to find byte order problems.

-- 
Martyn Johnson      maj@cl.cam.ac.uk
University of Cambridge Computer Lab
Cambridge UK
From: sasurguine@cudnvr.denver.colorado.edu
Newsgroups: comp.protocols.time.ntp
Subject: XNTP - NTP config Problem
Date: 8 Jan 93 11:10:29 GMT

I Need Config Info for the following Network Configuration.
I have a Micor Vax running NTP. This has been running for a while <since
I am quite new and didn't actually set it up, I don't know exactly how long:
Thus, I don't know what version I am running.

I would like to utilize XNTP to get 4 SPARCS in sync with the Micro Vax running
NTP.  The Vax gets its clock info from NCAR/UCAR in Boulder.  I have tried to
install XNTP on 1 of the SPARCS using the following conf info:

Peer 192.140.221.60        version1           #Our Vax

Peer 192.140.221.60                           #Our Vax

To the best of my knowledge niether of these entries in ntp.conf are
working < after all I still see my time as MST not UTC/GMT >

I'm obviously missing something here.  Do I need to alter any config info
on the Micro Vax < The NTP server >.  ARGHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!

Thanks For Your Help:

Scott A. Surguine
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  NEC NEWS
Date: 6 Jan 93 01:19:28 GMT
Distribution: inet
Organization: The Internet

Sean,

I know of no port; however, somebody might have done that. I expect the
next port will be to an LSI-11 running RT-11. Fancy that.

Dave
From: gwolsk@sei.com (Guntram Wolski)
Newsgroups: comp.protocols.time.ntp
Subject: Re:  bug in util/tickadj.c on MIPS RISCos
Date: 8 Jan 93 01:04:09 GMT
Distribution: inet
Organization: The Internet

Mills@udel.edu writes:
 > Guntram,
 > 
 > There seems to be a version problem. Your patch fails in an ugly way.
 > There have been a number of patches applied to tickadj.c recently.
 > You should fetch the latest version of xntp3 now on louie.udel.edu
 > and try again. Sorry for the inconvenience.

I checked xntp3.tar.Z on louie.udel.edu and it has a date of Dec. 30,
1992.  Well before I picked up the software.  I realize I did the diff
the wrong way so here is the appropriate diff to be fed to patch:

*** tickadj.c.fcs	Sun Dec 13 18:41:08 1992
--- tickadj.c	Tue Jan  5 16:53:28 1993
***************
*** 312,318 ****
  		    progname);
  		err++;
  	}
! #ifndef	_AUX_SOURCE
  	if (nl[K_NOPRINTF].n_value == 0) {
  		(void) fprintf(stderr, "%s: namelist can't find `_noprintf'\n",
  		    progname);
--- 312,318 ----
  		    progname);
  		err++;
  	}
! #if	!defined(_AUX_SOURCE) && !defined(mips)
  	if (nl[K_NOPRINTF].n_value == 0) {
  		(void) fprintf(stderr, "%s: namelist can't find `_noprintf'\n",
  		    progname);




Hope this helps,
--G
--
Guntram Wolski                   gwolsk@sei.com
Silicon Engineering, Inc.        408-438-5331 x112
...!{sgiblab,ames}!seidc!gwolsk
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  nbstime
Date: 7 Jan 93 04:54:31 GMT
Distribution: inet
Organization: The Internet

Mohamed,

Sorry for the delay. See the README file now in the pub/ntp directory
on louie.udel.edu.

Dave
Newsgroups: comp.protocols.time.ntp
From: ebrandsm@prl.philips.nl (Ewout Brandsma)
Subject: Re: Wireless time services -- standards?
Originator: ebrandsm@prl.philips.nl
Organization: Philips Research Laboratories, Eindhoven, The Netherlands
Date: Thu, 7 Jan 1993 08:41:53 GMT

In article <JIM.93Jan5183518@hunter.cs.strath.ac.uk>
jim@cs.strath.ac.uk (Jim Reid) writes:

>TV teletext services already do this (at least in the UK). However, it
>is up to the broadcaster to determine the accuracy of the teletext
>time information. Some may be less bothered about this than others - I
>have seen cable-supplied teletext with times minutes away from GMT. [UK
>broadcasters sync their teletext clocks to the UK MSF signal.] This
>would add extra complexity in the user interface to household gadgets
>that are already over-complicated. [eg - how do you tell the VCR what
>timezone it's in or which channel's teletext to believe?]

Actually this is exactly what my VCR (Philips VR 813) does. This deck
is equipped with a teletext decoder to enable programming via teletext
(VPT) and program start/end detection (PDC). Given the fact that it
already contains a teletext decoder, using it to synchronize the clock
shouldn't cost much extra.

It always uses the teletext signal present on the first preset channel
to synchronize clocks. So you should program your channels in such a
way that the first one contains a reliable teletext clock of your own
timezone. This may take away some freedom in channel allocation (though
not much in my opinion), but it doesn't complicate the user interface
at all.

Ewout Brandsma (ebrandsm@prl.philips.nl)
From: dave@HIAULY1.HIA.NRC.CA (John David Anglin)
Newsgroups: comp.protocols.time.ntp
Subject: adjtime on hp730 under hpux 8.07
Date: 6 Jan 93 22:15:20 GMT
Distribution: inet
Organization: The Internet

Since about the start of the new year, the syslog file on my hp730 running
hpux 8.07 has been filling up with the following error message:

Jan  6 16:37:38 hiauly1 xntpd[1770]: Previous time adjustment didn't complete

Do you have any suggestions as to what has gone wrong?

Thanks in advance,

Dave Anglin
National Research Council of Canada
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Wireless time services -- standards?
Date: 5 Jan 93 18:35:18 GMT
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
In-reply-to: tih@barsoom.nhh.no's message of 2 Jan 93 14:53:18 GMT

In article <tih.725986398@barsoom> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes:

   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.

Backup power supplies - usually big capacitors rather than batteries -
for clocks on things like VCRs are very cheap: perhaps costing a few
pennies.

   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?

A good question, but the answer is simple: cost. A backup power supply
for the clock is at least a couple of orders of magnitude cheaper than
a decent radio clock receiver or a teletext decoder. Another problem
is the diversity of time signals in the world: which one should the
VCR manufacturer include? WWV? DCF? MSF? OMEGA? GPS? (The last two are
probably best for availability throughout the world. However, they
ain't cheap. The cheapest GPS clocks cost $5-600 - roughly twice that
of a VCR.)

   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?

Probably because it's simpler and cheaper to put a quartz oscillator
on the device. There are so many world-wide clock and broadcast
standards that adding this feature to a VCR (say) would be a difficult
technical and political problem. It would also add expense and
complexity which could make sales harder to come by.

   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.

TV teletext services already do this (at least in the UK). However, it
is up to the broadcaster to determine the accuracy of the teletext
time information. Some may be less bothered about this than others - I
have seen cable-supplied teletext with times minutes away from GMT. [UK
broadcasters sync their teletext clocks to the UK MSF signal.] This
would add extra complexity in the user interface to household gadgets
that are already over-complicated. [eg - how do you tell the VCR what
timezone it's in or which channel's teletext to believe?]

		Jim
From: thorinn@DIKU.DK (Lars Henrik Mathiesen)
Newsgroups: comp.protocols.time.ntp
Subject: Problems with xntp and MIPS RISC/os 5.01
Date: 12 Jan 93 15:21:05 GMT
Distribution: inet
Organization: The Internet

Alan,

I am not sure that the SLEWALWAYS code has ever been tested. (I
certainly didn't do so when I was hacking xntp to version 3.) On the
other hand, it does seem like it ``ought to'' work --- it's not that
complicated. 

It does seem that you need something like SLEWALWAYS, or perhaps a
variant that uses gettimeofday to get to the nearest second and leaves
the residue in sys_offset. Since it is you who needs the feature, it
is probably up to you to get it to work.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
From: gwolsk@sei.com (Guntram Wolski)
Newsgroups: comp.protocols.time.ntp
Subject: bug in util/tickadj.c on MIPS RISCos
Date: 6 Jan 93 01:02:57 GMT
Distribution: inet
Organization: The Internet


Don't know where else to send this minor bug report to, so here goes:

I have compiled xntp version 3.1 on a mips box running RISCos 4.52
and when I try to run tickadj I get the message:

./tickadj: namelist can't find `_noprintf'

It seems the mips boxes don't have this variable in the kernel.  Maybe
this should be #ifdef'ed in the code:


*** tickadj.c   Tue Jan  5 16:53:28 1993
--- tickadj.c.fcs       Sun Dec 13 18:41:08 1992
***************
*** 312,318 ****
                    progname);
                err++;
        }
! #if   !defined(_AUX_SOURCE) && !defined(mips)
        if (nl[K_NOPRINTF].n_value == 0) {
                (void) fprintf(stderr, "%s: namelist can't find `_noprintf'\n",
                    progname);
--- 312,318 ----
                    progname);
                err++;
        }
! #ifndef       _AUX_SOURCE
        if (nl[K_NOPRINTF].n_value == 0) {
                (void) fprintf(stderr, "%s: namelist can't find `_noprintf'\n",
                    progname);


--G
--
Guntram Wolski                   gwolsk@sei.com
Silicon Engineering, Inc.        408-438-5331 x112
...!{sgiblab,ames}!seidc!gwolsk

Newsgroups: comp.protocols.time.ntp