NFS transfer times

[Brian Reiter]

Hi Folks,

Heres the situation. 2 DS10s (1 Server 1 Statation) running VMS 7-3-2 TCPIP 5-4 ECO 5. The DS10 AlphaStation is configured as the NFS server, the other DS10 is the client. During a test the client was able to transfer data from the server at a rate of 5 Mbytes per second, however transferring data to the server went at 0.9 Mbytes per second. At the time of the test there was no other LAN or disk activity.

The network i/f is at 100Mbs and both sides have autonegotiated to a 100 full. I suppose the questions are:

1) Is this normal?
2) If this behaviour is not normal what on the server could cause this discrepancie?

I'm tied to using NFS in this situation, the customer is adamant that we cripple our systems with unix stuff.


Regards

Brian

[Arch_Muthiah]

Hi Brian,

Please make sure the send and receive queue sizes and network state are ok using

TCPIP's> "netstat" command.

poor network configuration both in client and server side may be the reason poor nfs performance.

[Ian Miller.]

monitor the system running the NFS server.
MONITOR IO and MONITOR FCP

Is the file being extended in small amounts each time? I think will show in FCP activity?

Is highwater marking on - will show as erase activity?

Is the target disk heavily fragmented -lots of window turns?

[Volker Halle]

Brian,

consider to test the same or similar file transfer with FTP to see, if you achieve, better, worse or about the same performance. This could then point you in the direction to where the problem may be...

Volker.

[Brian Reiter]

Hi Volker

FTP via other network interfaces seems OK. Certainly not as low as 0.9Mbyte.

When I'm back in the office I'll try FTP on that interface and see if there are any differences.

cheers

Brian

[Colin Butcher]

What transfer rate do you get with other protocols (eg: DECnet COPY, TCP/IP FTP)?

I find something like COPY REMOTE:: NL: useful to remove the local system disc etc. from the equation.

Worst case write a small test program (even DCL using OPEN / WRITE / READ / CLOSE) to just hammer the network itself.

What are you seeing with the LAN device counters (LANCP / SDA will help you here). It is possible that you have a duplex mismatch, even though you think that both ends have auto-negotiated to 100FDX.

Is the switch a managed switch and does it tell you the speed / duplex state?

What firmware have you got in the DS10?

It's a steady process of elimination - prove everything else, then you can really point the finger at NFS.

Good luck. Hope this helps.

Cheers, Colin.

[Wim Van den Wyngaert]

How did you measure the performance ?

I did a copy of a file : 20 seconds.
I did a backup of the same file to a save set : 90 seconds (the file is extended a lot of times).

Wim

[Wim Van den Wyngaert]

Also usefull info :
$ ucx zero nfs
... do test ...
$ ucx show nfs

Wim
(still thinking in ucx)

[Michael Yu_3]

Hi Brian,

I suspect that the NFS client has duplex incorrectly negotiated.

If you are running with the latest LAN patch for V7.3-2, you can use mc lancp sho dev /int to see if the duplex is OK.

Otherwise check the counters using lancp show dev/count, if there are increasing errors like alignment errors, frame check errors or receive data length errors, the there is some problem with duplex between controller and switch port.

Thanks and regards.

Michael

[Brian Reiter]

Hi Folks

Sorry about the delay getting back. Had time off to cover staff development days at the school :)

Anyway, barring a single CRC error there was nothing untoward in the MC LANCP SHO DEV/COUNTERS, SHO DEV/CHAR indicates full duplex at a 100 MB. This interface gets used a lot by the applications and normally a mismatched duplex results in the system not working too well.

I repeated the file transfer test using FTP on the interface, FTP is around 4 to 5 times faster in both directions. Although writing files back on the server unit seems slightly slower (3 Mbytes a second vs 4 Mbytes for the client writing the file), but still substantially faster than the observed NFS performance.

So it could be some issue with the disks on the Server. I'll do some more tests when I get through the pile of post-holiday paperwork :)

cheers

Brian