Hi Kieran,
NonAVR retransmit after a specified amount of timeout (RTO) or
transmit pool is near full. The reason you don't see any
retransmission is because the time-out was set very high on purpose.
Requiring ACK for every two TCP packets is not good for high-speed
communication:
Since the ACK can take a long time to come back if the final product
is deployed over the internet. For example, if it takes 0.5 seconds
for ACK to come back, which is shorter than RTO, then the maximum
data rate is 2*1460*2, where the first 2 represents the two packets
before the ACK, 1460 is the max payload, and the second 2 is max ACK
within a second, and the result is only merely 5.8KB/sec
Could you reconsider my request? (not necessary the same as NonAVR,
but something better than the current lwip)
Thanks!
Chen
On Fri, 2010-12-10 at 15:50 -0500, Chen wrote:
>
> 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?
I really don't like the NonAVR version. What will cause it to start
retransmission? It seems to have ignored the TCP retransmission timeout
and is just carrying on sending new data regardless. I would be against
any change to make lwIP behave more like this. I'm happy to see it
carry on sending data until the RTO fires, but after that we must assume
something is wrong and stop sending new data to retransmit old packets.
Kieran
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
