Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Increasing robustness of a TCP receiver against peaks of CPU usage

Using wireshark to diagnose and solve data loss, data corruption and eventual socket connection loss. These happen when my receiver of a TCP socket is not fast enough to read the incoming packets from a remote data acquisition board.

The setup:

Our data receiver code runs on a PC with Windows 7 and can also run on an embedded. Same problem is seen on both platforms.

A remote data acquisition board sends samples at 240KB/second over tcp.

When the priority of the data receiving thread is low and CPU usage peaks (e.g. because I run Wireshark at high priority on the same CPU core as the data receiving code), we see data loss, data corruption and connection loss.

The question:

I expected the Window value on the ACK messages to decrease towards 0, and only then start having trouble. Then I would conclude that I need to somehow increase the the size of the receiving buffer to make my receiver more robust against peaks of CPU usage.

But the win value does not seem to even approach zero at the time that we start seeing Dup ACKs, which coincides with data corruption.

Shouldn't we see the Win value on ACK messages decrease to zero as the receiving buffer overflows (since the receiver is too slow to read the data as fast as needed)?

Then an "easy" fix should be to increase the receiving buffer (to minimize issues when a peak of CPU usage makes the receiver transiently slow).