Ethernet performance

[sebestajan]

Posted on October 13, 2009 at 18:30

Ethernet performance

[sebestajan]

Posted on May 17, 2011 at 09:32

I found, one DMA channel is dedicated for Ethernet port in STR912. Did anyone measured the real one-way data rate for the longest possible TCP packets (1500 bytes)? For example Freescale ColdFire CPUs had been tested as a chargen TCP servers (operating system = TargetOS/TargetTCP) and here are the results:

- MCF5282 21.1 Mbps at 100.0% utilization

- MCF5474 74.8 Mbps at 96.7% utilization

Is STR912 comparable to this results?

Thanks,..

[sebestajan]

Posted on May 17, 2011 at 09:32

I am allways asking, why such simple information cannot be provided in datasheet, but now it is even worse, noone is able to do Ethernet measurement on development board.

[gu48bz]

Posted on May 17, 2011 at 09:32

Using the example applications the throughput is really bad. I did tests of downloading a 300K jpg image and was getting a throughput of just over 20KBytes/Second, very poor.

After lots of investigation I found this to be the very poor way the ST ENET driver is implemented + there are tons of optimisations to be done in uIP. The ST ENET driver in its supplied form has problems with truncating packets (causing browser retries) due to the way it uses the DMA controller and its polling nature. I wrote my own interface compatible one and can get files downloading at about 150KB/Sec which is fine for the application I want to use it for. I'm sure with extra work on the TCP/IP stack I could get that upto about 500KB/Sec

I personally wouldn't use this part as a dedicated webserver, just use it as a way to setup and control the product based around the ST912x.

I'd suggest poeple have a look at the Keil Ethernet driver as a reference, as its far superior to the ST supplied one. Downside is that it doesn't fit into the ST HAL framework that easily.

PS. Has anyone else noticed that if you use Ethernet with EMI then the ethernet doesn't work if you configure Port 8 as databus (alt out2)? If you leave it as startup defaults (inputs) then the EMI and Ethernet work fine. Spooooky!

[sebestajan]

Posted on May 17, 2011 at 09:32

Many thanks, ''stevesky'' for valuable info!

So I found, that ENET is native driver supplied originally by ST Mic. But I still can not believe, that the maximum data rate on Ethernet can not be higher than 500 kB/s. I think you mean the data rate using file FTP transfer when any TCP/IP stack is used (ENET for example). My target application is close to reception raw ethernet packets, without much processing on recognition IP address, creating sockets or ports, just reception or transmission raw ethernet data.

I found document AN2367 - Optimized memory copy routine for TCP/IP on the STR91x. There is written formula:

Cycles = 84 + NBytes*1.5

,where NBytes is the number of received bytes from ethernet and Cycles is the number is CPU clock cycles to receive NBytes of data. For example for reception packet of the length 1024 bytes we need 1620 clock cycles.

So, now small calculation on this formula (I suppose STR912 with 96 MHz system clock and reception ethernet packets of the length 1024bytes) we get aproximate data rate:

MaxEthernetRate = 96000000/1620*1024 = 60.68 MBytes/sec

,but we are also limited by ethernet speed (100Mbit/sec), then

MaxEthernetRate = 100000000/8 = 12 MBytes/sec

-------------------------------------------------------------

If I take a look to your 150 kBytes/sec and 96 MHz system clock, than i get roughly 640 CPU cycles for reception only one ethernet byte, possibly using DMA!

In conclusion, TCP/IP stack need incredible amount of processing time on received ethernet packets, or there is big mistake i did in my calculations?

[alandras]

Posted on May 17, 2011 at 09:32

Maybe this is to late, but my TCP routines are showing first signs of life. This is what I get so far (see atachment).

Andras

[sarao]

Posted on May 17, 2011 at 09:32

What software did you use to make the graph? Was it something ''off the shelf''? I typically use WireShark (formally Ethereal) to capture packets and then let it report statistics.

I'm just always looking for new tools that can provide good visual output of statistics.

Thanks.

-Jeremy

[alandras]

Posted on May 17, 2011 at 09:32

One more improvement in memcpy and Windows is having hard time allready.

utilization is around 50%

Andras

[alandras]

Posted on May 17, 2011 at 09:32

I use Ethereal too.

Version 0.10.12 (C) 1998-2005 Gerald Combs

Andras

[sebestajan]

Posted on May 17, 2011 at 09:32

Hello all,

Alandras, Great measurements, I will try to do same for UDP streaming in a loopback. I found the hardest limitation is performance, and performance is given by header processing overhead.

Simply in conclusion I can send UDP packets of the length 1472 Bytes at data rate about 8 MByte/sec. Shorter packets, about 200 Bytes long can be retransmitted at data rate up to 1 MByte/sec. Note that in loopback application is no more data copied in memory, just header is updated and ENET Tx DMA is used to send data back to the sender. I will try to do more advanced measurements later.

Now I have one question, did anyone experienced, that ENET Tx DMA configured in polling mode (NPOL_EN = 1) is sometimes not transmitting packets? For some minutes the circular buffering algorithm is working properly (data rate 500kB/sec, average packet length 1400 Bytes), but after few minutes it allways happens, that about every 10th packet is missing (measured by Ethereal receiver). After another few minutes packets are send again 100% correct. Error free communication is critical for me, so I can not allow any missing packets. Additionaly I check twice (two times in source code using two another approaches) packet header (address, length, checksum) and data before tranmsission, I also count the number of packets for tranmission and after ENET Tx DMA reports the packet is transmitted the number of indicated transmitted packets is also correct. Just the real situation is that Ethereal tool is missing packets sometimes.

So I am asking if anyone experienced and maybe resolved such unwelcome behavior as I described here?

Regards, Jan

[sarao]

Posted on May 17, 2011 at 09:32

I have an application where I transmit packets that are 1068 bytes (ENET + IP + UDP + My data) at a very high rate (I'll dig up the number later). I cannot afford for a packet to not get sent. I am transmitting images and if 1 packets gets dropped the whole image is lost. To my data I added a 4 byte counter to the transmit packet. At the receiver I check to make sure that all packet counters increase by 1. If 1 packets gets dropped (or comes out of sequence, but my small network I don't have that problem), I know immediately.

This allows me to keep the sender (the STR9) and the receiver (my PC) in synch.

I have not seen any stalls that you describe, but I will look more closely and report back.