Netware 6.5 slow copying files

Do you have any traditional volumes on this server?  If not, then you can set your cachebalance higher, or turn it off altogether.  It's to balance cache utilization between NSS and traditional FAT filesystem.

I wouldn't expect it to be a NIC setting issue, if you've already verified it all matches.  The only instance (barring a bad NIC or driver) where the NIC settings affect stuff is if you've got your duplex and/or speed settings mismatched between the server and switch, or between the client and switch.  If it's all "auto/auto" and there are no problems with the hardware or drivers, then it should be fine.  Don't set your NIC to 1000/full if your switch is set to auto, or set your switch to 100/half if your NIC is set to auto; it's best to either set both ends to the same fixed setting or leave both ends Auto.

File commit means the server will write changes to disk when the file is closed instead of leaving it in cache for a bit and letting normal cache cleanup handle the commit to disk.  Generally, the settings related to client caching shouldn't affect reading from the server, unless there's a level2 oplock issue going on.  If oplocks are off on both ends (or on on both ends) read performance shouldn't be affected.

Since you're using hardware RAID5, no software-RAID-related TIDs apply, and reads should actually be faster than writes, since RAID5 read performance can only be beat by RAID 10. It's the write speed that suffers with RAID5.  That, IMHO, eliminates that.

Client file caching is the same as level 1 oplocks.  It allows local (on the client) caching of files, placing a lock on the files until the client closes the files and flushes its local cache to the server.  It only helps speed things up when doing bitwise manipulation of data, because the program doesn't have to wait for syn/ack traffic for each change.  Here's more info on oplocks and what to set, when and where:  http://support.novell.com/cgi-bin/search/searchtid.cgi?10095627.htm

A simple file copy from the server to the client should be lightning-fast, too, just like copying from the client to the server.  If it's not, then I'd suspect either a) you have some Windoze-specific stuff interfering or b) you need to find a post-SP2 4.91 client patch. There was one released today. http://support.novell.com/cgi-bin/search/searchtid.cgi?/2974113.htm

I solved the problem.  

I tried various other settings for OpLocks, re-verified auto-negotiation settings, etc.  But noting I did was working.  So, I decided to run a packet capture of a server file write and a file read and compare the two.  I filtered the packets to only display the traffic between my workstation and the server.  I started by looking at the packet sequences and noticed writes to the server were more bursty in nature.  In other words, there would be many more writes for each TCP ACK packet than there were for reads.  

Then I looked at the nodes involved expecting to only see two.  But in fact there were three nodes listed.  So the mystery deepened.  I thought perhaps the rogue node was the second NIC in my server, that was in fact disabled.  Comparing MAC addresses ruled that out.  I eventually discovered the third node was in fact my router.  I thought that was odd the server would try to traverse the router for LAN traffic.

So, I went back to inetcfg and checked the TCP bindings to the NIC.  Lo and behold, I found the subnet mask was incorrect.  I corrected the subnet mask error and now file copy from the server is as fast as to the server.

I'm still not sure why the incorrect subnet mask only affected traffic in one direction.  But I'm just happy to be screaming along once again.

Thanks for your suggestions.

Thanks for your input.

I'll look into that problem now that I have both directions running at the same speed.  Theorectically, I might get 8MB/s read and write, but I imagine there are many variables that would impact that speed.

I posted a comment in what I thought was the proper spot to ask for a refund on points since I solved my own question.  Forgive my ignorance if I goofed somewhere along the way.  Whatever is common practice is fine with me.  I sincerely did not intend for the question to reach the "abandoned" stage.

I followed the FAQ's which is exactly as you suggested with the exception of the link.