[Info-vax] Mounting NFS disk with /DATA non-default parameters

[glen herrmannsfeldt]

Sum1 <not at here.com> wrote:

(snip, someone wrote)
>>> Doing a TCPIP MOUNT blah will give a default read/write size of 8192
>>> according to TCPIP HELP MOUNT /DATA.  If I want to increase the size of
>>> the chunks transmitted, I expect that I can issue a TCPIP MOUNT/DATA=X,
>>> where X is some multiple of 512.  If I did /DATA=16384, I expect that I
>>> will be transferring 16k chunks.

(then I wrote)
>> As well as I understand it, yes, you can do that.
 
>> Are you using UDP or TCP?
 
(snip)

>> Going to jumbo packets might be more useful.

(snip)
> Thanks for the useful reply.  The "dumb" switch won't support 
> Jumbo packets and there is no spare slot on the DS10L.

You still didn't say UDP or TCP.

I started using NFS before there was NFS/TCP.

With UDP, the size specifies the size of the UDP packet, which
is then fragmented by IP if bigger than the MTU for the link.

For local networks, the usual way NFS is used, that works well.
But fragment reassembly fails if any frame is lost, and that can be
much slower than anything else. Also, Sun traditionally ran UDP without
checksum, relying on the ethernet checksum. Again, works fine for local
networks, not so well through the Internet.

For NFS/TCP, I would not expect much difference in transfer size.
 
> I am trying to improve the rate at which data arrives from the server 
> to the DS10L - there is a web server running and it receives requests 
> for photos, most of which are 300-300K.  Increasing the transfer size 
> may make a small but noticable improvement in the photo display time???.?

I think I wouldn't try changing the size until I needed to 
transfer gigabyte files, and then would also want jumbo frames.

At least the Sun NFS implementations would read ahead (on the 
physical disk) and have the data ready to go. I don't know
if the VMS ones do that.

-- glen