lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: decreasing throughput ends in lwip-collapse


From: Andre Puschmann
Subject: [lwip-users] Re: decreasing throughput ends in lwip-collapse
Date: Sat, 28 Oct 2006 13:01:25 +0200
User-agent: Thunderbird 1.5.0.4 (X11/20060619)

Hello,

sorry for the delay once again.
now I can give some more detailed information about what's going on. I
attached a ethereal capture file and a log file.

As you can see in the capture file at packet #27 and following the board
sends two frames from which the first one gets lost.
Windows acknowledges the last successfully received packet the second
time and so, after the RTO expired, lwip sends the lost (really?) packet
again. Than windows ACKs both packets.
what now happens is really strange I think, as lwip doesn't send the
next new package but a package already ACKed (packet #30 in capture) and
this even after a long delay.

Another odd thing is that once the connection gets into this state it
never leaves it. I mean at the beginning everything runs good up to one
certain point of time.

In the log file you can see the tcp-receive debug output (I added a few
more statements). I guess it shows that the windows ACK after the
retransmitted package isn't processed proper, since it as recognized as
an dup-ACK but it isn't.


Any comments and suggestions are more than welcome.


Best Regards


Andre



ethereal-capture: http://www.puschmann.net/public/log_forgotten_acks_new.cap

log-file:
http://www.puschmann.net/public/log_forgotten_acks_new.txt


Kieran Mansley wrote:
> On Tue, 2006-10-24 at 22:41 +0200, Andre Puschmann wrote:
> 
>> i also attached to ethereal captures .. first one shows a normal
>> transfer of the file 200msecs ..
> 
> It's quite hard to work with the text summary from ethereal as you can't
> see many of the useful details from the packets.  If you have the proper
> capture files, I can take a look at that.
> 
>> the "capture_download_nok"-file shows the droped packets and the
>> resulting delay (see time row).
> 
> You're right that there seems to be some dropped packets causing
> retransmissions, but I can't say anything more than that from the text
> summary.  Is this a capture at the WinXP end of the connection?  WinXP
> seems to be waiting a very long time before trying to retransmit (e.g. 6
> seconds) which is a bit odd.
> 
> Kieran





reply via email to

[Prev in Thread] Current Thread [Next in Thread]