This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ethernet performance <TCPIP guru question>
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: Stephen Polkowski <stephen at centtech dot com>
- Cc: eocs <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 25 Apr 2002 09:47:36 +0200
- Subject: Re: [ECOS] ethernet performance <TCPIP guru question>
- References: <3CC74F46.1050502@centtech.com>
> 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