Hallo,
Keil RL-ARM ( RTOS and TCP Stack ) provides a EMAC driver for AT91SAM7X
microcontroller using AT91SAM7X-EK. I did take this EMAC driver and ported it to
AT91SAM9260-EK ( almost the same thing despite different IO pins and so on ).
The EMAC driver is being configured to use MII mode, PCLK is ~200Mhz and MCLK is
~100Mhz. The SAM9260-EK jumpers and resistors where changed in order to make it
use MII instead of RMII interface ( Factory Default setting ).
I'm testing TCP and UDP performance using an application that works fine on
several ARM based eval board like MCB2300, MCBSTR9 and AT91SAM7X-EK.
Here's what happens when I run those tests on AT91SAM9260-EK.:
UDP.:
Average transfer speed is 47.2Mbits.
TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).:
I use telnet as a client and the average throughput is 0.4Mbits. Telnet receives
data at maximum speed during a few milliseconds and then it issues a
TCPZeroWindow ( no more room to receive any data ). SAM9260-EK will retry
sending data after one second ( minimum possible retransmission time on RL-ARM
TCP Stack ). So on average the performance is tremendously reduced. During a few
milliseconds of data burst speed gets up to 24Mbits.
TCP SAM9260 as a client ( using tcp_connect () and a specific TCP application on
PC ).:
It will never connect. PC application and SAM9260-EK will carry a strange
conversation where nobody sens to understand each other ( .95 is SAM9260-EK and
.31 is my PC ).:
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.95 192.168.1.37 TCP 4 >
cadlock2 [SYN] Seq=0 WinX40 Len=0
No. Time Source Destination Protocol Info
2 0.000036 192.168.1.37 192.168.1.95 TCP
cadlock2 > 4 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
No. Time Source Destination Protocol Info
3 0.894013 192.168.1.37 192.168.1.95 TCP
cadlock2 > compressnet [SYN, ACK] Seq=0 Ack=0 Wine535 Len=0 MSS60
No. Time Source Destination Protocol Info
4 0.999346 192.168.1.95 192.168.1.37 TCP 4 >
cadlock2 [RST] Seq=0 WinX40 Len=0
No. Time Source Destination Protocol Info
5 0.999387 192.168.1.95 192.168.1.37 TCP rje >
cadlock2 [SYN] Seq=0 WinX40 Len=0
No. Time Source Destination Protocol Info
6 0.999410 192.168.1.37 192.168.1.95 TCP
cadlock2 > rje [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
No. Time Source Destination Protocol Info
7 1.998682 192.168.1.95 192.168.1.37 TCP rje >
cadlock2 [SYN] Seq=0 WinX40 Len=0
My application must send 40MB of data acquisition from the
microcontroller's SDRAM to a PC application that will do some work on
it.
Right now this download/upload ( depends on the point of view ) is taking ( 40MB
/ ( 0.4Mbits / 8 bits ) ) = 800 seconds!
Does anybody have attempted to use AT91SAM9260-EK and RL-ARM TCP/IP Stack with
better results?
Does anybody have any test application that I could use in order to see a
different scene? I don't mind sending my AT91SAM9260-EK EMAC drivers.
Thanks.
Alex
AT91SAM9260-EK EMAC issues using Keil RL-ARM TCP Stack
Started by ●June 12, 2008
Reply by ●June 12, 20082008-06-12
Alex
> TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).: I
> use telnet as a client and the average throughput is 0.4Mbits.
Telnet receives data at maximum speed during a few milliseconds and then
it issues a TCPZeroWindow ( no more room to receive any data ).
SAM9260-EK will retry sending data after one second ( minimum possible
retransmission time on RL-ARM TCP Stack ). So on average the performance
is tremendously reduced. During a few milliseconds of data burst speed
gets up to 24Mbits.
>
Ever tried to slow down the sender ?
I often see performance dropping down if there is only one sender.
Try to send in chunks after which the PC sends a (dummy) packet back to
the SAM9.
Why do you want to uses TCP anyway ? Sounds like UDP is the better solution.
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
> TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).: I
> use telnet as a client and the average throughput is 0.4Mbits.
Telnet receives data at maximum speed during a few milliseconds and then
it issues a TCPZeroWindow ( no more room to receive any data ).
SAM9260-EK will retry sending data after one second ( minimum possible
retransmission time on RL-ARM TCP Stack ). So on average the performance
is tremendously reduced. During a few milliseconds of data burst speed
gets up to 24Mbits.
>
Ever tried to slow down the sender ?
I often see performance dropping down if there is only one sender.
Try to send in chunks after which the PC sends a (dummy) packet back to
the SAM9.
Why do you want to uses TCP anyway ? Sounds like UDP is the better solution.
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
Reply by ●June 12, 20082008-06-12
Alex Ruiz wrote:
> Hallo,
>
Hello,
> Keil RL-ARM ( RTOS and TCP Stack ) provides a EMAC driver for AT91SAM7X
> microcontroller using AT91SAM7X-EK. I did take this EMAC driver and
> ported it to AT91SAM9260-EK ( almost the same thing despite different IO
> pins and so on ).
>
> The EMAC driver is being configured to use MII mode, PCLK is ~200Mhz and
> MCLK is ~100Mhz. The SAM9260-EK jumpers and resistors where changed in
> order to make it use MII instead of RMII interface ( Factory Default
> setting ).
>
> I'm testing TCP and UDP performance using an application that works fine
> on several ARM based eval board like MCB2300, MCBSTR9 and AT91SAM7X-EK.
>
> Here's what happens when I run those tests on AT91SAM9260-EK.:
>
> UDP.:
> Average transfer speed is 47.2Mbits.
>
Not bad...
> TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).:
> I use telnet as a client and the average throughput is 0.4Mbits. Telnet
> receives data at maximum speed during a few milliseconds and then it
> issues a TCPZeroWindow ( no more room to receive any data ). SAM9260-EK
> will retry sending data after one second ( minimum possible
> retransmission time on RL-ARM TCP Stack ). So on average the performance
> is tremendously reduced. During a few milliseconds of data burst speed
> gets up to 24Mbits.
>
> TCP SAM9260 as a client ( using tcp_connect () and a specific TCP
> application on PC ).:
> It will never connect. PC application and SAM9260-EK will carry a
> strange conversation where nobody sens to understand each other ( .95 is
> SAM9260-EK and .31 is my PC ).:
>
> No. Time Source Destination Protocol Info
> 1 0.000000 192.168.1.95 192.168.1.37 TCP 4 > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 2 0.000036 192.168.1.37 192.168.1.95 TCP cadlock2 > 4 [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> No. Time Source Destination Protocol Info
> 3 0.894013 192.168.1.37 192.168.1.95 TCP cadlock2 > compressnet [SYN,
> ACK] Seq=0 Ack=0 Wine535 Len=0 MSS60
>
> No. Time Source Destination Protocol Info
> 4 0.999346 192.168.1.95 192.168.1.37 TCP 4 > cadlock2 [RST] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 5 0.999387 192.168.1.95 192.168.1.37 TCP rje > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 6 0.999410 192.168.1.37 192.168.1.95 TCP cadlock2 > rje [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> No. Time Source Destination Protocol Info
> 7 1.998682 192.168.1.95 192.168.1.37 TCP rje > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> My application must send 40MB of data acquisition from the
> microcontroller's SDRAM to a PC application that will do some work on it.
>
IMHO, your sending window is not enough for this much of bandwidth. you can try
increasing your TCP window, in my SAM7X I use 10000 window size and I get
~6-8 mbps from it. Though UDP gives me ~10 mbps. Moreover, nagle algorithm may be
decreasing your overall throughput for better utilization. You may try disabling it,
however, I don't think telnet is a good test case. I would go with a simple PC program
which receives continuous data at periodic intervals preferably at MTU(1460) sized packets.
Regards,
Caglar
> Hallo,
>
Hello,
> Keil RL-ARM ( RTOS and TCP Stack ) provides a EMAC driver for AT91SAM7X
> microcontroller using AT91SAM7X-EK. I did take this EMAC driver and
> ported it to AT91SAM9260-EK ( almost the same thing despite different IO
> pins and so on ).
>
> The EMAC driver is being configured to use MII mode, PCLK is ~200Mhz and
> MCLK is ~100Mhz. The SAM9260-EK jumpers and resistors where changed in
> order to make it use MII instead of RMII interface ( Factory Default
> setting ).
>
> I'm testing TCP and UDP performance using an application that works fine
> on several ARM based eval board like MCB2300, MCBSTR9 and AT91SAM7X-EK.
>
> Here's what happens when I run those tests on AT91SAM9260-EK.:
>
> UDP.:
> Average transfer speed is 47.2Mbits.
>
Not bad...
> TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).:
> I use telnet as a client and the average throughput is 0.4Mbits. Telnet
> receives data at maximum speed during a few milliseconds and then it
> issues a TCPZeroWindow ( no more room to receive any data ). SAM9260-EK
> will retry sending data after one second ( minimum possible
> retransmission time on RL-ARM TCP Stack ). So on average the performance
> is tremendously reduced. During a few milliseconds of data burst speed
> gets up to 24Mbits.
>
> TCP SAM9260 as a client ( using tcp_connect () and a specific TCP
> application on PC ).:
> It will never connect. PC application and SAM9260-EK will carry a
> strange conversation where nobody sens to understand each other ( .95 is
> SAM9260-EK and .31 is my PC ).:
>
> No. Time Source Destination Protocol Info
> 1 0.000000 192.168.1.95 192.168.1.37 TCP 4 > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 2 0.000036 192.168.1.37 192.168.1.95 TCP cadlock2 > 4 [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> No. Time Source Destination Protocol Info
> 3 0.894013 192.168.1.37 192.168.1.95 TCP cadlock2 > compressnet [SYN,
> ACK] Seq=0 Ack=0 Wine535 Len=0 MSS60
>
> No. Time Source Destination Protocol Info
> 4 0.999346 192.168.1.95 192.168.1.37 TCP 4 > cadlock2 [RST] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 5 0.999387 192.168.1.95 192.168.1.37 TCP rje > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 6 0.999410 192.168.1.37 192.168.1.95 TCP cadlock2 > rje [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> No. Time Source Destination Protocol Info
> 7 1.998682 192.168.1.95 192.168.1.37 TCP rje > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> My application must send 40MB of data acquisition from the
> microcontroller's SDRAM to a PC application that will do some work on it.
>
IMHO, your sending window is not enough for this much of bandwidth. you can try
increasing your TCP window, in my SAM7X I use 10000 window size and I get
~6-8 mbps from it. Though UDP gives me ~10 mbps. Moreover, nagle algorithm may be
decreasing your overall throughput for better utilization. You may try disabling it,
however, I don't think telnet is a good test case. I would go with a simple PC program
which receives continuous data at periodic intervals preferably at MTU(1460) sized packets.
Regards,
Caglar
Reply by ●June 12, 20082008-06-12
42Bastian,
Data is sent by 9260 only when it receives an ACK from Receiver. One way to slow things down would be to reduce the packet size ( right now I'm using maximum size, near 1400 bytes ) to about 256 bytes, but that also doesn't avoid TCPZeroWindow being issued. Reducing packet size on average doesn't change things much.
The best option would be to have sam9260 as a client. For LPC2378, STR912FW44 and AT91SAM7X the same test application will output >10Mbits without any gasp or TCPZeroWindow.
I tried to use TFTP implemented on top of UDP but that introduced more problems on the design. Problems related to SDRAM latency, SSC_Handler execution time, SSC PDC transfer to SDRAM, and update file system on SDRAM all at the same time. It could be probably solved doing a good configuration on BUS MATRIX but since the original problem is being TCP I didn't wanted to spend much energy on that.
TCP was chosen because the idea is have less headache about data delivery as they are sent to PC once it requests it. The device will be put on local LAN facing high number of collision domains and so on.
Do you think UDP could be used only for acquisition exchange or for the whole thing? Maybe mix TCP for talking and UDP for acq data exchange would be better?
Thanks.
Alex
Thu, 12 Jun 2008 14:48:57 +0200, 42Bastian escreveu:
> Alex
>
> > TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).: I
> > use telnet as a client and the average throughput is 0.4Mbits.
> Telnet receives data at maximum speed during a few milliseconds and then
> it issues a TCPZeroWindow ( no more room to receive any data ).
> SAM9260-EK will retry sending data after one second ( minimum possible
> retransmission time on RL-ARM TCP Stack ). So on average the performance
> is tremendously reduced. During a few milliseconds of data burst speed
> gets up to 24Mbits.
> > Ever tried to slow down the sender ?
>
> I often see performance dropping down if there is only one sender.
> Try to send in chunks after which the PC sends a (dummy) packet back to
> the SAM9.
>
> Why do you want to uses TCP anyway ? Sounds like UDP is the better solution.
> --
> 42Bastian
>
> Note: SPAM-only account, direct mail to bs42@...
>
>
Data is sent by 9260 only when it receives an ACK from Receiver. One way to slow things down would be to reduce the packet size ( right now I'm using maximum size, near 1400 bytes ) to about 256 bytes, but that also doesn't avoid TCPZeroWindow being issued. Reducing packet size on average doesn't change things much.
The best option would be to have sam9260 as a client. For LPC2378, STR912FW44 and AT91SAM7X the same test application will output >10Mbits without any gasp or TCPZeroWindow.
I tried to use TFTP implemented on top of UDP but that introduced more problems on the design. Problems related to SDRAM latency, SSC_Handler execution time, SSC PDC transfer to SDRAM, and update file system on SDRAM all at the same time. It could be probably solved doing a good configuration on BUS MATRIX but since the original problem is being TCP I didn't wanted to spend much energy on that.
TCP was chosen because the idea is have less headache about data delivery as they are sent to PC once it requests it. The device will be put on local LAN facing high number of collision domains and so on.
Do you think UDP could be used only for acquisition exchange or for the whole thing? Maybe mix TCP for talking and UDP for acq data exchange would be better?
Thanks.
Alex
Thu, 12 Jun 2008 14:48:57 +0200, 42Bastian escreveu:
> Alex
>
> > TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).: I
> > use telnet as a client and the average throughput is 0.4Mbits.
> Telnet receives data at maximum speed during a few milliseconds and then
> it issues a TCPZeroWindow ( no more room to receive any data ).
> SAM9260-EK will retry sending data after one second ( minimum possible
> retransmission time on RL-ARM TCP Stack ). So on average the performance
> is tremendously reduced. During a few milliseconds of data burst speed
> gets up to 24Mbits.
> > Ever tried to slow down the sender ?
>
> I often see performance dropping down if there is only one sender.
> Try to send in chunks after which the PC sends a (dummy) packet back to
> the SAM9.
>
> Why do you want to uses TCP anyway ? Sounds like UDP is the better solution.
> --
> 42Bastian
>
> Note: SPAM-only account, direct mail to bs42@...
>
>
Reply by ●June 12, 20082008-06-12
Caglar,
The Strange thing is that my PC is the guy that is doing TCPZeroWindow.
I'm using Windows XP and used a utility called TCPOptimizer to setmy PC
Window up to 1MB. When I use whireshark to analyze what is going on my PC, TCP
Window always starts at 65535, no matter what size I do set using TCPOptimizer,
no matter what size is in windows reg files, wireshark will always display it
starting at 65535, bizarre.
When I use RL-ARM TCP Stack on SAM7X, having SAM7X as a CLIENT,sending data to PC, I get 12.5Mbits.
>try
>increasing your TCP window, in my SAM7X I use 10000 window size and I
get
>~6-8 mbps from it.
I'm not quite sure how to change this window size on this TCP stack, Ill check that out, the window problem is on PC side though.
You mean disabling Nagle on PC side? RL-ARM TCP Stack doesn't support Nagle.
I will work on a PC application other than Telnet.
Thanks for the hints.
Alex
Thu, 12 Jun 2008 16:49:32 +0300, Caglar Akyuz escreveu:
Alex Ruiz wrote:
>
>
> Hallo,
>
Hello,
> Keil RL-ARM ( RTOS and TCP Stack ) provides a EMAC driver for AT91SAM7X
> microcontroller using AT91SAM7X-EK. I did take this EMAC driver and
> ported it to AT91SAM9260-EK ( almost the same thing despite different IO
> pins and so on ).
>
> The EMAC driver is being configured to use MII mode, PCLK is ~200Mhz and
> MCLK is ~100Mhz. The SAM9260-EK jumpers and resistors where changed in
> order to make it use MII instead of RMII interface ( Factory Default
> setting ).
>
> I'm testing TCP and UDP performance using an application that works fine
> on several ARM based eval board like MCB2300, MCBSTR9 and AT91SAM7X-EK.
>
> Here's what happens when I run those tests on AT91SAM9260-EK.:
>
> UDP.:
> Average transfer speed is 47.2Mbits.
>
Not bad...
> TCP SAM9260 as a server ( using tcp_listen() and telnet on PC ).:
> I use telnet as a client and the average throughput is 0.4Mbits. Telnet
> receives data at maximum speed during a few milliseconds and then it
> issues a TCPZeroWindow ( no more room to receive any data ). SAM9260-EK
> will retry sending data after one second ( minimum possible
> retransmission time on RL-ARM TCP Stack ). So on average the performance
> is tremendously reduced. During a few milliseconds of data burst speed
> gets up to 24Mbits.
>
> TCP SAM9260 as a client ( using tcp_connect () and a specific TCP
> application on PC ).:
> It will never connect. PC application and SAM9260-EK will carry a
> strange conversation where nobody sens to understand each other ( .95 is
> SAM9260-EK and .31 is my PC ).:
>
> No. Time Source Destination Protocol Info
> 1 0.000000 192.168.1.95 192.168.1.37 TCP 4 > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 2 0.000036 192.168.1.37 192.168.1.95 TCP cadlock2 > 4 [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> No. Time Source Destination Protocol Info
> 3 0.894013 192.168.1.37 192.168.1.95 TCP cadlock2 > compressnet [SYN,
> ACK] Seq=0 Ack=0 Wine535 Len=0 MSS60
>
> No. Time Source Destination Protocol Info
> 4 0.999346 192.168.1.95 192.168.1.37 TCP 4 > cadlock2 [RST] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 5 0.999387 192.168.1.95 192.168.1.37 TCP rje > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> No. Time Source Destination Protocol Info
> 6 0.999410 192.168.1.37 192.168.1.95 TCP cadlock2 > rje [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> No. Time Source Destination Protocol Info
> 7 1.998682 192.168.1.95 192.168.1.37 TCP rje > cadlock2 [SYN] Seq=0
> WinX40 Len=0
>
> My application must send 40MB of data acquisition from the
> microcontroller's SDRAM to a PC application that will do some work on it.
>
IMHO, your sending window is not enough for this much of bandwidth. you can try
increasing your TCP window, in my SAM7X I use 10000 window size and I get
~6-8 mbps from it. Though UDP gives me ~10 mbps. Moreover, nagle algorithm may be
decreasing your overall throughput for better utilization. You may try disabling it,
however, I don't think telnet is a good test case. I would go with a simple PC program
which receives continuous data at periodic intervals preferably at MTU(1460) sized packets.
Regards,
Caglar
MARKETPLACE
You" target="_blank" rel="nofollow">http://media.adrevolver.com/adrevolver/href?banner9161&place&143&url_=http://tc.deals.yahoo.com/tc/blockbuster/display.com?cidi00028">You rock! Blockbuster wants to give you a complimentary trial of Blockbuster Total Access./>
__._,_.___
__,_._,___
Reply by ●June 12, 20082008-06-12
Alex Ruiz wrote:
> Caglar,
>
> The Strange thing is that my PC is the guy that is doing TCPZeroWindow.
> I'm using Windows XP and used a utility called TCPOptimizer to set�my PC
> Window up to 1MB. When I use whireshark to analyze what is going on my
> PC, TCP Window always starts at 65535, no matter what size I do set
> using TCPOptimizer, no matter what size is in windows reg files,
> wireshark will always display it starting at 65535, bizarre.
>
> When I use RL-ARM TCP Stack on SAM7X, having SAM7X as a CLIENT,�sending
> data to PC, I get 12.5Mbits.
>
>>try
>>increasing your TCP window, in my SAM7X I use 10000 window size and I get
>>~6-8 mbps from it.
>
> I'm not quite sure how to change this window size on this TCP stack,
> I�ll check that out, the window problem is on PC side though.
>
I thought .95 was 9261 and from your packet capture 5840 was 9261's TCP send
window. That's why I thought you should increase 9261's window. Actually, I re-read
your capture output and I didn't understand really what was going on.
> You mean disabling Nagle on PC side? RL-ARM TCP Stack doesn't support Nagle.
>
Both if possible, but only PC side is also helpful I guess. However, this has less
importance until you have more helpful test case.
> I will work on a PC application other than Telnet.
>
I think this will light the problem.
Regards,
Caglar
> Caglar,
>
> The Strange thing is that my PC is the guy that is doing TCPZeroWindow.
> I'm using Windows XP and used a utility called TCPOptimizer to set�my PC
> Window up to 1MB. When I use whireshark to analyze what is going on my
> PC, TCP Window always starts at 65535, no matter what size I do set
> using TCPOptimizer, no matter what size is in windows reg files,
> wireshark will always display it starting at 65535, bizarre.
>
> When I use RL-ARM TCP Stack on SAM7X, having SAM7X as a CLIENT,�sending
> data to PC, I get 12.5Mbits.
>
>>try
>>increasing your TCP window, in my SAM7X I use 10000 window size and I get
>>~6-8 mbps from it.
>
> I'm not quite sure how to change this window size on this TCP stack,
> I�ll check that out, the window problem is on PC side though.
>
I thought .95 was 9261 and from your packet capture 5840 was 9261's TCP send
window. That's why I thought you should increase 9261's window. Actually, I re-read
your capture output and I didn't understand really what was going on.
> You mean disabling Nagle on PC side? RL-ARM TCP Stack doesn't support Nagle.
>
Both if possible, but only PC side is also helpful I guess. However, this has less
importance until you have more helpful test case.
> I will work on a PC application other than Telnet.
>
I think this will light the problem.
Regards,
Caglar
Reply by ●June 12, 20082008-06-12
On that dump I sent there's no TCPZeroWindow being happening. That dump shows what happens on an attempt to connect to SAM9260 running TCP as a client. That dump doens't makes sense at all for me too.
Bellow is what a TCPZeroWindow looks like. Win=0 does not mean TCP ZeroWindow, it really depends on what is being transmited at that package: ( .95 is PC telling .95 that it has no room for more data ).
No. Time Source Destination Protocol
Info
197 5.806606 192.168.1.99 192.168.1.95 TCP
[TCP ZeroWindow] pdps > cslistener [ACK] Seq=7 Ack192 Win=0
Len=0
No. Time Source Destination Protocol
Info
198 9.823987 192.168.1.95 192.168.1.99 TCP
[TCP Retransmission] cslistener > pdps [PSH, ACK] Seq793 Ack=7 WinX40
Len16
No. Time Source Destination Protocol
Info
199 9.824108 192.168.1.99 192.168.1.95 TCP
[TCP ZeroWindow] pdps > cslistener [ACK] Seq=7 Ack192 Win=0
Len=0
No. Time Source Destination Protocol
Info
200 10.715301 192.168.1.99 192.168.1.95 TCP
[TCP Window Update] pdps > cslistener [ACK] Seq=7 Ack192 Win760 Len=0
No. Time Source Destination Protocol
Info
201 10.715760 192.168.1.99 192.168.1.95 TCP
pdps > cslistener [PSH, ACK] Seq=7 Ack192 Win760 Len=3
I'll try to rewrite the EMAC driver in order to use RMII instead of MIIinterface to check if it works with better lucky.
Thanks for the light.
Alex
Thu, 12 Jun 2008 18:40:46 +0300, Caglar Akyuz escreveu:
Alex Ruiz wrote:
>
>
> Caglar,
>
> The Strange thing is that my PC is the guy that is doing TCPZeroWindow.
> I'm using Windows XP and used a utility called TCPOptimizer to set�my PC
> Window up to 1MB. When I use whireshark to analyze what is going on my
> PC, TCP Window always starts at 65535, no matter what size I do set
> using TCPOptimizer, no matter what size is in windows reg files,
> wireshark will always display it starting at 65535, bizarre.
>
> When I use RL-ARM TCP Stack on SAM7X, having SAM7X as a CLIENT,�sending
> data to PC, I get 12.5Mbits.
>
>>try
>>increasing your TCP window, in my SAM7X I use 10000 window size and I get
>>~6-8 mbps from it.
>
> I'm not quite sure how to change this window size on this TCP stack,
> I�ll check that out, the window problem is on PC side though.
>
I thought .95 was 9261 and from your packet capture 5840 was 9261's TCP send
window. That's why I thought you should increase 9261's window. Actually, I re-read
your capture output and I didn't understand really what was going on.
> You mean disabling Nagle on PC side? RL-ARM TCP Stack doesn't support Nagle.
>
Both if possible, but only PC side is also helpful I guess. However, this has less
importance until you have more helpful test case.
> I will work on a PC application other than Telnet.
>
I think this will light the problem.
Regards,
Caglar
__._,_.___
__,_._,___
