In the past, I’ve seen issues on latency sensitive applications that were quite difficult to find the root cause of. Symptoms tended to be in the form of unexpected delays and performance problems in applications where there were frequent, but very small updates. This is easy to spot if your app has some sort of timestamping mechanism to determine whether delays are occurring (eg: you could see a delay that is too large to be network induced), otherwise you’re into packet analysis territory.
Wireshark traces tended to show a delay in ACKs being sent back and/or fast retransmits where the other end was still waiting for an ACK to a packet. The delays introduced were far too high to be a network issue (or so you’d think) and everything checked out, so blame was levelled at the server end, but it took a while to find out where exactly this delay was being introduced.
From Microsoft KB2020559:
The Nagle Algorithm applied as part of RFC 1122 means that small payload network transmissions (such as read SCSI OpCode commands) may not be sent until either a full TCP segment is reached on that NIC or the delayed acknowledge time trigger is reached (200ms).
The procedure is on the webpage linked above, and does highlight some potential pitfalls which you should be aware of, but for reference:
On Linux, this setting has to be coded into the app by setting the TCP_NODELAY socket option. There doesn’t seem to be a way of setting this on a NIC that I can find.