Performance of TCP/IP stacks

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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



Re: Performance of TCP/IP stacks

Quoted text here. Click to load it

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 :)



Re: Performance of TCP/IP stacks
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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

Re: Performance of TCP/IP stacks
Quoted text here. Click to load it

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


Re: Performance of TCP/IP stacks
Quoted text here. Click to load it

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

Re: Performance of TCP/IP stacks
Quoted text here. Click to load it

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


Re: Performance of TCP/IP stacks
Quoted text here. Click to load it

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

Re: Performance of TCP/IP stacks
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Performance of TCP/IP stacks
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.



Re: Performance of TCP/IP stacks
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.



Site Timeline