HDTenEightyP/NetNews huggingface dataset:
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: NFS / RFS performance ???
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 9 Sep 1992 03:51:04 GMT

In article <1992Sep8.192211.8020@vector.dallas.tx.us>, tbo@vector.dallas.tx.us (Terry Bohaning) writes:
> 
> Does anyone have any experience with Sun RFS and NFS. 
> 
> We're currently using NFS in a major way, but have learned the hard way
> what an "Unreliable Transport" that UDP is. From Sun's documentation it
> appears that RFS is TCP based, but it really doesn't give me any idea
> of the performance characteristics of the protocols. Can anyone give me
> a comparison of the NFS vs RFS.
> 
> I'm trying to work around the current nightmare that we have. Most of
> our user's have quit using NFS as it is so unreliable. In order to get
> enough speed, we need to run with a frame size of 8k. For reliability,
> OTOH, we need to set the frame size between 1-2k. This means that we take
> a hugh hit in performance to get a reliable transport.
> 
> Will RFS give us a reasonably fast, reliable transport mechanism???


Changing the packet size to 1K does not affect the reliability of
NFS on competently designed and implemented NFS servers and clients.
It will reduce performance somewhat.

One needs small UDP packets only if:
    -using cheap (not necessarily inexpensive) ethernet hardware
	or operating systems on clients or servers that cannot handle
	several back-to-back ethernet packets.

    -using broken routers or bridges.

    -you have a badly broken ethernet, which loses a significant
	fraction (>= 1%) of its packets.

Any of these situations will terrible things to any network protocol,
albeit NFS is particularly vulnerable.


Please note that NFS can be made entirely reliable, although
arbitrarily slow, by using "hard mounts," even in such broken
environments.

Perhaps the most common NFS configuration error is to use soft mounts
inappropriately (i.e. where reliability matters, such as on writable
file systems).


Vernon Schryver,  vjs@sgi.com

P.S. The "Distribution: usa" line in your article may have reduced
   the number of people who saw it.
From: costello@eplrx7.es.duPont.com (Tim Costello)
Newsgroups: comp.protocols.nfs
Subject: Re: PC-NFS Browse & Mount
Date: 10 Sep 92 14:01:49 GMT
Organization: DuPont Engineering Physics Laboratory

From article <18lb4kINNrfv@seven-up.East.Sun.COM>, by kstout@medieval.East.Sun.COM (Kate Stout - Sun PC Network Engineering):
> There was an inquiry last week about Browsing and Mounting 
> Filesystems using PC-NFS 4.0 with Windows.

	I asked the question.
> 
> The concern raised was why you can't connect  all of the file systems
> that you can see when you browse the server.
> 
> The answer is fairly simple - Browsing shows all of the exported
> filesystems available on a server, regardless of permissions and status.
> (For example, it is possible to have a filesytem exported that no
> longer exists.)
> 
> When you attempt to connect, checking is done for a variety of things,
> such as whether you have permissions to mount the file system, whether
> it exists, etc. 

	I knew that, it was part of the question.  The filesystem I'd like
to mount is on a Sun geographically and has different UID, GID settings, so
that the authentication done by a local SUN running pcnfsd doesn't count for
anything.

> 
> So it is possible to have a mismatch between what you have rights for
> and what is shown, or what the server claims to have, and what is 
> actually there.

	I want the mount attempt to ASK for username/password as applied to
the remote file system.  Or can I turn authentication off altogether and be
asked for username/password for each file system to be mounted.

> 
> Hope that helps - Kate
> ------------------------------------------------------------------------------
> --    Kate Stout, PC-NFS Engineer       | There are two kinds of people	 --
> --    Sun Microsystems, Billerica MA.   | in the world; those who divide -- 		                 --    (kstout@East.Sun.COM)             | the world into two kinds....   --
> 

-- 
Tim Costello
Du Pont Merck Pharmaceutical
costello@eplrx7.es.dupont.com
From: dale@manet.wustl.edu (Dale Frye)
Newsgroups: comp.protocols.nfs
Subject: Re: Memory usage of NFS daemon bwnfsd
Date: 8 Sep 92 15:11:12 GMT
Reply-To: dale@manet.wustl.edu
Organization: Washington University, School of Engineering, St. Louis MO

In article <1992Sep5.144415.15875@maccs.dcss.mcmaster.ca>  
fred@maccs.dcss.mcmaster.ca (Fred Whiteside) writes:
> 	again, true.  actually, i have a new, improved version of the
> daemon just about ready to go.  lots of new features to support our
> imminent release of version 3.0 and the windows goodies, plus many
> enhancements from the net as well as bug fixes (printout banner problem
> is now *finally* sorted out).  it would likely be a good idea to get
> this if you are using the old daemon.
> 
> 	any suggestions about distribution? i hesitate to post it here,
> as that would seem to be extraordinarily bad manners. alt.sources?
> we are not currently set up to provide anonymous ftp, but i certainly
> have no aversion to others providing that ...
> 
> 	comments, people?
> 
> -fred whiteside
>  Beame & Whiteside Software, Ltd.

Fred,
 How about posting it to SIMTEL and/or wuarchive?  Comments anyone?

Dale Frye
Washington University in St. Louis
Newsgroups: comp.protocols.nfs
From: tmurphy@convex.com (Tom Murphy)
Subject: packet disassembler
Summary: Need packet disassembler
Keywords: nfs
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Mon, 14 Sep 1992 18:16:06 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

I am using "etherfind" for debugging of NFS problems.  It does fine
on giving me the header information on NFS packets, but I would
like the complete packet disassembled.   Are there any PD packets
that can read the hex output from etherfind and give a full break down
of the packet?

Thanks


--
================================================================================
Tom Murphy - tmurphy@convex.com       |  I am sorry I forgot.  I do have a
CONVEX System Integration and Support |  photographic memory, but I ran
Product Specialist                    |  out of film 8-)
Newsgroups: comp.protocols.nfs
From: nagel@Cigna.COM (Mark Nagel)
Subject: Re: Pcnfs 4.0 and Telnet
Organization: CIGNA FIRST, Irvine, CA
Date: Tue, 8 Sep 1992 19:04:16 GMT

In <18hbqhINNni@huon.itd.adelaide.edu.au> george@ache.mad.adelaide.edu.au (George Travan) writes:

>I have an application that runs on a SUN that uses line drawings/highlighting all
>sorts of things. Hence I am having a problem with the telnet distributed with
>pcnfs. 
>I get a row of 'qqqqqqqqqqqqqqqqqqqqqqq' for horizontal lines abd 'x' for vertical 
>lines  within telnet. This looks gross...
>Can telnet  handle line drawings such as this??? Anyone??

We have the same sort of application.  All of our terminals need to
be VT-220 compatible to get the lines and the telnet that comes with
PC-NFS is only VT-100 compatible.  Advanced Telnet is VT-220
compatible, but also has problems, especially under Windows.  I have
had all our users just exit Windows before using AT and it works
sufficiently well for them to perform their tasks.

It might be possible to use a PD package that has PC-NFS support to
achieve the same thing.  MS-Kermit has VT-220 emulation, but it does
not support PC-NFS (there are arcane ways of making it sort-of work,
though).

Mark
-- 
Mark Nagel <nagel@cigna.com>	| DISCLAIMER: Any resemblence of these
Network Administrator		| opinions to those of CIGNA are purely
CIGNA/FIRST			| coincidental.
          (Don't start vast projects with half-vast ideas)
Newsgroups: comp.protocols.time.ntp
From: kdenning@portal.hq.videocart.com (Karl Denninger)
Subject: Sun 4m / Xntp3 - problems
Organization: VideOcart Inc.
Date: Tue, 15 Sep 1992 19:17:48 GMT

We're running into some strange behavior with SunOS 4.1.2 and XNTP3.

We have an Intel SVR4 machine which runs stratum 2 most of time; this
provides time service to our internal network here.  It is operating
properly with xntp2.  No problems there that I can see.

However, our Sun machines, which are running Xntp3, will often report 
"Previous time adjustment failed to complete" on the console.  They're right
too - they continue to drift over time until they get a little more than
second out of whack, at which time they are forcefully reset (or so it
appears) by xntpd.

Therefore, it would appear that the "adjtime()" call isn't doing anything!

Has anyone seen this and does anyone have suggestions on where to look?

(BTW, both the Suns and RS/6000s have lousy clocks.  Our Intel V.4 machine
is much better; about 0.2 seconds a day.  The Suns and RS/6000s both drift
more than 4-5 seconds each if left unchecked.)

--
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022
From: chicken@npac.syr.edu (Mark R. Levinson)
Newsgroups: comp.protocols.time.ntp
Subject: Setting the time when the system boots
Date: 3 Sep 92 16:04:16 GMT
Organization: NPAC, Syracuse University - Syracuse, New York


	I'm interested in hearing how people running NTP on Unix systems set
the time when the system boots. Do you use ntp in your /etc/rc file? Or do
you use rdate instead and let NTP compensate for any initial inaccuracy
later? Anyone have any pros or cons one way or the other?

--
Mark R. Levinson
Northeast Parallel Architectures Center
Syracuse University
From: glenn@SUNDECK.USASK.CA
Newsgroups: comp.protocols.time.ntp
Subject: Re: Minor bug in GOES support (xntpd v3)
Date: 15 Sep 92 22:01:07 GMT
Distribution: inet
Organization: The Internet

>Looks like someone transposed a few letters (the code didn't even
>compile).  I don't know if this means that the GOES support is
>likely to not work; I haven't had a chance to wire it up yet.

! 	goes->lastrec = rbufp->recv_time;


As the instigator, I should speak to this.  I have never run the
GOES code without CLKDISC support.  If you are using CLKLDISC, be
sure to define -DCLKDISC where you would put -DSTREAM in the Config
file.  If not, things will run in raw mode (or STREAM if -DSTREAM).

The streams code handling is supposed to be the same as used in wwvb
driver with modifications for the timestamp form and additions for
CLKLDISC.  It looks like I made a typo when moving this line from
one spot to another during modification.  Oops.  It should work with
correction though.

Glenn Hollinger
University of Saskatchewan.
From: shibumi@joes.garage.com (Kenton A. Hoover)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Trimble & Rockwell GPS Receivers
Date: 15 Sep 92 07:06:00 GMT
Reply-To: shibumi@joes.garage.com
Organization: Joe's Garage, San Francisco, KA

jcs@zoo.bt.co.uk (John C Sager) writes:
[lots of interesting stuff about all the new six channel GPS units]

Well, this is rather interesting.  Trimbal, Motorola and Rockwell come out
with small six-channel units for the automotive market within a few months of
each other.  Anyone tell me which new ASIC or two-chip hybrid for GPS I 
missed in the news?

| 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===============|
| Delores breezed along the surface of her life like a flat stone forever     |
| skipping along smooth water, rippling reality sporadically but oblivious to |
| it consistently, until she finally lost momentum, sank, and due to an over- |
| dose of flouride as a child which caused her to suffer from chronic apathy, |
| doomed herself to lie forever on the floor of her life as useless as an     |
| appendix and as lonely as a five-hundred pound barbell in a steroid-free    |
| fitness center.                                                             |
|                -- Winning sentence, 1990 Bulwer-Lytton bad fiction contest. |
From: srp@babar.mmwb.ucsf.edu (Scott R. Presnell)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time synchronization on lots of SGI Indigos
Date: 11 Sep 92 03:46:55 GMT
Organization: UCSF Computer Graphics Lab

paulr@umbc4.umbc.edu (Paul Riddle) writes:

>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).

>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.

I ported and use ntpd (without the "x") on a set of about 12 PI's. I hacked
up ntpd on our iri to accept the "tickadj" var, multiply by 1000 and use it
to set timetrim via the syssgi() function and SGI_SETTIMETRIM (there is
also a SGI_GETTIMETRIM). Tickadj is in uS/S, timetrim is in nS/S.  I've
been using a value of about -400000 nS/S (so tickadj = -400) for our
4D/20's and a 25: the logical clock stays synced with that, and -4000 nS/S
(so tickadj = -4) for the 35's.  timetrim is a signed long.

Check babar.mmwb.ucsf.edu [128.218.21.42] in ~ftp/pub/ntpd.patch for the
patch and the Makefile.

	- Scott Presnell (srp@cgl.ucsf.edu)

-- 
Scott Presnell				        +1 (415) 476-9890
Pharmaceutical Chemistry, S-926			srp@cgl.ucsf.edu
University of California
San Francisco, CA 94143-0446
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  Minor bug in GOES support (xntpd v3)
Date: 15 Sep 92 23:54:02 GMT
Distribution: inet
Organization: The Internet

Glenn,

I have fixed the source tree. As an underground creature with its tail
in the air, said tree will be replanted on louie next morn.

Dave
Newsgroups: comp.protocols.time.ntp
From: ggm@brolga.cc.uq.oz.au (George Michaelson)
Subject: Re: Export update
Organization: Prentice Centre, University of Queensland
Distribution: inet
Date: Mon, 14 Sep 1992 22:54:14 GMT


brolga.cc.uq.oz.au:/net.sources/authdes.c.Z

This is Eric Youngs exportable DES implementation, re-re-bludgeoned
by the author to suit this context.

Totally un-encumbered by US export restrictions.

comments/bugs and applause to eay@psych.psy.uq.oz.au

	-George
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht
Newsgroups: comp.protocols.time.ntp
From: glenn@herald.usask.ca (Glenn Hollinger)
Subject: Motorola GPS Receiver
Originator: glenn@herald.usask.ca
Organization: University of Saskatchewan
Date: Wed, 9 Sep 1992 18:00:46 GMT

The new Motorola GPS Receiver has been mentioned a couple of times here.
I just got a copy of the technical reference manual for this box and
will offer a few notes about it.

1) The unit is a nice piece of work.  A 4 inch diameter 1 inch thick
antenna disk and a 4x3x1 inch system box powered by 12 or 5 volts.

2) The ascii timestamps have a variable delay from 0 to 50 milliseconds.
This is not very good, but see point 3.

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.

4) The box will speak Motorola binary code (complex), NMEA code, and
do LORAN emulation.

Sounds great!

Glenn Hollinger,                     glenn@herald.usask.ca
University of Saskatchewan.          +1-306-966-4827
From: mogul@PA.DEC.COM (Jeffrey Mogul)
Newsgroups: comp.protocols.time.ntp
Subject: Minor bug in GOES support (xntpd v3)
Date: 15 Sep 92 20:55:29 GMT
Distribution: inet
Organization: The Internet

Looks like someone transposed a few letters (the code didn't even
compile).  I don't know if this means that the GOES support is
likely to not work; I haven't had a chance to wire it up yet.

*** 1.1	1992/09/11 23:28:44
--- refclock_goes.c	1992/09/11 23:48:45
***************
*** 469,475 ****
  	if (goes->lencode == 0) return;
  	tstmp = goes->lastrec;
  #ifndef CLKDISC
! 	goes->lastrec = rbufp->rec_vtime;
  #endif
  
  #ifdef DEBUG
--- 469,475 ----
  	if (goes->lencode == 0) return;
  	tstmp = goes->lastrec;
  #ifndef CLKDISC
! 	goes->lastrec = rbufp->recv_time;
  #endif
  
  #ifdef DEBUG

-Jeff
From: cyrus@convex.com (Tait Cyrus)
Newsgroups: comp.protocols.time.ntp
Subject: xntp vs xntp3
Date: 16 Sep 92 01:10:32 GMT
Organization: Engineering, CONVEX Computer Corp., Colorado Springs, CO., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

I have been running xntp for almost 2 years on our Convex and Dec machines.
Today I obtained xntp3 and compiled and installed on our Convex (set up as
a local time server even though it doesn't actually have a real clock).
Unfortunately all other machines, still running the 2 year old xntp
now can't talk to the new xntp3 time server.  

I used the same /etc/ntp.conf file [maybe that is part of my problem].  xntp3
started up just fine and xntpdc[3] ran ok with the local machine.  In xntpdc
if I set host to an old xntp machine, I got a:
	localhost: timed out, nothing received
	***Request timed out
So both xntp3 can't talk to old xntp machines and old xntp machines can't talk
to xntp3.

Any suggestions/ideas?  I can't see anything in the doc/man pages which talks
about potential problems.

Thanks

-- 
W. Tait Cyrus                   Software Engineer
Convex Computer Corporation     cyrus@convex.com
2075 Research Parkway Suite B   719-594-4900 ext 41
Colorado Springs, CO 80920
From: wales@CS.UCLA.EDU (Rich Wales)
Newsgroups: comp.protocols.time.ntp
Subject: IP address change for ntp2.cs.ucla.edu
Date: 11 Sep 92 22:12:42 GMT
Distribution: inet
Organization: The Internet

One of the UCLA CS Department's stratum-2 tickers -- ntp2.cs.ucla.edu
(formerly known as gw2.cs.ucla.edu) -- will be changing its IP address
next Tuesday (9/15) from 131.179.128.3 to 131.179.128.5.

If you are using this host as an NTP server, please change its address
in your configuration file to 131.179.128.5 on Tuesday (9/15).  Expect
some temporary disruption of service during the day as the machine is
rebooted with its new address.

Our other NTP server (ntp1.cs.ucla.edu, formerly called gw1.cs.ucla.edu)
will keep its current IP address of 131.179.128.2.

We're installing a new Wellfleet packet router here, and the "powers
that be" decided that the new router should take over the IP address of
one of the old RT routers (which have been doubling as NTP servers).
The new router, unfortunately, doesn't speak NTP.  I tried =really= hard
to keep both RT's on their current addresses, but without success.

Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (310) 825-5683
From: scotth@hoshi.corp.sgi.com (Scott Henry)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time synchronization on lots of SGI Indigos
Date: 11 Sep 92 14:28:26 GMT
Organization: Silicon Graphics Inc, Mountain View, CA


>>>>> In article <1992Sep10.233120.22639@umbc3.umbc.edu>, paulr@umbc4.umbc.edu (Paul Riddle) writes:


paulr> I would like to use xntpd for time synchronization on several labs of
paulr> SGI Indigos.  There are a total of 115 machines.  I have built and
paulr> tested xntpd successfully, but it doesn't include kernel support for
paulr> setting tickadj on the Indigo.  I have tried tweaking tickadj by hand,
paulr> but no matter what I do it generates large volumes of syslog messages
paulr> saying that it is stepping the clock backwards (one every couple of
paulr> minutes).
...
paulr> So, my basic question is:  has anyone gotten xntpd to work well on an
paulr> Indigo?  If so, how did you do it?

I've ported xntp to the IRIS, and have made patches and a tar file of
binaries available for anonymous FTP from sgigate.sgi.com
(192.82.208.1) in the directory ~ftp/net-services/xntp. It is being
used extensively (though far from universally) within SGI for time
synchronization.

obligatory disclaimer: placing this software out for anonymous FTP
does not in any way imply official support, blah, blah, blah. However,
I'm interested in any bugs or problems you may find to improve the port.

=-=-=-=
--
 Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings
 Networking Services,        / Help! My disclaimer is missing!
 Silicon Graphics, Inc      / GIGO *really* means: Garbage in, Gospel Out
Newsgroups: comp.protocols.time.ntp
From: kardel@darkstar.informatik.uni-erlangen.de (Frank Kardel)
Subject: Re: XNTP3 on SVR4 (DELL Intel release)
Organization: CSD., University of Erlangen
Date: Thu, 10 Sep 1992 08:00:33 GMT

kdenning@portal.hq.videocart.com (Karl Denninger) writes:

>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?

Main point, besides ordinarily porting issues, is to convince xntp3
that settimeofday() probably calls stime() (don't know for Dell)
to set the clock (-> second resolution). This behaviour is at
least documented for Solaris 2.0 (SysVR4 for Suns).

Aren't "leading operating system technology standards" nice ?

With stime() and second clock resolution you seldom get
within 128ms of the "actual" time. xntp3 does clock slewing once
it gets within 128ms of the "actual" time.

It might be configurable, but ask Dave what breaks when setting
CLOCK_MAX_F to 0.5 secs.

The Sun documentation has a cute way of telling you how to cope
with the inferior stime() kernel interface:

Quoted from Sun's Manual:

...
     The implementation of  settimeofday()  ignores  the  tv_usec
     field  of  tp.  If the time needs to be set with better than
     one second accuracy, call settimeofday() for the seconds and
     then adjtime() for finer accuracy.
...

Yuck!

I don't know whether this behaviour is common to all SysVR4 or only
a feature of the advanced SunOS Operating System Technology.

--
	   Frank Kardel (kardel@informatik.uni-erlangen.de)
    All SCSI disks will from now on be required to send an email
         notice 24 hours prior to complete hardware failure!
From: stewart@ra.cis.udel.edu (John Stewart)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Setting the time when the system boots
Date: 5 Sep 92 19:57:17 GMT
Organization: University of Delaware

In article <chicken.715535488@npac.syr.edu> chicken@npac.syr.edu (Mark R. Levinson) writes:
>	I'm interested in hearing how people running NTP on Unix systems set
>the time when the system boots. Do you use ntp in your /etc/rc file? Or do
>you use rdate instead and let NTP compensate for any initial inaccuracy
>later? Anyone have any pros or cons one way or the other?

I believe that, for people using the xntp [or xntpv3] implementation of the
protocol, a common thing to do in /etc/rc.local (or wherever) is:

	if [ -f /usr/local/bin/tickadj ]; then
		/usr/local/bin/tickadj -s
	fi

	if [ -f /usr/local/bin/ntpdate ]; then
		/usr/local/bin/ntpdate time_server
	fi

	if [ -f /usr/local/bin/xntpd ]; then
		/usr/local/bin/xntpd
	fi

This does an initial sync so that the xntpd will successfully start.  After
this point, the xntpd will take care of keeping the clock in sync.

Hope this helps.

/jws
Newsgroups: comp.protocols.time.ntp