[lwip-users] Re: lwip-users Digest, Vol 87, Issue 31

[Chen]

Hi all, 

I am coming back with two captures regarding lwip's retransmit
mechanism

NonAVR.pcap is captured on a non-lwip device, and you can see even ACk is
stopped at packet 48, this TCP server keeps sending out packets to the
PC

AVR.pcap is captured on a lwip-based device, and once the ACK is dropped
after packet 73, it stops transmission and begin to retransmit

Both cases were created by pulling the ethernet cable on the PC to
demonstrate the retransmit mechanism, and Nagel is disabled in both
cases.

*** THERE IS NOTHING WRONG IN LWIP'S APPROACH ***, but there is room to
improve: If the ack comes in slower than usual, the Non-lwip approach
will keep the flow going and have no impact on the throughput
rate.

May I request such option in the future lwip?

Thanks for consideration!

Chen




> > Message: 3
> > Date: Wed, 24 Nov 2010 09:45:47 -0500
> > From: Chen <address@hidden>
> > Subject: [lwip-users] Re: lwip-users Digest, Vol 87, Issue 29
> > To: address@hidden
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Thank you, Simon!
> >
> > 1) I assume you made a typo when commenting TCP_WND?
> >
> > "This must be at least  * (2 * TCP_MSS) for things to work
> well"
> > seems apply to TCP_SND_QUEUELEN, and since #define
> > TCP_SND_QUEUELEN        6 *
> TCP_SND_BUF/TCP_MSS, it satisfies the 
> > requirement
> >
> > 2) In my current configuration, which is derived from AVR32, 
> > TCP_SND_BUF=30000
> >
> > 3) Since there are plenty data steaming to lwip, I am sure there
> are
> > more than 2 frames (1200 bytes each frame) enqueued, thus Nagle
> > shouldn't affect it
> >
> > 4) I am programming in socket level, I assume
> > lwip_setsockopt_internal is the API in this level to turn
> on/off
> > nagle, but I failed to find the online doc regarding its detail.
> Can
> > you give a pointer?
> >
> > At this point, I still don't see why lwip should pause the
> > transmission after missing an ACK
> >
> >
> >>I think that was a typo and Kieran meant TCP_SND_BUF (the send
> queue
> >>limit in bytes). You might have to change TCP_SND_QUEUELEN (the
> send
> >>queue limit in pbufs), too.
> >>
> >> > Nagle's algorithm shouldn't affect my application since I
> am always
> >> > sending 1200 bytes data all the time.
> >>
> >>Based on how quickly the remote side ACKs the data, it might
> still
> >>influence the send decision. The nagle algorithm sends if:
> >>- no unacked data or
> >>- more than one unsent segment or
> >>- unsent segment has reached the maximum size
> >>
> >>Since you have TCP_MSS set to 1500, it will *not* send a
> 1200-byte frame
> >>directly, only if the last frame has been acknowledged or there
> are 2
> >>frames enqueued. Therefore, the nagle algorithm might help.
> >>
> >>Aside from that, TCP_MSS==1500 is not correct for ethernet. The
> MTU is
> >>1500, so TCP_MSS is 1460 (MTU - sizeof(ip_hdr) -
> sizeof(tcp_hdr)). Also,
> >>you seem to have ignored the comment on TCP_WND in opt.h:
> >>"This must be at least  * (2 * TCP_MSS) for things to
> work well"
> >>
> >>I know it's sad we don't have a step-by-step guide for port
> creation or
> >>memory configuration, but the already existing documentation
> (comments
> >>in code, doc directory in the code ZIP, wiki) should have helped
> to
> >>discover the limit of this setting...
> >>
> >>Oh, and I think it's also questionable to turn off asserts when
> hunting
> >>a problem. Unless you are really limited in processing speed and
> the
> >>application doesn't run without assertions turned on, you should
> only
> >>disable assertions once you know for sure your application runs
> stable.
> >>Before that, you only risk masking problems. We included
> those
> >>assertions for some reason, after
> all.

AVR.pcap
Description: Binary data

NonAVR.pcap
Description: Binary data