HDTenEightyP/NetNews huggingface dataset:
From: art@cs.UAlberta.CA (Art Mulder)
Subject: Re: XNTP on SPARC IPX
Organization: University of Alberta, Edmonton, Canada
Date: Fri, 22 Jan 1993 20:46:43 GMT

sasurguine@cudnvr.denver.colorado.edu writes:

>I am STILL trying to get XNTP up & operational on a SPARC IPX.  I am now 
...

Scott, I tried mailing you the other day, but cudnvr.denver.colorado.edu
claims to have no idea who 'sasurguine' is.  You should tell your sysadmin
that your news software is putting bogus return addresses into your
news header.

I've compiled xntp on Sparc's with minimal fuss.  However, I did not
try and compile in CHU support (as your note of yesterday implied you did).

If you send me email, with a functional email address, I'll happily send
you the "Config" file that I used for our Sun4's.  

...art

DISCLAIMER: I'm no xntp expert, just someone who "plugged it in and
  it works"
--
 ...art mulder ( art@cs.ualberta.ca )    | "Do not be conformed to this world,
 Department of Computing Science         |  but be transformed by the renewal
 University of Alberta, Edmonton, Canada |  of your mind, ..."  Romans 12:2
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  xntp on HP 710 running HP-UX 8.05 - problems
Date: 21 Jan 93 22:53:01 GMT
Distribution: inet
Organization: The Internet

Ken,

Thanks; your patch is now number seven on that foopaw. I'll put up 
the several patches received on that and other issues soon. Whew.

Dave
Newsgroups: comp.protocols.time.ntp
From: art@cs.UAlberta.CA (Art Mulder)
Subject: Re: Ntpdate Xntpdc Xntpd Troubles
Organization: University of Alberta, Edmonton, Canada
Date: Mon, 25 Jan 1993 20:20:22 GMT

sasurguine@cudnvr.denver.colorado.edu writes:

>Now that I have compiled the latest XNTP, I am actually getting some results.
>About the only command I can get to work correctly seems to be ntpdate.

>I am firing up XNTPD on a SPARC IPX and trying to get my clock from a
>Micro VAX running Multinet.  When I fired up the XNTPD yesterday, the
>clock raced ahead of the Micro Vaxes by roughly 6 minutes < after starting
>out 2 behind >.  It took about 1.5 hours for this to occur.

>My /usr/xntp/conf/ntp.conf file :

>server 192.150.224.50 version 1  #Our Micro Vax

>This is the only config file I have altered.

>When I attempt to:

>ntpdate 192.150.224.50 I get the error:

>ntpdate: no server suitable for synchronization found

  If your server is version 1, (as your ntp.conf file shows) then
  you must also instruct ntpdate of this fact via "-o 1"

--
 ...art mulder ( art@cs.ualberta.ca )    | "Do not be conformed to this world,
 Department of Computing Science         |  but be transformed by the renewal
 University of Alberta, Edmonton, Canada |  of your mind, ..."  Romans 12:2
Newsgroups: comp.protocols.time.ntp
From: hubler@galaxy.lerc.nasa.gov (Dale Hubler)
Subject: Re: Total novice question regarding xntpd & RS6000's
Organization: NASA Lewis Research Center
Distribution: na
Date: Fri, 29 Jan 1993 03:34:43 GMT

In article <1993Jan27.192325.5614@eagle.lerc.nasa.gov> fsset@bach.lerc.nasa.gov (Scott Townsend) writes:
>I'm a new, non-administartor type user of AIX & xntpd on a cluster of 32
>RS6000's.  This system is used for lots of compute-bound things, some running
>in parallel over Ethernet.
>
>
>I'd appreciate any comments you may have.  I`m not an administrator for this
>system but if the net wisdom can suggest some things to try, either I can
>try it or if I don't have the required permissions I think I can find someone
>who does.
>

As one of the admins who set these things up and as the admin who
threw on xntp I figured I'd post the answer here too.  Uh, duh,
what's an /etc/ntp.conf file???  My brain must have been paged the 
day I set them up.  They are all within a second now.  Thanks here
too Scott.

Dale
--
Dale A. Hubler  (216) 977-7014   hubler@lerc.nasa.gov
For each and every low-tech problem there exists a high-tech solution
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: YADU-II
Date: 25 Jan 93 16:07:57 GMT
Distribution: inet
Organization: The Internet

Folks,

Happens every time. I put up the latest batch of patches and approximately
instantly a huge batch of additional patches lands my airstrip. You may
successfully resist the urge to snarf the pub/ntp/xntp3.tar.Z distribution
on louie.udel.edu, unless you (a) plan additional patches or (b) have
a TrueTime OM-DC radio clock, for which a driver is now included, (c)
have a TrueTime GOES radio clock, for which mandatory patches are included.
The other stuff is mostly portability and maintenance stuff. For you
Europeans, Frank Kardel has a new DCF77 clock driver.

For the DownUnders, the OM-DC support is for the Omega navigation system,
which is one of only two systems (the other being GPS) that work in the
southern hemisphere for precision time distribution.

Dave
From: thorinn@DIKU.DK
Newsgroups: comp.protocols.time.ntp
Subject: XNTP3/MIPS RISCos 5.01 solved (ish)
Date: 26 Jan 93 11:00:30 GMT
Distribution: inet
Organization: The Internet

Philip,

thanks for the explanation. Anyway, as Alan pointed out, it can't be
the SETTIMEOFDAY_DAMAGED code that causes his problem.

It still looks to me as if, somehow, the system clock jumped one
second backwards. Possibly the new RISC/os clock code is not robust in
the face of multiple adjtime calls.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Newsgroups: comp.protocols.time.ntp
From: larson@loren.net.com (Alan Larson)
Subject: CLOCK.ADJ
Organization: Network Equipment Technologies
Date: Thu, 21 Jan 1993 21:50:57 GMT


  The loop filter parameters in xntp3 (include/ntp.h) say:

     * Loop filter parameters.  See section 5.1 of the specification.
     * Note that these are appropriate for a crystal time base.  If your
     * system clock is line frequency controlled you should read the
     * specification for appropriate modifications.

    #define	CLOCK_ADJ	0	/* adjustment interval: 2**0 = 1 */

  When I looked in section 5.1 and table 6 (page 40 of RFC1305),
it said that the appropriate value or CLOCK.ADJ was 4 seconds for
a crystal, and 1 second for the mains.


  Which is right?  There seems to be no way to determine which is
correct, since the section 5.1 (Fuzzbnall Implementation) has no
discussion of why this particular interval was selected.

  Interestingly, there is also no mention of a clock adjustment being
actually done at a time relative to the CLOCK.ADJ counter.  What is
the real purpose of this variable?

	Alan
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Service in UK
Date: 26 Jan 93 14:56:11 GMT
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
In-reply-to: dwells@fits.cv.nrao.edu's message of 25 Jan 93 14:15:27 GMT

In article <DWELLS.93Jan25091527@fits.cv.nrao.edu> dwells@fits.cv.nrao.edu (Don Wells) writes:

   In article <whiskerp.26.0@logica.co.uk> whiskerp@logica.co.uk (Peter
   Whisker) writes: "... It seems that the UK has no NTP servers - the
   nearest (and the only GMT/BST time zone one) is Trinity College
   Dublin..."

This is a wrong impression. There are many NTP servers in the UK. My
department alone has about 100 or so. There are a handful of stratum 1
servers, though most of them rely on the unsatisfactory MSF signal.
BTW, the time zone that a server is in doesn't matter - NTP timestamps
and radio signal sources like MSF use GMT/UTC. Round trip times to far
away servers is another matter however..... 

I know of three radio clocks linked to stratum 1 NTP servers in the
UK, though I have no explanation why these aren't in the clock.txt
file on louie.udel.edu. These are:

Server(s)				Contact(s)		Source
bear.zoo.bt.co.uk			John Sager		GPS
					jcs@zoo.bt.co.uk
beal.ncl.ac.uk				Dick Snow		MSF
					C.R.Snow@ncl.ac.uk
					Roger Broughton
					R.E.Broughton@ncl.ac.uk
{ashby,albatross,			Piete Brooks		MSF
gannet,swan}.cl.cam.ac.uk		pb@cl.cam.ac.uk
					Martyn Johnson
					maj@cl.cam.ac.uk

I understand that the servers at Cambridge are linked to one MSF
receiver with multiple outputs. Please contact the people above for
details of access policies before attempting to use their servers.
Access to the GPS server is particularly difficult because it is
tucked away behind British Telecom's Internet firewall.

Anyone is welcome to peer with my Stratum 2 servers -
ntp[0-4].cs.strath.ac.uk - these peer with a number of Stratum 1
servers (and sources) throughout the world.

		Jim
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  lib/dcf77parse.c
Date: 26 Jan 93 23:29:01 GMT
Distribution: inet
Organization: The Internet

Bill,

Done.

Dave
From: jones@HERMES.CHPC.UTEXAS.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Solaris 2.1
Date: 27 Jan 93 00:37:43 GMT
Distribution: inet
Organization: The Internet


I have the mods to make ntpd run under Solaris 2.1.  I does not work
very well.    I suppect the main problem is the need to turn of
the time of day clock.  Does anyone know how to do this!

Bill Jones
From: jones@HERMES.CHPC.UTEXAS.EDU
Newsgroups: comp.protocols.time.ntp
Subject: lib/dcf77parse.c
Date: 26 Jan 93 21:44:34 GMT
Distribution: inet
Organization: The Internet



Mill,

Could you get  Frank Kardel to move lib/dcf77parse.c to 
xnptd/refclock_dcf77.c.

It really should not be compiled unless you are building a dcf77 driver!
It make it too hard to build the ntp lib on non SunOS 4.1 machines!!!

Bill Jones
From: philip@CGIN.CTO.CITICORP.COM (Philip Gladstone)
Newsgroups: comp.protocols.time.ntp
Subject: Re:  XNTP3/MIPS RISCos 5.01 solved (ish)
Date: 25 Jan 93 16:46:37 GMT
Distribution: inet
Organization: The Internet


The way that SETTIMEOFDAY_DAMAGED works is that is enables (part of)
the SLEWALWAYS code. settimeofday() calls are only done for errors of more than
2 seconds. After a settimeofday, a gettimeofday is done to determine the error
left (which is typically under 1 second - depending on the nature of the
broken settimeofday). This value is pushed into the SLEWALWAYS code. Thus
after a STEP, the system time will *not* be correct, but the internal NTP
time will be. The error is removed by the adjtime calls over some time
period.

Philip
Newsgroups: comp.protocols.time.ntp
From: dwells@fits.cv.nrao.edu (Don Wells)
Subject: Re: Service in UK
Organization: nrao
Date: Mon, 25 Jan 1993 14:15:27 GMT

In article <whiskerp.26.0@logica.co.uk> whiskerp@logica.co.uk (Peter
Whisker) writes: "... It seems that the UK has no NTP servers - the
nearest (and the only GMT/BST time zone one) is Trinity College
Dublin..."

The subject of precision time distribution across the Internet arose
in newsgroup sci.astro about a month ago. Here is a relevant followup
from that discussion:
> Newsgroups: sci.astro
> Organization: British Telecommunications plc
> From: jcs@zoo.bt.co.uk (John C Sager)
> Subject: Re: Universal time
> Date: 23 Dec 92 10:47:46 GMT
> 
> In article <DWELLS.92Dec17184737@fits.cv.nrao.edu>, dwells@fits.cv.nrao.edu
> (Don Wells) writes:
> 
> [...]
> 
> > Precision distribution of time across the Internet has been an
> > operational reality for several years, using NTP [Network Time
> > Protocol]. Master ("stratum 1") servers exist in (all?) regional nets
> > of the NSFnet and in most regional nets worldwide, probably including
> > the UK.
> 
> There are several NTP time servers operating in the UK at stratum 1, ie
> they derive their time from an external high-accuracy source. My
> own machine, bear.zoo.bt.co.uk (132.146.40.28), does this normally, taking
> its time reference from a GPS receiver. Its system clock is rarely
> more than 50 microseconds away from UTC, and one ought to be able to
> maintain millisecond accuracy from it in the UK running the latest
> version of xntp3 from louie.udel.edu.
> At this time, and over the Christmas period, my server is at stratum 2
> as I am evaluating the navigation performance of the GPS receiver in my car.
> It will be back to full accuracy in early January 1993.
> 
> 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


--

Donald C. Wells             Associate Scientist        dwells@nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N
From: ajudge@maths.tcd.ie (Alan Judge)
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP3/MIPS RISCos 5.01 solved (ish)
Date: 25 Jan 93 10:22:12 GMT
Distribution: inet
Organization: The Internet


Mills> Would you like to update the xntp3 distribution with either/both README
Mills> and patches? If so, please send to me and I will energize files.

The only patch involved is the one that Philip Gladstone sent me.  He
says that he sent it in to you as well (SETTIMEOFDAY_DAMAGED).  If you
want, I can generate a README about my experiences with RISC/os 5.  I
can generate one now, but it will only be valid for my experiences
with a MIPS R4000 machine.  If you are willing to wait a few weeks, I
will have upgraded our R3000 machines as well, and can give info on
what happened there (and give a source patch for the kernel).

In any case, I'd like to wait a few days, as I am having some odd
stepping problems with ntp on the R4000.  I enclose a bit of a log
below.  Any hints on what I should look at?  To me, it looks like the
system clock is just jumping or something.

Incidentally, could you tell me what units the compliance is measured in.
--
Alan
Jan 25 02:56:27 hamilton xntpd.riscos5[255]: offset -0.031991 freq 13.18306 comp 2
Jan 25 03:56:27 hamilton xntpd.riscos5[255]: offset -0.028834 freq 12.82216 comp 2
Jan 25 04:56:27 hamilton xntpd.riscos5[255]: offset -0.034151 freq 12.40161 comp 2
Jan 25 05:56:26 hamilton xntpd.riscos5[255]: offset -0.033507 freq 12.01387 comp 2
Jan 25 05:57:28 hamilton xntpd.riscos5[255]: adjust: STEP dropped (134.226.32.17 offset 0.465565920)
Jan 25 06:06:00 hamilton xntpd.riscos5[255]: adjust: STEP dropped (134.226.32.17 offset 0.976336360)
Jan 25 06:10:16 hamilton xntpd.riscos5[255]: adjust: STEP 134.226.32.17 offset 0.975142002
Jan 25 06:10:16 hamilton xntpd.riscos5[255]: system event 5 status c0f3
Jan 25 06:10:39 hamilton xntpd.riscos5[255]: peer 134.226.1.24 event 84 status 9084
Jan 25 06:10:39 hamilton xntpd.riscos5[255]: system event 4 status c6f5
Jan 25 06:10:48 hamilton xntpd.riscos5[255]: peer 134.226.81.11 event 84 status 9084
Jan 25 06:11:03 hamilton xntpd.riscos5[255]: peer 134.226.32.17 event 84 status 9084
Jan 25 06:16:08 hamilton xntpd.riscos5[255]: system event 3 status 6f4
Jan 25 06:56:26 hamilton xntpd.riscos5[255]: offset -0.029797 freq 11.81857 comp 2
Jan 25 07:56:26 hamilton xntpd.riscos5[255]: offset -0.030590 freq 11.45856 comp 2
Jan 25 08:56:26 hamilton xntpd.riscos5[255]: offset -0.014349 freq 11.15582 comp 2
Newsgroups: comp.protocols.time.ntp
Subject: problem accessing time servers with xntp v3
From: ral@cerc.wvu.wvnet.edu (Rebecca A. Littleton)
Date: Wed, 27 Jan 1993 22:08:41 GMT
Organization: Concurrent Engineering Research Center

	I have an Ultrix machine I've configured as a stratum 3
time server syncing off the following stratum 2 machines:
128.46.129.82   molecules.ecn.purdue.edn # Purdue University
192.35.82.50    ntp0.cornell.edu         # Cornell University
192.80.214.42   fuzz.sura.net            # SURA Consortium, College Park, MD
128.118.25.3    clock.psu.edu            # Penn State University
128.194.3.100   falcon.tamu.edu          #Texas A&M Academic Computing Services
192.5.146.42    fuzz.psc.edu             # PSC Supercomputer Center
128.175.1.3     louie.udel.edu           # University of Delaware
I've used the NTP version 1 that's bundled in the Ultrix 4.2 OS for the
past 2 years.  It serves 60+ workstations in my LAN.
	Today I installed xntp version 3 on this machine and I'm
unable to sync off of any of these servers except for louie.udel.edu.
Why?  
	Here's my ntp.conf file:
peer		fuzz.sura.net
peer		ntp0.cornell.edu
peer		louie.udel.edu
peer		fuzz.psc.edu
driftfile       /usr/xntp3/ntp.drift  

	Here's an output from xntpdc
xntpdc> peers
     remote           local      st poll reach  delay   offset   disp
======================================================================
+ntp0.cornell.ed 0.0.0.0         16 1024    0  0.0000  0.000000 16.000
*louie.udel.edu  129.71.14.1      2  128  377  0.0390  0.025507 0.0168
+fuzz.psc.edu    0.0.0.0         16 1024    0  0.0000  0.000000 16.000
+fuzz.sura.net   0.0.0.0         16 1024    0  0.0000  0.000000 16.000

	I appreciate your help.  You can respond to this newsgroup
or to my e-mail:  ral@cerc.wvu.wvnet.edu.  Thanks.

Rebecca Littleton
Systems Admin
West Virginia University
Morgantown WV 26506


Newsgroups: comp.protocols.time.ntp
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Re: XNTP3/MIPS RISCos 5.01 solved (ish)
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Distribution: inet
Date: Wed, 27 Jan 1993 09:40:21 GMT

ajudge@maths.tcd.ie (Alan Judge) writes:

>However, the primary problem turned out to be the MIPS kernel.  All
>MIPS workstations have time of day chips, and it seems that the kernel
>intermittently checks this clock and adjusts the CPU clock accordingly
>(both by using an internal adjtime(), and by changing the basic speed
>of the CPU clock causing the "Adjust CLOCK Hz" messages in syslog).
>Obviously, this has bad interactions with the correct operation of
>NTP, which is doing something similar based on NTP clocks outside.
>Each time the kernel does this, NTP has a fit.

>It seems from the code that this has always been done, even on R3000
>machines and in RISCos 4.51, so NTP has always been a bit funny

>There is no MIPS-provided way to turn this off (like Sun's
>dosynctodr).  However, MIPS do provide source code for all their
>drivers with RISCos, so it is a fairly simple patch on most MIPS boxes

I've run xntp3 on CDC's EPIX 1.4.3 on R3000 and R6000 boxes. EPIX 1.4.3
is based on RISCos 4.52. Under EPIX 1.4.3 its just the same, we always
got the funny "Adjust CLOCK Hz" messages as well as "Previous time adjustment
didn't complete messages". I've now disabled the verify_time 
code in /usr/reconfig/io/todc_r{3030,6000}.c, and gee xntp runs more stable
now. No more didn't complete messages, and very good synchronization
to our stratum 1.

Before I had offset's in the 5-15 msec range, now i get offsets in the
0.1-2 msec range!!!!! (On a CD4320, aka RC3230.)

That's great !

>I have put in a request for an easier way to disable the clock syncing.
I will put in a similar request to CDC.

Sincerely,
Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
Newsgroups: comp.protocols.time.ntp
From: fw@world.std.com (forrest d whitcher)
Subject: time regulation (FAQ?)
Summary: time regulation if not inter-net connected
Keywords: timed nbstime
Organization: The World Public Access UNIX, Brookline, MA
Distribution: us
Date: Thu, 21 Jan 1993 16:03:52 GMT

My apologies if this is indeed an FAQ, I need to access a valid
time source for a network of tcp/ip pc's served by unix and os/2
systems. The pc's sync their time off of the server using timed.
I am looking for a method to keep the server in tune with UTC. I
have found nbstime, which is fine for the pc, looking for comparable
technique to run on rs/6000, trying to avoid porting pc source to
unix. Thanks in advance, forrest.

reply on e-mail		fw@world.std.com

Forrest Whitcher          Boston Scientific Corp. (617) 972-4289
From: thorinn@DIKU.DK
Newsgroups: comp.protocols.time.ntp
Subject: XNTP3/MIPS RISCos 5.01 solved (ish)
Date: 25 Jan 93 11:39:40 GMT
Distribution: inet
Organization: The Internet

Alan,

from your log it looks like the system time jumped one second backward
in the minute after 05:56:26. Perhaps the SETTIMEOFDAY_DAMAGED patch
does not always guess correctly to which side RISC/os 5 is going to
jump?

The compliance is not really the compliance any more --- it is log2 of
the loop time constant in seconds. The actual value, as a time
interval, may have some significance in phase locked loop theory, but
in the NTP loop filter it is just a number that is used to scale
certain other numbers --- the larger the time constant, the
``stiffer'' the loop, and the longer the poll interval.

The compliance used to be another quantity with a dimension of time, a
long-term decaying average of the loop offset, scaled to ``the same''
units as the loop time constant which it was used to derive. (Smaller
compliance => larger loop time constant.)

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
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: Thu, 21 Jan 1993 11:58:12 GMT

In article <gray.727547744@cary.lkg.dec.com>, gray@cary.lkg.dec.com (Cary Gray) writes:
...
|> I'm not in a position to do any cross byte-order testing; so I'm unable to
|> test Martyn's patches for v3.  I can supply the old patches to someone who
|> is willing to interpret, test all the combos of byte order, and forward to
|> Dave.

I am in principle both able and willing to do this again for v3, but
cannot afford to take the time to do it right now. If it hasn't been
done by the time I get round to a v3 campaign, I will certainly do it
then.

-- 
Martyn Johnson      maj@cl.cam.ac.uk
University of Cambridge Computer Lab
Cambridge UK
From: paul@kuhub.cc.ukans.edu
Newsgroups: comp.protocols.time.ntp
Subject: ukans.edu NTP servers addresses change
Date: 28 Jan 93 08:09:04 CST
Organization: University of Kansas Academic Computing Services

To those of you who use the strat 2 NTP servers at ukans.edu by
address instead of by name:

Our servers' IP address are changing

kuhub.cc.ukans.edu will change to IP address 129.237.32.1
lane.cc.ukans.edu will change to IP address 129.237.32.2

The old addresses

kuhub.cc.ukans.edu - 129.237.1.10
lane.cc.ukans.edu - 129.237.1.31

You can make the changes at any time, as both hosts are responding to
both of their addresses.

The old addresses will be removed at the end of May.

Changes to clock.txt will be sent, shortly.
Newsgroups: comp.protocols.time.ntp
From: peppe@ipgaix.unipg.it (G. Vitillaro)
Subject: 3 stratum 1 ntp servers needed
Summary: We need to contact 3 stratum 1 ntp servers.
Keywords: ntp, stratum 1, Italy
Organization: Universita' di Perugia
Date: Thu, 28 Jan 1993 17:59:06 GMT

Following the suggestion in the xntp 3 documentation,
we would like to establish a permanent connection with
3 stratum 1 ntp (possible version 3) servers near (from
the network dealy point of view) to us.

We will use them from 3 differents machines (becoming
stratum 2): one AIX 3.1, one AIX 3.2 and one AIX/370 1.2.1 to
sync our (growing) network.

The 3 servers will be peers each one to the other two.

Please contact me sendind address of the servers and
permission at <peppe@ipgaix.unipg.it>.

We are currently using only one stratum 2 server in Swiss,
but I would like in any case to follow the author documentation.

Thank in advance for any help,   Regards   G. Vitillaro
-- 
Giuseppe Vitillaro - IBM SEMEA      |  E-Mail : peppe@ipgaix.unipg.it 
University of Perugia Italy         |  06100 Perugia  Phone:+39.75.585-2200
---------------------------------------------------------------------------
All comments/opinions are mine and don't represent those of IBM