Re: SV: [ECOS] Gigabit Ethernet throughput on XScale

[Eric Doenges <Eric dot Doenges at DynaPel dot com>]

John Newlin wrote:

> TFTP is not a good comparison.  TFTP sends one data packet, and then 
> waits for an ACK.  This is why the performance is very bad.  If you 
> wrote your own protocol using a UDP connection you can get huge 
> performance gain.  The downside is that you have to handle dropped 
> packets, which you can do in a simple fashion (like TFTP does), or you 
> can do something much more fancy like TCP which is probably way overkill.
>

True, which is why I also quoted the maximum throughput I got using the
test programs which eCos supplies. These send UDP and TCP packets of
various sizes; the highest throughput is of course reached by using
large UDP packets (and is a lot higher than what I get with TFTP, but
just not anywhere near the theoretical maximum achievable with 100MBit/s
Ethernet).

[ ... ]

> For comparison, I have a 12.5Mhz part (yes, 12.5) that can send/receive 
> data at over 50Mb/s with 512 byte frame size.  With Jumbo frames I can 
> saturate a 100Mb/s line.  Assuming it scales with frequency, than you 
> would get a 32x 1.6Gb/s throughput at 400Mhz with 512b frames.  Now this 
> is without an OS, just a simple main(), and my own interrupt handlers.  
> There will be some performance hit for using an OS.

Im pretty sure your system doesn't need to copy the data around with the
CPU. I'm also guessing that in your case, the Ethernet controller is on
chip. Remember, my numbers are for a RealTek 8139, which is notorious
for being heavily CPU dependant because it's such a poor design. The
only reason anyone uses that part is because it's dirt cheap. Also,
I would guess that having a general purpose networking stack that can
handle all of IPv4 is going to have quite a performance hit compared to
a custom-built solution tailored for one specific use case.

> Another performance hit is that the ECOS network drivers do a copy on 
> both send and receive.  If you're looking for max performance I suggest 
> finding an OS that has a zero-copy driver, those copies kill 
> performance.  It's been awhile since I wrote a network driver for ECOS, 
> so this may not be an issue (Someone will correct me if I am wrong. :)  )

Actually, under eCos an Ethernet controller with a scatter/gather DMA
mechanism (and access to the complete memory space of the system) could
avoid copying packets to be sent out, though I don't think it would work
for received packets, since the generic Ethernet support will only give
you a buffer to place the data in once it knows which size the received
packet has, i.e. after the chip has started receiving a packet, when
it's too late to setup which DMA buffers to use (at least with all the
ethernet chips I've looked at so far, which are admittedly not many).
--
--------------------------------------------------------------------
|     Eric Doenges              |     DynaPel Laboratories GmbH    |
|     Tel: +49 89 962428 23     |     Fraunhoferstrasse 9/2        |
|     Fax: +49 89 962428 90     |     D - 85737 Ismaning, Germany  |
--------------------------------------------------------------------


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