Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - GBit Ethernet Speed: (9 Items)
   
GBit Ethernet Speed  
we want to implement a GBit Ethernet connection in our SoC in order to
transfer very huge amounts of data. I've got no idea, how to calculate the real transfer rate within a given system.
The most important question I've got to clarify is: Do we have a chance to reach transfer rates above 500MBit/sec with 
the following system configuration?
Our system will be:
-	XILINX Virtex 4 (PPC, 300MHz)
-	TEMAC IP-Core (Tri-Band Ethernet MAC => Gigabit IP-Core by XILINX)
-	QNX 6.3.0, SP3. Could be upgraded, if needed.

We’d prefer – of course – utilizing the standard components and protocol stack (FTP etc.). 
Is there a chance to do that?

Thank you, best regards,
Thoralf
RE: GBit Ethernet Speed  
Hi Thoralf:

	Some benchmarking that we did on those parts a while back would
suggest that this rate is not likely to be achievable. The CPUs are
relatively slow and the memory subsystem also appeared to limit the maximum
throughput.  There are things that could be done with io-pkt to possibly
increase the throughput, but even then I wouldn't count on reaching a
500Mbps transfer rate.

We generally use the TTCP application as a simple mechanism for measuring
throughput.

	Robert.


-----Original Message-----
From: Thoralf Baum [mailto:thoralf.baum.ext@siemens.com] 
Sent: Tuesday, January 22, 2008 6:01 AM
To: technology-networking
Subject: GBit Ethernet Speed

we want to implement a GBit Ethernet connection in our SoC in order to
transfer very huge amounts of data. I've got no idea, how to calculate the
real transfer rate within a given system.
The most important question I've got to clarify is: Do we have a chance to
reach transfer rates above 500MBit/sec with the following system
configuration?
Our system will be:
-	XILINX Virtex 4 (PPC, 300MHz)
-	TEMAC IP-Core (Tri-Band Ethernet MAC => Gigabit IP-Core by XILINX)
-	QNX 6.3.0, SP3. Could be upgraded, if needed.

We'd prefer - of course - utilizing the standard components and protocol
stack (FTP etc.). 
Is there a chance to do that?

Thank you, best regards,
Thoralf


_______________________________________________
Technology
http://community.qnx.com/sf/go/post4492
Re: RE: GBit Ethernet Speed  
> 
> -----Original Message-----
> From: Thoralf Baum [mailto:thoralf.baum.ext@siemens.com] 
> Sent: Tuesday, January 22, 2008 6:01 AM
> To: technology-networking
> Subject: GBit Ethernet Speed
> 
> we want to implement a GBit Ethernet connection in our SoC in order to
> transfer very huge amounts of data. I've got no idea, how to calculate the
> real transfer rate within a given system.
> The most important question I've got to clarify is: Do we have a chance to
> reach transfer rates above 500MBit/sec with the following system
> configuration?
> Our system will be:
> -	XILINX Virtex 4 (PPC, 300MHz)
> -	TEMAC IP-Core (Tri-Band Ethernet MAC => Gigabit IP-Core by XILINX)
> -	QNX 6.3.0, SP3. Could be upgraded, if needed.
> 
> We'd prefer - of course - utilizing the standard components and protocol
> stack (FTP etc.). 
> Is there a chance to do that?
> 
> Thank you, best regards,
> Thoralf
> 


If the processor is 300Mzh and let's say it's 1 instruction per cycle, you have 50MBytes coming in that means 6 
instruction per bytes.  Even if the IP core has 0 overhead the CPU will simply be swamped.

Re: RE: GBit Ethernet Speed  
Thank you very much.

The calculation of a bytewise sending powered by the cpu leads directly to the core of my problem:
The XILINX IP Core (and I think, most HighSpeed Ethernet controllers) supports sending and receiving using DMA and multi
 buffer mode (scatter/gather or PingPong).

The question is: Does the QNX TCP stack make usage of such features? In other words: Are there any bottlenecks where the
 cpu has to copy each single word from one place to another place?

If so, the calculation above would meet the reality - unfortunately...

best regards,
Thoralf
RE: RE: GBit Ethernet Speed  
Hi Thoralf:

There is inherently a copy between the application process space and stack
process space (a message pass).  The xtemac driver that we have in house
uses DMA and scatter / gather and everything within the stack is essentially
"zero-copy", but you still have to move the data from the stack to the
application if you're using the standard protocols.

While there are things that you can do to get around this (putting your app
inside of the stack as a filter or its own protocol, setting up an area of
shared memory that you can use for raw Ethernet packets and then passing
pointers into / out of the stack through a filter devctl interface, other
workarounds), you'll be going to extraordinary lengths and I still don't
have a strong feeling that you'll achieve that rate.  Using the new
networking stack (io-pkt) with a newly written driver that will allow you to
use Jumbo packets (not supported in io-net) will give you a significant
performance boost, but, even then, if the rate is at all achievable, I'll
bet that the CPU occupancy will be 100%.

What will the application be doing with the data? If it has to touch every
byte anyway, you might want to do a basic memory access test to see if the
application can even do what it has to do without networking involved at
all...  If the app uses up a significant portion of CPU, then you'll know
for sure that the stack won't be able to push the data through fast enough.


	Robert.



 

-----Original Message-----
From: Thoralf Baum [mailto:thoralf.baum.ext@siemens.com] 
Sent: Wednesday, January 23, 2008 5:29 AM
To: technology-networking
Subject: Re: RE: GBit Ethernet Speed

Thank you very much.

The calculation of a bytewise sending powered by the cpu leads directly to
the core of my problem:
The XILINX IP Core (and I think, most HighSpeed Ethernet controllers)
supports sending and receiving using DMA and multi buffer mode
(scatter/gather or PingPong).

The question is: Does the QNX TCP stack make usage of such features? In
other words: Are there any bottlenecks where the cpu has to copy each single
word from one place to another place?

If so, the calculation above would meet the reality - unfortunately...

best regards,
Thoralf

_______________________________________________
Technology
http://community.qnx.com/sf/go/post4525
Re: RE: RE: GBit Ethernet Speed  
Hi Robert,

thank you very much. This was exactly what I need to know.

Hi Malte:
We cannot use any compression algorithm, unfortunately.

I’ll tell something about our new project: We’re going to develop a device to read real time, high resolution video 
data from another device. Because of the resolutions and frame rates forced by our customer we will need to implement 
the whole transfer system within the FPGA logic of the Virtex 4. That means the pixel data will get into RAM without any
 processor usage. 

Now there’s another requirement to transfer the original data stream over a GBit Ethernet connection. No compression 
should be made. The only step allowed to reduce the data rate is to reduce frame rate. At original frame rate we would 
have a data stream of about 7,1GBit/s.

So it’s our task to transfer the data as fast as possible, at a constant bit rate. But we also have to think about our 
development budget. And so we would prefer the usage of the QNX built in protocol stack. Of course, we should think 
about a home made, special protocol stack too.

Best regards,
Thoralf

Re: RE: RE: GBit Ethernet Speed  
I understand that you can't use MPEG2 or similar video compression, but at least bit-stream compression should be 
applied to reduce the HUGE amount of data coming over the line. Maybe a logic in the FPGA could do the bit-stream 
decompression on the fly.

As next step I guess you need to alter the io-pkt or network driver to write the data into a Shared Memory Object. This 
object then will be also mapped in by your application processing the data.
Re: RE: RE: GBit Ethernet Speed  
Hello,

that's a good idea. This would be the best we can do in our case.
The only thing I suspect is that the noisy pixel data will not be shrinked too much. The same problem we would have 
using a lossless picture compression algorithm.
But we will think about compromises in this direction.

Thank you,
Thoralf
Re: RE: GBit Ethernet Speed  
It would also be interesting to know what the data is - maybe it can be compressed. Depending on the data, a light 
compression (e.g. just compress equal bytes) would not severely eat CPU cycles but could reduce the amount of data to be
 transferred. More complex compression algorithms may be applicable, depending on the ratio of saved bytes vs.
(de)compression CPU usage.