slow performance over WAN

[Ian Lochray]

Our customer has got a Tru64 server and a Windows server. They access these from PCs across a WAN and a LAN. Following reports of poor network response, we set up a simple ftp test. The results showed that LAN preformance was fine between the PCs and the Tru64 and the Windows servers. Across the WAN however, the Windows access was fine but access to the Tru64 server was many, many times slower than across the LAN and often times out. I cannot blame the WAN as the Windoes access is OK. Any ideas?

[Ralf Puchner · Accepted solution]

Have a look to the mtu size and fragmentation of the packets. try

inet:
pmtu_enabled=0

to allow fragmentation.

[Ian Lochray]

Ralf,
thanks for the input. I will get the customer to try this and I will let you know the results.

[Al Licause]

You might also check the routing tables on each host and perform a traceroute or
tracert from the PC to see if the paths are similar.

[Ralf Puchner]

any news to report?

[Ian Lochray]

Ralf,
we have asked the customer to make the change and report back to us. We are still waiting for a reply. I will update the entry to let you know if it works or not.

[Alexey Borchev]

We had 'slow Trunix' on LAN.

Ftp Trunix -> local HDD was fast.
Ftp Trunix -> network disk from NT server was slow.

Both FTP's executed from NT workstation, the "only difference" is destination drive C:\ versus N:
The solution was to run
C:\tmp> ftp -w:8192

It resolved the issue.
Maybe, this would be helpful in Your case.

[Ian Lochray]

We disabled pmtu_enabled and this made a considerable imrpovement although not quite enough. We then changed the MTU on the LAN card from 1500 to 1400 as the WAN used a router that had a packet size limit of 1458 so any full packets were being fragmented. This has resolved the issues.
Thanks for your help.

[Ralf Puchner]

You can add the -mtu 1400 option to the /etc/routes entries. So the packet size is only smaller for the gateway communication and not for the entire network communication.

[Ian Lochray]

I have just had an update on this. Apparently peformance was improved by setting the MTU to 1400 but not consistently. Subsequently, however, the server was rebooted and since then all response times have been excellent. Does this make any sense?

[Ralf Puchner]

Ian,

next time please use the netstat -rn, netstat -m and netstat -i command to check for resource/network problems. Maybe this will give you an clue what is going on.

[Ian Lochray]

Ralf,
thanks for your input.
Is it possible that, following the change to the MTU on the LAN card, something did not become aware of the new size until after a server reboot?

[Ralf Puchner]

no, maybe there are some sockets/connections still waiting for response or starting broadcast/paket storms.

[Ken Dearden]

You should not change the default Ethernet card settings, such as MTU, withough very good reason. Fragmentation of packets is determined by the network components for optimum performance. In a protocol deploying a conenction-oriented transport, such as TCP, it is the responsibility of the Transport layer (layer 4) of the protocol to ensure that packets are re-assembled, presented in the correct equence and that any corrupt or undelivered packets are retransmitted. TCP/IP is a very robust protocol and is tolerant to reasonably long delays and poor quality networks. Whilst poor performance might be experienced, it is unusual for TCP/IP to be the root cause of a session diconenction.

[Ralf Puchner]

Ken,

you are right, but in case of WAN, tunneling etc. this is a "must" to get the right performance. Otherwise network hardware will be stressed and depending on your hardware packets will be dropped or delayed if buffers are full.