HDTenEightyP/NetNews huggingface dataset:
From: george@ache.mad.adelaide.edu.au (George Travan)
Newsgroups: comp.protocols.nfs
Subject: ftp transfers to pc FROM sun take forever.
Date: 11 Sep 92 05:26:30 GMT
Reply-To: george@frodo.ua.oz.au
Organization: University of Adelaide
NNTP-Posting-Host: ache.mad.adelaide.edu.au
Originator: george@ache.mad.adelaide.edu.au



I have noticed some strange behaviour between a pc client running pcnfs4.0a
and its SUN IPX server. Specifically, ftp transfer rates depend upon the direction
with transfers "FROM" the SUN to the pc take what seems to be 'forever'.

An example:

12934 bytes received in 78.064100 seconds (0.16 kbytes/s)  SUN -> PC
The same file transfered in the other direction happens at a reasonable rate. >10kbtes/s.
PC -> SUN.

What could be causing this? It seems to be only for files > 1k and the system just
looks inactive.

Is their any way of determining where/what the problem may be? I'm stumped over this.


/Geo
-- 
                  George Travan "A Rebel Without A Clue!"                   
                  E-mail: george@ache.mad.adelaide.edu.au                       
     Phone: (Australia) +61 08 228 5968   Fax: (Australia) +61 08 224 0464  
        University of Adelaide,G.P.O Box 498 Adelaide, AUSTRALIA 5001
From: wjk@Phonogenic.COM (Bill Keenan)
Newsgroups: comp.protocols.nfs
Subject: What NFS packages for Windows 3.1/DOS 5.0 are shipping?
Date: 5 Sep 92 23:53:41 GMT
Reply-To: wjk@Phonogenic.COM (Bill Keenan)
Organization: Phonogenic Systems Corporation
X-Mailer: uAccess - Macintosh Release: 1.6v1

I am trying to select an NFS package for use on 386/486 machines
running Windows 3.1 w/ DOS 5.0. I have been trying to get product info
and/or an evaluation copy of each package I learn about. So far, I know
of 5 packages (ftp's, B&W's, PC-NFS, Super TCP, Chameleon) which may or
may not work WELL with Windows.

I should appreciate knowing about any packages (publisher, phone number,
address, etc.) which are available. I should also like any praises or
flames for these packages in the Windows 3.1 environment.

The plan is to use the selected package with an NE2100 compatible
Ethernet interface. Any opinions on this interface should also be
welcome.

Bill

------------------------------------------------------------------------
Bill Keenan
Internet:	wjk@phonogenic.com -or- phngnc!wjk
AppleLink:	wjk@phonogenic.com@INTERNET#
CompuServe:	>INTERNET:wjk@phonogenic.com
Phonogenic Systems Corporation - Phone 415/365-1083 - FAX 415/365-1083
PO Box 3535, Redwood City CA 94064

Rudman - Tsongas '96 on the Republocatic ticket
Politicians working together for fiscal responsibility! This country
borrows about $4.25 per day per US resident (that is $21/day for a
family of 4) with little hope of paying any of the principle!
Newsgroups: comp.protocols.nfs
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: What are the advantages and disadvantages of B+Wnfs vs SunPCNFS?
Keywords: PC-Email, PC-NFS, HP server
Organization: Twin Sun, Inc
Date: Wed, 16 Sep 1992 00:35:42 GMT

curt@ekhadafi.austin.ibm.com (Curt Finch) writes:

>What are the advantages and disadvantages of B+W NFS vs SunPCNFS?

This month's issue of SunWorld has a review article that might help
answer this question:

	Dave Taylor, Joanna Tsang, Martin L.W. Hall
	Making the PC connection
	SunWorld 5, 9 (Sept 1992), 63-67

This review is worth reading if you're interested in connecting PCs and Suns.
It covers the following products:

	Pathway Access 2.0 with Client 1.1 (Wollongong)
	PC-Interface 4.10 (Locus)
	PC/TCP 2.05 with Kernel and InterDrive (FTP Software)
	BW-NFS 2.0 (Beame & Whiteside)
	PC-NFS 4.0 (SunSelect)

Overall, they liked Pathway Access the best, or B&W if you're on a budget.
PC-Interface was the quickest overall, but it was NFS-only (no FTP).
From: horwich@lexcel.mti.com (Jordan Horwich)
Newsgroups: comp.protocols.nfs
Subject: NFS IOPS specs
Date: 15 Sep 92 23:41:52 GMT
Organization: Micro Technology, Inc., Anaheim, CA

SUN and Auspex have different benchmark specifications for 
generating their respective NFS IOPS values. Can anyone direct me
towards these specfications. Also, is anyone aware of the Systems 
Performance Evaluation Cooperative ? If so, how do I contact this
organization ? I would like to get a benchmark spec from them as well.


Jordan Horwich
Micro Technologies Inc.
horwich@mti.com
From: wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
Newsgroups: comp.protocols.nfs
Subject: Re: on.c source
Date: 8 Sep 92 14:22:15 GMT
Reply-To: wswietse@bs.win.tue.nl

wswietse@wsbs06.bs.win.tue.nl (Wietse Venema) writes:
> The on/rexd protocol is as secure as a wildcard in your hosts.equiv file.
> Be careful.

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Nice analogy, but wouldn't a wild card in /.rhosts be more similar to rexd?

The SunOS 4.1.1 rexd refuses access to the root account. This leaves
bin, daemon etc. unprotected, so the restriction hardly helps.

SunOS 4.1.1 rexd is like having "+ +" in /etc/hosts.equiv.

	Wietse
From: bodapati@hpindda.cup.hp.com (Ramesh Bodapati)
Date: Fri, 4 Sep 1992 23:42:27 GMT
Subject: Re: NFS file locking
Organization: HP Information Networks, Cupertino, CA
Newsgroups: comp.protocols.nfs


Hi. I support the (remote) lock manager on HP-UX systems.

I spent some time looking at this problem and verified that two PCs can 
edit the same file.        

SHARE and UNSHARE requests are handled by the lock manager.

The reason both PCs can edit the same file is that when the editor is run it 
firsts issues a SHARE command, gets the data into its buffer and it immediately
issues a UNSHARE command.  You can now  edit the file on your PC. Later when 
you make changes and write the file back into the server, the PC once 
again issues a SHARE and UNSHARE requests.

So, the editor doesn't have exclusive access to the file for more than a very
small period of time. 

I wrote a "C" program, on a PC, that opens a file (O_RDWR)  and   keeps it open 
indefinitely. When  you run this program the other PC can no longer edit 
or cat the file.  IT WORKS!


The applications, vi editor in this case, should either lock the file via a
seperate LOCK request or they should not issue an UNSHARE command for thei
system to behave as you are expecting.


I hope this helps.

Ramesh Bodapati
Information Networks Division
Hewlett-Packard
bodapati@cup.hp.com



P.S: Note that you must execute the "share" command on the PC and you must
     mount the server with the /ms option.

Newsgroups: comp.protocols.nfs
From: cliff@psisa.psi (Clifford Kahan)
Subject: HELP!
Organization: Pencom Systems Incorporated
Distribution: usa
Date: Tue, 08 Sep 1992 15:32:35 GMT

Please do not flame me for posting this here but I am really in a bind.

I currently have a client that really needs to enhance their operating systems
file system.  I would like to find someone who would be interested and 
qualified to make significant changes to the file system.  The position will
last for about a year and will require someone to work at their location a
minimum of 40/hr a week.  Financially I'm sure I can make it attractive.

Once again I'm sorry for posting in this group, but I need some help.

thanks

cliff@pencom.com
Xref: sparky comp.protocols.nfs:2280 comp.unix.programmer:4606 comp.unix.wizards:3871
From: vander@flab.fujitsu.co.jp (Mike van der Velden)
Newsgroups: comp.protocols.nfs,comp.unix.programmer,comp.unix.wizards
Subject: NFS Protocol Specification
Date: 10 Sep 92 08:34:09 GMT
Followup-To: comp.protocols.nfs
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan


I have the need to implement a protocol which will function much like
NFS.  I've read version 2 of the NFS protocol specification, and I
understand that it's the version that everyone uses.  I know version 3
exists, and I'm working on getting my hands on a copy of that
specification.

But, before I start, I'd like to solicit opinions from the net.  I'm
willing to summarize for the net if there is wide-spread interest
(otherwise I could e-mail a summary to anyone who would be interested).
I'm especially interested in opinions from people who have had an
opportunity to implement all or part of the NFS protocol.
Specifically, I would like to know:

1>  What would you do to improve the protocol?  Forgetting all about
    backwards compatibility, would there be any specific functions that
    you would add/remove/modify?  How about the arguments used by the
    protocol?

2>  What were the major problem areas you encountered in implementing
    the protocol?

3>  Are there any papers or other such documentation on this subject?

I have my own ideas on #1, but I'd like to hear what others have to
say, so I can avoid needless mistakes.  Thanks in advance for your time.

Please note the Followup-To: line.
--
Mike van der Velden
Distributed Systems Laboratory, Fujitsu Laboratories Ltd., Kawasaki, Japan
e-mail: vander@tokyo.hi.flab.fujitsu.co.jp

ps. If you send me a picture postcard      Mike van der Velden
    from your area to the address at       Fujitsu Unoki Dormitory, room 227
    right, I'll send you one from Tokyo.   2-17-18 Unoki, Ota-ku, Tokyo 146
    Postcards must be received by          Japan
    November 15, 1992
From: Gary.Woodman@anu.edu.au (Gary Woodman)
Newsgroups: comp.protocols.nfs
Subject: Re: Ctrl-P key confusing to PC-NFS?
Date: Thu, 10 Sep 1992 03:37:31 GMT
Organization: Computer Services Centre, Australian National University
NNTP-Posting-Host: gurrung.anu.edu.au

In article <657@dwp.la.ca.us> carlson@dwp.la.ca.us (Carlson Peters x7898) writes:

>I get this too.  Since ^p is part of emacs style unix command line
>editing I am forever hitting this by mistake.  

Must be a pain to a Unix-type person...

>The only alternative is to reboot.  

Not so; just hit ^p again, even at the Abort, Retry, Ignore prompt, to turn 
off printer logging.

>If I am running a dow session under 
windows I can>force the window to die with unpredictable results.

You don't say. :-)

--
Gary.Woodman@anu.edu.au         This post made from 100% recycled electrons.
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Organization: University of Waterloo
Date: Mon, 14 Sep 1992 18:17:14 GMT

> eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
>> someone else wrote:
>>>I've gotten as high as 5megabits/second using a 50Mhz 486DX box with a 16 
>>>bit WD board using the same software and packet driver.
>>
>>3Com's new (unreleased) cards should up that by 25% to 50%.

The 'unofficial' numbers I have list output speed on that baby (3c509)
at about 1168 kB/s or 9.57 Mb/s whereas WD8003 and 3c507s put out
far less than 700 kB/s on the same benchmark. 

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
Newsgroups: comp.protocols.nfs
From: costello@eplrx7.es.duPont.com (Tim Costello)
Subject: PCNFS, Authentication, and "other" file servers
Organization: DuPont Engineering Physics Laboratory
Date: Fri, 4 Sep 1992 13:46:11 GMT

	This question is most likely due to my lack of understanding Re:
PCNFS authentication servers, etc.  Let me describe the scenario.

	I have accounts on 2 geographically separated Sun systems.  One is
in my buliding and somewhat under my control.  It also serves as the
authentication server for my PC.  It's also on the same segemnent of
ethernet as my PC.  e other Sun system is reached through a router, a
different ethernet segment, and I have no control over it's setup.  Because
of these differences, event though both accounts have the same user name,
they are of course, associated with different user and group ID codes.  So,
the local Sun is not allowing authentication for the remote Sun, or at least
that's my assumption.

	Using PCNFS and Windows, I can "browse" the available file systems
for mounting on the remote Sun.  I cannot, however, mount them...I get an
error telling me that the remote file system is "unkown".  If I can browse
it, it must exist, right?

	So, the wrap up question for this long winded question is - How do I
mount a file system from a machine that isn't local to/ or share a file
system with the authentication server?  

	Or am I just confused and have everything wrong?

Thanks.

P.S.  There's a switch that can be used in the PC's CONFIG.SYS file, on the
line with PCNFs.SYS, the /v switch, that the documentation claims "will
allow names that exceed the 8.3 character format required by DOS."  This
would be particularly useful in Windows file requestors, since there doesn't
seem to be a way to get the names converted to "real" names ala 'ls'.  The
/v switch appears to have no effect in my setup (Win 3.1, PCNFS 4.0a).


-- 
Tim Costello
Du Pont Merck Pharmaceutical
costello@eplrx7.es.dupont.com
Newsgroups: comp.protocols.nfs
From: eengelke@steam.uwaterloo.ca (Erick Engelke)
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Organization: University of Waterloo
Date: Fri, 11 Sep 1992 18:56:12 GMT

 tom@rsp.UUCP (Thomas Ruf) writes:
>eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
>
>>>I've gotten as high as 5megabits/second using a 50Mhz 486DX box with a 16 
>>>bit WD board using the same software and packet driver.

>>That is about the limit of the current ISA ethernet hardware and packet
>>drivers...
>>On a different ISA network card we get 850 KB/s, but you really start
>>hitting the hardware bus limitations.

>Can't agree here: a good Ethernet card on ISA (e.g. our LANCE based cards)
>can saturate an Ethernet and of course also receive at the same rate.
>If you assume that ISA has a bandwidth of
>about 4MB/s, the CPU has still about 70% of time available for the
>packet driver and TCP/IP protocol processing. So the limitation
>is probably not the bus but the cpu.

I'd love to see that on ISA architecture.  But our experience to 
date has been that 286 machines with non-standard 12 MHz bus 
outdoes 386 machines on 8 or 10 Mhz buses when just doing packet
i/o (ie. no processing of the data).  By that I mean the kB/s
you get doing nothing but rep outsb  or rep outsw.

I used to have the numbers handy for maximum and avg transfer
rates on the various busses, speeds, etc.  Though I've lost 
that data, I remember it being consistant with my claim here.

If you have an ISA card and packet or ODI which can drive it at
full Ethernet speed (with new packets, not just retransmitting
already loaded packets), post back on this group.  A lot of 
people would like to see it.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
From: douglas@rhi.hi.is (Douglas Brotchie)
Newsgroups: comp.protocols.nfs
Subject: Re: What are the advantages and disadvantages of B+Wnfs vs SunPCNFS?
Date: 12 Sep 92 11:20:00 GMT

In <1992Sep11.183209.4545@maccs.dcss.mcmaster.ca> fred@maccs.dcss.mcmaster.ca
 (Fred Whiteside) writes:

>	My apologies in advance for airing internal difficulties
>on the network ...

>In <5305@krafla.rhi.hi.is>, (Douglas Brotchie) douglas@rhi.hi.is writes:
>>Alas, not my experience.
>>We tried an evaluation of BW-NFS in July.
>>Sent a technical query by fax 23rd. July.  No reply.

> [...]

>	the response to your fax was sent on Aug. 6th to the original
>requestor (Sigurbjartur A. Gudmundsson).  We likely should have sent
>an additional copy to you; our error.

>Fred Whiteside
>Beame & Whiteside Software, Ltd.

Thanks for your reply.
I will investigate immediately (i.e. after the weekend) the status of the
BWNFS product evaluation here.
In view of recent comments in this group - I look forward to doing so.

Douglas Brotchie
University of Iceland
Xref: sparky comp.protocols.nfs:2253 comp.os.ms-windows.programmer.misc:1704
From: als@bohra.cpg.oz.au (Anthony Shipman)
Newsgroups: comp.protocols.nfs,comp.os.ms-windows.programmer.misc
Subject: Implementing an RPC server with PC-NFS
Date: 7 Sep 92 06:30:13 GMT
Organization: Computer Power Software

I have the PC-NFS 4.0 Programmer's Toolkit.  It omits the server side of the
ONC RPC package.  But I need to write an application that runs as an RPC
server under Windows 3.1.

Here is my proposal for how to do this.  I have the source for TIRPC V2.0beta
so I can compile the server code under Windows.  The only tricky thing I expect
is emulating the behaviour of the Unix poll() system call.  There must be a
task switch while waiting for a network packet so there must be a message 
loop.  There is no way to get a message when an 
RPC packet comes in so I have to poll the network periodically. 
I can do this with a Windows timer.  I run a message dispatch
loop.  When a timer message comes in I check for RPC packets.  If one is found
then the message loop is terminated and the poll() function returns.

Here is pseudo-code for the scheme:


int
RunMessageLoop( int (*done_proc)(void), void *arg)
{
    /*
    **  Return TRUE only if we exited because done_proc() succeeded.
    */
    int ret = FALSE;

    do()
    {
        ret = (*done_proc)(arg);     /* do first in case already ready */
        if (ret) 
            break;

        GetMessage()
        DispatchMessage()

        any other Windows-specific break condition
    }
}


An implementation of poll() for the server library must do the following.

svc_poll(poll_set, npoll, timeout)
{
    int     done;
    struct  arg;

    clear timeout counter
    build arg from poll data and timeout counter

    done = RunMessageLoop(check_for_any_ready_fds, arg);

    if (done)
    {
        unpack data into poll_set
        return OK
    }
    else
    {   
        return some error   /* application window dying? */
    }
}

int
check_for_any_ready_fds(arg)
{
    if (any fds in *arg ready)
    {
        build the set of ready fds in *arg
        return true
    }
    inc arg->timeout counter
    if (timeout exceeded)
    {
        flag timeout in *arg
        return true
    }
    return false
}

I can use select() with a 0 timeout to check for ready fds.

Does this scheme seem reasonable?  Can anyone suggest a better way to do this.

There are other complications of course.  My server must include an emulation
of rpcbind.  This means the server code must listen for rpcbind packets as well
as application packets and distribute them.  The rpcb_set() and rpcb_unset()
functions need to be reimplemented to call rpcbind() locally since it will be
linked in with the server library.


Thanks for any advice.

-- 
Anthony Shipman                 "You've got to be taught before it's too late,
CP Software Export Pty Ltd,      Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia, 3121       You've got to be carefully taught."  R&H
Newsgroups: comp.protocols.nfs
From: fred@maccs.dcss.mcmaster.ca (Fred Whiteside)
Subject: Re: PCNFS and symbolic links 
Reply-To: fred@bws.com (Fred Whiteside) 
Organization: Beame & Whiteside Software Ltd. 
Date: Tue, 8 Sep 1992 14:40:43 GMT

In <188dfiINNlka@seven-up.East.Sun.COM>, geoff@tyger.Eng.Sun.COM writes:
>#I believe that one of the other NFS client for PC vendors has a way
>#around this (FTP, B&W?).
>
>B&W has a form of automount for such links, but I'm sure that Carl or
>Fred would acknowledge that in the absence of an RPC service which can
>report the full mount topology for a server, such a mechanism is a
>partial solution at best.

Ummm, not quite true Geoff.  We support symbolic links to
directories only, but they may reside anywhere on *any* file-system.
Of course, if the actual directory is not mountable you don't get the
directory, but that behaviour seems desirable.  We do not support
symbolic links to files.

While the fact that we don't support symbolic links to files
but only to directories may be seen as partial support of symbolic
links, we feel that the resource tradeoff involved justifies this
limitation.

And I have no idea what your comment about an RPC mechanism
for reporting mount topology of a server could possibly mean.

-Fred Whiteside
-- 
Fred Whiteside   Beame & Whiteside Software Ltd., Caledonia, Ontario
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred
Newsgroups: comp.protocols.nfs
From: karl@empirical.com (Karl Auerbach)
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Organization: Empirical Tools and Technologies
Date: Thu, 10 Sep 1992 01:45:51 GMT

>From: tgl@ssd.kodak.com (Tom Lathrop)
>Subject: Sun <=> PC Transfer Rate (Summary)
>Date: 4 Sep 92 17:39:31 GMT
>I was asked to summarize the responses to my query about optimizing
>Sun to PC file transfer.

>>I would like to find a fast way to transfer large files from a Sun
>>to a 486 PC.

>The consensus seems to be that FTP is faster than NFS for file transfer.
>FTP is included with the Sun PC-NFS package

That is almost always the case.  But it will be strongly affected by the
window size parameters at either end.

Was UDP checksumming turned on with NFS?

Was FTP doing binary or text mode transfer?  The latter requires the CPU at 
either end to examine each and every byte and do some data juggling.  (
Actually the PC end can win at this game because the DOS end-of-line
pair is the same as the internet end-of-line.)

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.

There is also a substantial difference depending on the latency and error 
rate of the network.  If you are going through routers and over the internet 
you can see a major difference between NFS and TCP file transfer rates.

But the #1 absolute most important factor is the speed of the disk.

I routinely get 2megabit FTP transfers from a Sun Sparc 2 to a wimpy
16mhz 386sx box with an 8 bit WD board and packet driver.... as long as the 
destination is NUL:  (Software is PC/TCP v2.1)

I've gotten as high as 5megabits/second using a 50Mhz 486DX box with a 16 
bit WD board using the same software and packet driver.

(This was done on an Ethernet with a background load of 300+ packets/second.)

But throw a disk in... and things get slower.  Of course this is affected
by how much disk caching is going on at either end.

 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.


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

Also, some drivers assume 8086 instruction set and don't use the much faster 
block-move to I/O port instructions.

In fact some drivers use DMA although a 386 or 486 CPU is often faster.

>software side, a couple of people said that if a packet driver is used,
>which one it is makes a big difference.

I've sent over 2500 packets per second through packet drivers.  And that 
was on a 12mhz 286.  Of course, that was a special test designed to
load the network.

I routinely receive a load of over 500 packets/second with a packet driver.

			--karl--
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
From: backman@vaxeline.ftp.com  (Larry Backman)
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Nntp-Software: PC/TCP NNTP
Organization: FTP Software, Inc., Wakefield, MA
Date: Fri, 11 Sep 1992 08:50:58

 >> >I've gotten as high as 5megabits/second using a 50Mhz 486DX box with a 16 
 >> >bit WD board using the same software and packet driver.
 >> 
 >> That is about the limit of the current ISA ethernet hardware and packet
 >> drivers.  3Com's new (unreleased) cards should up that by 25% to 50%.

 The 3C509 (if this is what you are referring to) has serious problems with
 8K receives.  I have had little luck in getting its OS/2 NDIS driver to 
 consistently receive all 6 IP fragments in an 8K RPC.  3Com's response
 has been to state that the NFS protocol is flawed if it expects to
 receive 6 back to back packets.

 The board has only a 2K buffer.
 
 Draw your own conclusions.

Larry Backman
FTP Software