Performance of TCP/IP stacks

Hey

I will just put in my bad light on the Uip tcp/ip stack, the problem is the speed caused by windows uses 200mS to reply 1 ack package and the Uip canot send multiple packages, it gives a maximum og less than 10kbyte/s both 10 connections of 5 kbyte/s is not a problem....

Kasper (hope it is readable, a litle drunk after the last examination in my education.... 2nd higest grade :)

This is a standard TCP behavior called Delayed ACK; Windows is doing the right thing. It's done to prevent 1:1 ACK traffic for every packet received.

There isn't a way for the sender to manipulate / disable Delayed ACK on the receiver. However, if the Windows app is your own (i.e., not a browser client), configure it to send back a simple 1-byte NOP response whenever data is received - this will embed an ACK and boost your performance.

Yep, this is a limitation of the transmitting IP stack - only one TCP packet can be outstanding. IIRC, lwIP (by the same folks) does not have this TCP limitation.

Cheers, Richard

1. Congratulations!

1. The phenomenon is according to the RFC, called delayed ACK. Its purpose is to see if there is anything to send toward the embedded device along with the ACK. There is a trick to tickle the Windows stack to respond sooner by sending an extra ACK (toward Windows) with a slightly old sequence number.

This is a common problem in embedded stacks, as smoother flow would need more buffers: everything not yet ACKed must be kept in the sending TCP's socket buffers. The space needed is pretty quickly excessive in a small embedded device.

HTH

Ah yes, nice trick; I forgot about that one. That should be a pretty easy hack, no?

I'm not finding the details in a quick dig, but I recall that you would send an ACK with the proper ACK number (i.e., all bytes received to-date), but *incrementing* your sequence number by some amount to suggest there's missing data - this is supposed to trigger the receiver to react with a retransmission ACK to say "no, I'm missing that data, here's what I've got so far, please re-send".

Does this sync with your understanding? Any pointers to a more detailed discussion or implementation?

I'm at a loss for where I heard this trick; either here in c.a.e, or perhaps in Bentham's TCP/IP Lean book.

Richard

Well - that's mis-using the keepalive probe. I'm using in in my own TCP/IP embedded stack (which does not claim any RFC compliance, it's server only).

Yes, it would be. It should also be fairly foolproof, but it will also trip-up diag tools looking for re-transmissions, and will likely increment the re-transmissions counter on the far-end device.

Do you find that normal keepalives are effective against Delayed ACKs? (i.e., as above, but with your sequence# one less than the last ACK# received)

Have you found any implementations where this was an exception, or where it needs a byte of garbage data in the payload?

Richard

To combat the Nagle algorithm, I split my response payload packet into 2 TCP packet xmits...

the 1st typically contains 1 byte (a bytecount in my case). I set the TCP window size to 0 in this packet.

the 2nd contains the remainder of the data with the wondow size returned to nominal.

To combat the Nagle algorithm, I split my response payload packet into 2 TCP packet xmits...

the 1st typically contains 1 byte (a bytecount in my case). I set the TCP window size to 0 in this packet.

the 2nd contains the remainder of the data with the wondow size returned to nominal.

The segment for tickling an ACK *is* a keepalive probe without the advance byte but with the retarded sequence. It's only not used in the keepalive purpose (once every two hours).

The probes with advance bytes are for window probing and they are not used here.

All the common implementations I've tested are happy with the keepalive probes (Windows, Linux, Solaris, OS X).