HDTenEightyP/NetNews huggingface dataset:
From: dale@manet.wustl.edu (Dale Frye)
Subject: Re: PC-NFS & MS-DOS ASSIGN
Reply-To: dale@manet.wustl.edu
Organization: Washington University, School of Engineering, St. Louis MO
Date: Tue, 8 Sep 1992 15:15:48 GMT

In article <1992Sep08.100204.27562@bas-a.bcc.ac.uk> ccaajmf@ucl.ac.uk  
(John Franks) writes:
> I'm having trouble with PC-NFS crashing my computer if I even run the  
"assign"
> command. This wouldn't be a problem (use subst) except that I have to  
have
> a partitioned hard disk, taking C: and D:, but for historical reasons, I  
want
> to have D: mounted over PC-NFS and probably E: redirected to the real  
D:. 
> 	I can do the second half, but without ASSIGN I can't get D: to be  
a 
> PC-NFS mounted drive. 
> 
> 	So, I'm after any ideas on getting around this, or avoiding the  
problem
> with "assign". 
> 
> 	Help . . .
> 
> P.S. Yes, I've tried every combination of join/subst I can think of. No  
luck.

Both ASSIGN and SUBST will not work with networked drives (I wish it  
would!) Blame Microsoft. It's documented in the DOS 5.0 manual.
PC-NFS used to provide its own remapping command but I've heard that they
took it out. (Is this true??)

Dale Frye
Washington University in St. Louis
From: douglas@rhi.hi.is (Douglas Brotchie)
Newsgroups: comp.protocols.nfs
Subject: Re: What are the advantages and disadvantages of B+Wnfs vs SunPCNFS?
Keywords: PC-Email, PC-NFS, HP server
Date: 11 Sep 92 15:22:21 GMT

In <BuE6Gr.J69@ddsw1.mcs.com> karl@ddsw1.mcs.com (Karl Denninger) writes:

>In article <1992Sep4.165323.2674@awdprime.austin.ibm.com>
 curt@ekhadafi.austin.ibm.com
 (Curt Finch 903 2F021 curt@aixwiz.austin.ibm.com 512-838-2806) writes:
>>What are the advantages and disadvantages of B+W NFS vs SunPCNFS?
>>[...]

>From someone who has used both (current B&W, Sun PCNFS about a year back):
> [...]
>o)	Support.  B&W hasn't let me down yet; then again, you rarely need
>	to call them.  [...]

Alas, not my experience.
We tried an evaluation of BW-NFS in July.
Sent a technical query by fax 23rd. July.  No reply.
I sent email message 29th. July.   No reply.
I sent a final fax 6th. August, including the final sentence: "If I do not
receive a reply to this fax, I will have no further dealings or communications
with your company."    No reply.

I cannot comprehend, and will not do business with, a company that ignores
three enquiries from a prospect.

Douglas Brotchie
University of Iceland
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip
From: avalon@coombs.anu.edu.au (Darren Reed)
Subject: Re: NFS Over Satellite Link
Organization: Computer Services Centre, Australian National University
Date: 12 Sep 92 18:09:06 GMT

pahountis@ncf.al.alcoa.com (Julia Pahountis) writes:

>Has anyone, or do you know of anyone, who has done NFS over a satellite link?  (Can it be done?)
>I would appreciate any information on how it was accomplished and what
>kind of problems were
>encountered.

Well Australia is connected to the USA via a fairly fast satellite link
(512kbit/s) and I've never seen any problems when using an NFS disk
mounted from the USA.

How was it done ?

# mount wuarchive.wustle.edu:/archive/mirrors /mirror

Was much easier than having ftp running (although slower too).

Darren.
From: kstout@medieval.East.Sun.COM (Kate Stout - Sun PC Network Engineering)
Newsgroups: comp.protocols.nfs
Subject: PC-NFS Browse & Mount
Date: 9 Sep 1992 17:09:40 GMT
Organization: Sun Microsystems Inc. - BDC
Reply-To: kstout@medieval.UUCP ()
NNTP-Posting-Host: medieval.east.sun.com

There was an inquiry last week about Browsing and Mounting 
Filesystems using PC-NFS 4.0 with Windows.

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. 

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.

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....   --
From: tbo@vector.dallas.tx.us (Terry Bohaning)
Newsgroups: comp.protocols.nfs
Subject: NFS / RFS performance ???
Date: 8 Sep 92 19:22:11 GMT
Distribution: usa
Organization: Dallas Semiconductor

Hi All,

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

Thanks,

Terry Bohaning			tbo@vector.dallas.tx.us
Systems Administrator		Dallas Semiconductor Inc.
Newsgroups: comp.protocols.nfs
From: uresh@ovrbid.lkg.dec.com (Uresh Vahalia)
Subject: Re: RPC version 3?
Organization: Digital Equipment Corp.
Date: Fri, 11 Sep 1992 20:37:13 GMT

>You might be looking at the portmap protocol which rev'ed to version 3
in SVR4 and version 4
>in Solaris 2.0.

Yes.  That is what I meant.  Where can I find specs foe these versions?


Uresh Vahalia
Xref: sparky comp.protocols.nfs:2289 comp.protocols.tcp-ip.ibmpc:5164 comp.dcom.lans.ethernet:1874
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Date: 10 Sep 92 16:05:59 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <karl.23.716089551@empirical.com>, karl@empirical.com (Karl Auerbach) writes:
> ...
> And if you use TCP with the new window extension mechanisms you can get
> much better throughput.  However, I don't know any PC code that uses those 
> yet.

Really?  To a PC which probably can't handle more than a few
back-to-back ethernet packets?  (A 250KByte window means the sender is
going to want to send hundreds of back-to-back 1500 byte packets in a
row.)  And on ethernet where the bandwidth*delay product is so low?  I
would really like to know.


>  Two
> >SPARCstation 2's are apparently capable of data rates of 800 to 1000
> >kilobytes per second memory-to-memory transfer on a dedicated Ethernet.
> 
> Sun's can do *much* better than that.

Yes, it's hard to get much more than 1MByte/sec over a 10MHz ethernet.

TCP-Large-Windows might help, by making it possible to reduce the
number of ACK's and so the time spent in collision back-off.  I'll have
to try that.


> > The CPU is probably not critical,
> 
> CPU *is* critical.  One of the big bottlenecks is checksum calculation.
> (I do hope that whoever measured the Sun NFS speed did it with checksums 
> turned on -- Sun workstations run with UDP checksums OFF by default.)

This is partly true in the NFS, TCP, and UPD implementations I know
about.  The CPU is the critical resource if you are using something
faster than ethernet, but the checksum is only one of the top 3 or 4
contenders in the program counter profiles.  The cost of the UDP
checksum for modern systems, including Suns, at the low data rates of
NFS over ethernet is insignificant.

Consider that you have only about 1MByte/sec of ethernet bandwidth, and
so need to execute between 0.5 and 1.0 million Instructions/sec to
checksum the data (depending on whether you have a carry bit).  Setting
aside any data cache misses, which will generally have to be paid for
the bcopy()'s, that is on the order of 1.0 to 2.0 M cycles/sec.  On a
machine with 33MHz clock rate, you will spend less than 10% of you CPU
computing the UDP checksum.

Of course, you can write code to compute the UDP checksum as slowly as
you wish.  The AT&T 80386 System V reference source I saw a few years
ago was very clearly correct, since it computed the checksum in C one
byte at a time.  It was also very clearly amazingly slow.  I assume
vendors were expected to replace the code with assembly language.

Sun continues to promise that real soon they will turn on UDP checksums
by default.  That may have already happened.


Vernon Schryver,  vjs@sgi.com
Xref: sparky comp.protocols.nfs:2268 comp.protocols.tcp-ip.ibmpc:5113
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject: Re: ?floating license server al la FrameMaker
Date: 8 Sep 1992 18:29:12 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <18fp5aINNnsd@seven-up.East.Sun.COM> geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>(Obviously you can prevent people from copying an application executable
>by marking it as execute-only, but this won't work with applications which
>require read access to the .EXE to, e.g., load overlays.)

People willing to hack a bit can fix even this.  The trick is to figure out
where the core of the program ends and where the overlays begin, then split
them into two files.  Write a shim TSR to redirect usage from one to the
other, and you'll be able to mark the core and the TSR execute-only.  The
overlays are copyable, but they are hopefully of little use without the
program core.

This doesn't work with Windows applications, and my little tools that do it
only work on about 75% of the software I've tried them on, but they do help.

BTW, we tried Saber Meter and were quite unhappy with it.  We had much
better luck with Setlimit from San Diego Mesa College.  Unfortunately,
Setlimit won't work with NFS (as the original question required), since
it depends on NetWare semaphores.

-- 
"Beware of programmers who     Stephen Trier
 carry screwdrivers."          Network Services Engineering, IRIS/INS/Telecom
       Leonard Brandwein       Case Western Reserve University
                               trier@ins.cwru.edu
From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: Ctrl-P key confusing to PC-NFS?
Date: 5 Sep 1992 12:54:39 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Fixed in 4.0a, FTPable from any of
	bcm.tmc.edu
	ftpserver.massey.ac.nz
	src.doc.ic.ac.uk

Geoff

--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
From: doug@mcm.com (Doug Dooley)
Subject: PC-NFS received packets error & Cabletron packet driver
Keywords: PC-NFS Cabletron driver
Reply-To: doug@mcm.com (Douglas F. Dooley)
Organization: Mellon Capital Management Corp., San Francisco
Date: Sun, 6 Sep 1992 23:23:11 GMT

All of our PC's (about 50) running PC-NFS 4.0a with Cabletron
E2010 and E2110 NICs using Cabletron's Generic Packet Driver ver.
3.02.25 and Cabletron's PC-NFS Ethernet Interface Driver Ver
1.01.00 consistently produce the PC-NFS error message:

NFS243W : Warning: no packets received from the network: check
connectors, etc.

In addition, a PC-NFS "netstat -i" says Ipkts=0, but a plain
"netstat" says TCP & UDP packets have been received.  Most else
of PC-NFS seems to work OK, but we are concerned we may be
missing something important.

We see this on all our PC's (386s & 486s, various makes) with
the above configuration, but don't see it with 3COM
cards/drivers, or if we use Cabletron's NDIS driver interface.

Has anyone else see this problem?  Is this a PC-NFS problem or a
defective Cabletron driver?  There was a posting from another
site about this problem a month or so ago, but I didn't see any
response.
-- 
===========================================================================
Douglas Dooley
Mellon Capital Management
Email: doug@mcm.com               Phone: 415-546-6056
Newsgroups: comp.protocols.nfs
From: andyp@shared.COM (Andy Pardue)
Subject: on.c source
Date: Fri, 04 Sep 92 21:53:05 GMT
Distribution: comp
Organization: Shared Financial Systems

I am trying to locate source for the 'on' command.  I have done some poking
around at various ftp sites but am obviously missing something.  Any help
will be appreciated.
--
        Andy Pardue                            Shared Financial Systems
        uunet!shared!andyp                     Dallas, Tx 
        Phone: 214-458-3896                    Fax: 214-458-3876
        --->>> My opinions may not be shared by Shared <<<---
Xref: sparky comp.protocols.nfs:2328 comp.protocols.tcp-ip.ibmpc:5235 comp.dcom.lans.ethernet:1913
From: rh0083b@medtronic.COM (Roger-Hunen)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Date: 15 Sep 92 06:55:28 GMT
Organization: Medtronic, Inc.

In article <karl.23.716089551@empirical.com> karl@empirical.com (Karl Auerbach) writes:
>>Two SPARCstation 2's are apparently capable of data rates of 800 to 1000
>>kilobytes per second memory-to-memory transfer on a dedicated Ethernet.
>
>Sun's can do *much* better than that.

No they cannot. 1000 kByte/s = 8 Mbit/s, which already comes close to the
10 Mbit/s of the Ethernet...

Regards,
-Roger
(I speak for myself)
Xref: sparky comp.protocols.nfs:2255 comp.protocols.tcp-ip.ibmpc:5094
From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject: Re: PC-NFS received packets error & Cabletron packet driver
Date: 7 Sep 1992 14:50:18 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com
Keywords: PC-NFS Cabletron driver

Quoth doug@mcm.com (Douglas F. Dooley) (in <1992Sep6.232311.17688@mcm.com>):
#All of our PC's (about 50) running PC-NFS 4.0a with Cabletron
#E2010 and E2110 NICs using Cabletron's Generic Packet Driver ver.
#3.02.25 and Cabletron's PC-NFS Ethernet Interface Driver Ver
#1.01.00 consistently produce the PC-NFS error message:
#
#NFS243W : Warning: no packets received from the network: check
#connectors, etc.
#
#In addition, a PC-NFS "netstat -i" says Ipkts=0, but a plain
#"netstat" says TCP & UDP packets have been received.  Most else
#of PC-NFS seems to work OK, but we are concerned we may be
#missing something important.
#
#We see this on all our PC's (386s & 486s, various makes) with
#the above configuration, but don't see it with 3COM
#cards/drivers, or if we use Cabletron's NDIS driver interface.
#
#Has anyone else see this problem?  Is this a PC-NFS problem or a
#defective Cabletron driver?  There was a posting from another
#site about this problem a month or so ago, but I didn't see any
#response.

This is due to a defective Cabletron driver. 

PCNFS.SYS contains a "log vector", an array of counters which are
incremented to reflect various events. When the link level driver is
initialized, it is passed a pointer to this vector so that it can log
driver-level events. Among the events which are logged are packet
receives and sends. In the case of a board-level driver, these tallies
accurately reflect the totals for the interface; in the case of a
"shim" (e.g. PKTD.SYS or NFS-NDIS.SYS) they reflect the events which
were "visible" to the shim. The Cabletron driver is obviously not
logging incoming packets correctly.

The "No packets received..." message is issued at the end of certain
NET commands (including "NET INIT") if at the conclusion of the command
no input packet events have been logged. It does not necessarily imply
that a problem exists (I'm sure that there are quiet nets, though I've
never seen one! :-), but if the "NET INIT" failed for some reason (e.g.
"NET NISSET *" failed to find an NIS server) the message may assist in
troubleshooting.

As for the Cabletron driver, if things appear to work apart from the
"No packets..." message and the "NETSTAT -I" counters, I wouldn't
worry. We'll suggest to Cabletron that they add the missing line to
their driver.

Geoff

--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.nfs
Subject: Re: packet disassembler
Date: 14 Sep 1992 20:28:24 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: nfs

In article <tmurphy.716494566@convex.convex.com> tmurphy@convex.com (Tom Murphy) writes:
>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?

Get tcpdump from an FTP server.  It's similar to etherfind, but decodes
more than etherfind does, and it looks relatively easy to extend.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: spw@gothamcity.uucp (Steve Weismuller [UNISYS])
Subject: NFS info
Organization: Software Technology Branch - NASA/Johnson Space Center
Distribution: usa
Date: Wed, 16 Sep 1992 03:29:08 GMT



Does anyone have any source of info (i.e. papers) that discusses NFS
in for use in a distributed environment, and what the advantages and
disadvantages are?  How much overhead NFS employs, ...  any info
would be helpful...

spw@gothamcity.jsc.nasa.gov

Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
From: hoffman@tsla.noava.lisc.lockheed.com (John Hoffman)
Subject: Re: PC-NFS received packets error & Cabletron packet driver
Organization: LISC Noava
Date: Sat, 12 Sep 92 01:16:33 GMT

John Hoffman
doug@mcm.com (Doug Dooley) writes:
: All of our PC's (about 50) running PC-NFS 4.0a with Cabletron
: E2010 and E2110 NICs using Cabletron's Generic Packet Driver ver.
: 3.02.25 and Cabletron's PC-NFS Ethernet Interface Driver Ver
: 1.01.00 consistently produce the PC-NFS error message:
: 
: NFS243W : Warning: no packets received from the network: check
: connectors, etc.
: 
: In addition, a PC-NFS "netstat -i" says Ipkts=0, but a plain
: "netstat" says TCP & UDP packets have been received.  Most else
: of PC-NFS seems to work OK, but we are concerned we may be
: missing something important.
: 
: We see this on all our PC's (386s & 486s, various makes) with
: the above configuration, but don't see it with 3COM
: cards/drivers, or if we use Cabletron's NDIS driver interface.
: 
: Has anyone else see this problem?  Is this a PC-NFS problem or a
: defective Cabletron driver?  There was a posting from another
: site about this problem a month or so ago, but I didn't see any
: response.
: -- 
: ===========================================================================
: Douglas Dooley
: Mellon Capital Management
: Email: doug@mcm.com               Phone: 415-546-6056
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip
From: raob@mullian.ee.mu.oz.au (richard oxbrow)
Subject: Re: NFS Over Satellite Link
Organization: Electrical and Electronic - University of Melbourne 
Date: Sun, 13 Sep 1992 00:28:52 GMT

In article <avalon.716321346@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes:
>pahountis@ncf.al.alcoa.com (Julia Pahountis) writes:
>
>>Has anyone, or do you know of anyone, who has done NFS over a satellite link?  (Can it be done?)
>>I would appreciate any information on how it was accomplished and what
>>kind of problems were
>>encountered.
>
>Well Australia is connected to the USA via a fairly fast satellite link
>(512kbit/s) and I've never seen any problems when using an NFS disk
>mounted from the USA.

mounting over a 57kbit/s link isn't all that much fun ;-) but it works
provided your link doesn't died..

I would suggest you have a look at transarc's/CMU AFS (andrew files system)
which performs a similar function to NFS but has a few other nifty
features, like local file caching, added security etc..  (to cut down
on the link traffic)

	richard/..
 
richard oxbrow			   |internet    raob@mullian.ee.mu.OZ.AU
dept. ee eng,  uni of melbourne    |uunet       ..!uunet!munnari!mullian!raob
parkville, victoria         3052   |fax         +[613] 344 6678   	   
australia               	   |phone       +[613] 344 6782
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
From: beame@maccs.dcss.mcmaster.ca (Carl Beame)
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Organization: McMaster University, Hamilton, Ontario, Canada.
Date: Wed, 16 Sep 1992 00:33:37 GMT

> beame@maccs.dcss.mcmaster.ca (Carl Beame) writes:
>
>
>	We have also done tests with the 3C509 card. The tiny buffer size makes
>the card little better then their 3C501. Its not just NFS that can expect a
>large number of back to back packets, TCP does as well. 
>

Well, I guess I have to eat my words ... well almost. Let me rephrase the
above statement. The 3C509 card when configured for "DOS Client" driver
optimization does not perform well ... but when configured for a "Windows
Client" or "Server", the card is the best ISA card I've seen. It passes
all our tests with flying colours and when we advertised a 16K TCP Window,
we had no trouble FTP getting files from a SUN and RS/6000. Full NFS 8K
reads were no trouble, even when running MS Windows from an NFS volume.
 
Though I know that we are going to get many support calls from users who are
having trouble with our default setup as it will not function well if the
card is set for "DOS Client" optimization. I was wondering if anyone knows
what the different optimizations mean ?

Carl Beame
Beame & Whiteside Software Ltd.
Newsgroups: comp.protocols.nfs