What we HAVE done is to FTP to/from the HP to a high end workstation, and verified the transmission rate. If you’re on a 100 Meg connection, you should get at LEAST 30 Meg from a high end workstation to/from the HP via FTP (use a large file of 50 Meg or more). If your rate is only 5 meg or so, you’ve probably got a duplex mismatch.

If you use Autonegotiate on the switches, you should also use Autonegotiate on the server; if hardcode speed/duplex at one side, make sure you fix it the same on the other. A duplex mismatch will severely impact performance, but may appear normal under low volume traffic.

I don’t think the client OS is generating these checksums since I’m seeing retransmission requests from the server. I’m starting to lean towards the server as the culprit from my tests. Can a bad cable cause incorrect checksums or would it be the server’s nic?

Thanks

A possible reason for the incorrect checksum is if your network cards are capable of performing TCP Checksum Offload. Broadcom and Intel gigabit cards are among those that can offload TCP checksum calculation. Linux enabled TCP Checksum Offload automatically when it is available.

With TCP Checksum Offload, the packets are captured before the card calculates the checksum — so the checksums may not be correct. The checksum actually transmitted on the wire and received by the destination host will be correct.

On Linux, it is possible to disable TCP checksum offload

Of course it could also be due to any number of conditions, such as hardware failure, corruption of an IP datagram or router or congestion. Make sure your NIC drivers (server and wrkstn) are up to date. You may need to configure an NLB setup to make a fatter pipe for your ERP server.
Good luck!

The server is HP-UX 11.11 but will be migrating to 11.23 in the next couple months. From my testing it seems to be something wrong with the server, but we’re DBA-less currently so I’m reluctant to make any changes!