SCIF:
Odds are your problem is arising from the bandwidth-delay product of your WAN link. This is the round-trip time of the link multiplied by the number of bytes per second it can send.
A long, fat pipe can result in very poor performance of large-volume TCP data transfer, which is what an NFS mount basically is, because of the size of the TCP transmit and receive windows.
In most HP-UX systems, the default window is 32k.
So, for example, say you have a T3 link at 44,736,000 bits per second or 5,592,000 bytes per second, with a round-trip time of 40 milliseconds between your NFS client and server.
This means that the link can transmit as much as 223,680 bytes (5,592,000 bytes * 0.040 seconds) before it's even physically possible for the local system to get the first acknowledgment from the remote system.
With a TCP transmit window set to 32k, then only 32k is sent in 5.85 milliseconds, and the other 34.15 milliseconds is spent waiting for the first ACK packet to come back.
You may see this referred to as packets "in flight," and it's a good way to visualize the situation.
The key to improving performance in this situation is to adjust the TCP transmit and receive windows to fit the capabilities of the WAN link.
The default window sizes are set in /dev/tcp: tcp_xmit_hiwater_def, and _recv_
In the above example, if I cranked the transmit and receive windows up to 256k:
ndd -set /dev/tcp tcp_xmit_hiwater_def 262144
ndd -set /dev/tcp tcp_recv_hiwater_def 262144
... then instead of sending 32k and waiting 34 milliseconds for the acknowledgment, it'll send 223,680 bytes in 40 milliseconds and then start getting acknowledgments back to drain out the buffer as it continues to transmit.
(I think there's also a case to be made for making the window size an even multiple of the maximum segment size of 1500 bytes, but HP doesn't do it, and memory is cheap.)
There's other parameters in /dev/tcp you'll notice - _lfp (long fat pipe) and _lnp (long narrow pipe), which allow the system to set different TCP windows for different types of links, but as I recall that applies only to interfaces, so if your router is handling the WAN link, not the HP system, then it's not triggered. You may need to investigate that further if you don't want the larger window to apply to every single TCP connection that the system makes. Memory's cheap nowadays, anyway.
Now, if you bump the TCP windows up like this there's a couple more settings you will probably want to change:
tcp_sack_enable = 1
tcp_ts_enable = 1
The "SACK" feature is "Selective ACK" from RFC-2018 - if some packets are lost, but not all, the receiver can acknowledge all the packets it has received, rather than just the highest in the continuous sequence, allowing the sender to fill in the gap without re-sending all the packets past the gap which were successfully received.
The "TS" feature is "timestamps" - since sequence numbers only go to 64k, it may be possible for them to wrap around when larger windows are in use. The timestamp will differentiate two packets with the same sequence number.
Setting these two parameters to "1" means that the system will both offer and accept these features. "2" means that the system will accept, but not offer.
To preserve these settings across reboot, update the /etc/rc.config.d/nddconf file:
TRANSPORT_NAME[0]=tcp
NDD_NAME[0]=tcp_xmit_hiwater_def
NDD_VALUE[0]=262144
TRANSPORT_NAME[1]=tcp
NDD_NAME[1]=tcp_recv_hiwater_def
NDD_VALUE[1]=262144
TRANSPORT_NAME[2]=tcp
NDD_NAME[2]=tcp_ts_enable
NDD_VALUE[2]=1
TRANSPORT_NAME[3]=tcp
NDD_NAME[3]=tcp_sack_enable
NDD_VALUE[3]=1
Let me know how fast your NFS mount goes after you do this. I think both your /test and your /a/b/c/d times will decrease noticeably, depending, of course, on your actual bandwidth/delay product.
