This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ethernet performance <TCPIP guru question>


Thank you Andrew.  This makes more sense now.  I must have missed the
section on lost packets in the Stevens books.

Steve

Andrew Lunn wrote:

>>         I did a tcpdump from my Linux machine.  I've noticed two things.
>>First, the TCP window size in ECOS isn't sliding during the transfer. 
>>This might be confusing the sender, I'm not sure.  Also, I see a burst 
>>of data packets and ACKS from ECOS which appear good.  Then all of a 
>>sudden, ECOS starts to ACK to the same packet over and over.  After a
>>few more acks, the sequence resumes.  Is this normal?  Does this explain 
>>the slow network performance?
>>
> 
> That i think is happening is someone is loosing packets. This has two
> affects:
> 
> 1) eCos will keep sending ACKs for the packet before the one that is
> missing.  
> 2) The window size will not grow.
> 
> Both will result in poor performance. 
> 
> 
>>Here's the dump of the burst sequence running into the ACK sequence.
>>
>>Thanks.
>>
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1507369:1508817(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1508817:1510265(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1510265:1511713(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1511713:1513161(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: P 1513161:1514609(1448) ack 1 win 5792
>>
> 
> I think this packet above is getting lost.
> 
> 
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>
> 
> Here is eCos acking up to, but not including the last packet.
> 
> 
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1514609:1516057(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1516057:1517505(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1517505:1518953(1448) ack 1 win 5792
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1518953:1520401(1448) ack 1 win 5792
>>
> 
> The client keeps sending since its not reached its window size yet.
> 
> 
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>
> 
> eCos has not received the retransmit, so sends the ack again, just in
> case the ack got lost.
> 
> 
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1520401:1521849(1448) ack 1 win 5792
>>
> 
> More data
> 
> 
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1521849:1523297(1448) ack 1 win 5792
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: P 1513161:1514609(1448) ack 1 win 5792
>>
> 
> Here is the retransmit.
> 
> 
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>
> 
> This could happen is the ACK was already in the queue to be sent when
> the retransmit was received.
> 
> 
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>
> 
> This is strange. Why send the ack again?
> 
> 
>>1.1.1.2.55961 > 1.1.1.3.ftp-data: . 1523297:1524745(1448) ack 1 win 5792
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1513161 win 18824
>>
> 
> Here it finally acks the retransmit
> 
> 
>>1.1.1.3.ftp-data > 1.1.1.2.55961: . ack 1523297 win 8688
>>
> 
> and it acks all the data is had queued up until the last data packet.
> 
> 
> We need the time stamps to get a better idea. Why send that ack again?
> It could be part of a triple ack i suppose. The time stamps will make
> the obvious.
> 
>     Andrew
> 
> 


-- 
Stephen Polkowski
Centaur Technology
Austin, TX
(512) 418-5730


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]