Forums

Performance of TCP/IP stacks

Started by Dejan June 20, 2005
There are many freely available TCP/IP stakcs  (OpenTCP, lwIP, ethernut 
etc.) as well as many commercial ones (NetX, CMX, ...) . I would appreciate 
if you can comment on the performance of  TCP connections (as well as UDP, 
if available). The type of micro used as well as CPU clock is also usefull. 
This is not a school project nor market survey. I simply want to see what 
can I expect from such solutions. Commercial ones usually give memory 
footprints, but performace is never shown...Thank you in advance.

- Dejan


"Dejan" <(remove)ddurdeni@zg.t-com.hr> wrote in message 
news:d95td5$7uf$1@ss405.t-com.hr...
> There are many freely available TCP/IP stakcs (OpenTCP, lwIP, ethernut > etc.) as well as many commercial ones (NetX, CMX, ...) . I would > appreciate if you can comment on the performance of TCP connections (as > well as UDP, if available). The type of micro used as well as CPU clock is > also usefull. This is not a school project nor market survey. I simply > want to see what can I expect from such solutions. Commercial ones usually > give memory footprints, but performace is never shown...Thank you in > advance.
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 :)
Repzak wrote:
> 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
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.
> 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....
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
Repzak wrote:
> > 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
1. Congratulations! 2. 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 -- Tauno Voipio tauno voipio (at) iki fi
Tauno Voipio wrote:
> 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.
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
Richard H. wrote:
> Tauno Voipio wrote: > >> 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. > > > 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). -- Tauno Voipio tauno voipio (at) iki fi
Tauno Voipio wrote:
> 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.


Richard H. wrote:
> Tauno Voipio wrote: > >> 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)
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.
> Have you found any implementations where this was an exception, or where > it needs a byte of garbage data in the payload?
All the common implementations I've tested are happy with the keepalive probes (Windows, Linux, Solaris, OS X). --- An embedded TCP implementation has also to be quite anti-social to hanging connections: there is simply not enough storage available to allow for the luxury of connections doing nothing. It would need storage up to the peer window size (up to tens of kilobytes) to get rid of the delay caused by the delayed ACK. In many embedded systems this is more than is available, especially as it is needed for each active connection separately. -- Tauno Voipio tauno voipio (at) iki fi