-----Original Message----- From: Justin [mailto:Justin.Acklin@sv.sc.philips.com] Sent: Wednesday, March 22, 2000 7:21 PM To: toasters@mathworks.com Subject: Re: Solaris 7 & NFS2/NFS3/TCP/UDP....

I just looked at our main filer and realized we are using 8k NFS packets. With almost exclusively solaris 2.6 and 2.7 clients. I bet we would see a significant speed increase if we upped it, particularly with the large regressions being done on this Netapp. But, can I just log in and change the value? Will that affect existing mounts, and at what point would the new blocksize take effect? Or, can I only set it on reboot -- but even then the clients would have to remount the filesystem right? Someone help me out on the proper way to do this, and let me know if doing this causes harm in any way. Looking at nfsstat most of our operations are indeed nfs3.

In my real-world experience, some sites do well with 32K transaction sizes, some do better with 8K. It depends on the typical amounts of retransmissions you have on your network.

What people need to remember is that regardless of how big your transaction size is, if you are using Ethernet, you are bound to a 1500 byte packet size. So with a larger transaction size you are generating fewer NFS requests, but layers 2 and 3 still have to deal with the consequenses. Layer 3 has to break the requests into multiple IP packets, and layer 2 is responsible for holding those packets until the transaction is complete in the case of retransmission.

Now let's add UDP to the mix. UDP doesn't have a concept of a packet count. Therefore, retransmissions are more expensive in a UDP environment because you have to start from the beginning. Now, with 8K transactions you're only talking about a small number of packets that would have to be retransmitted. What with 32K, you can have many more (in the range of 16-18 packets) and this can be expensive.

So what's the bottom line? You may want to experiment with a client or two and see how these parameters affect your network. In some cases, 32K/UDP works great. In others, it's not so great. Use what works on your network.

Hope this helps.

-- Adam Fox NetApp Professional Services, NC adamfox@netapp.com