Re: [ECOS] ethernet performance <TCPIP guru question>

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

>          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

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