Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)

[Stephane Fillod]

On Wed, Jun 22, 2005 at 12:40:06PM +0200, Harald Welte wrote:
> On Tue, Jun 21, 2005 at 04:10:35PM -0700, John Gilmore wrote:
> > I'm picking up the Gigabit Ethernet conversation from a few weeks ago.
> 
Me too.

Please, add your inputs to the following page:

        http://comsec.com/wiki?USRPnotUSB


> > > I'm by no means arguing that the linux network stack is slow.  It's just
> > > not intended for an application which just wants to get big data streams
> > > with low latency and little overhead into userspace.
> > 
> > I'm surprised to hear you suggest this (though I note you didn't give
> > numbers, just generalizations like "enormous").  
> 
> I didn't state (or at leat want to state) that it was impossible to
> achieve multiple-gigabit data rates with the Linux network (or even
> TCP/IP) stack.
> 
> I just think that it is a horrible waste of cpu cycles and memory
> bandwidth, when all you want is to get large amounts of data from a
> local (cloe to the computer) device into an userspace application.  This
> is especially true if your userspace application is a cpu hog like
> digital signal processing algorithms ;)

This is were everybody does not agree. Several of us (most likely hams)
want to get large amounts of data from a *distant* (away from the computer)
device. IOW, I don't want to get my SHF signal through a long, expensive
and lossy cable, while I could have it sampled right at the antenna on
top of the pole, and data transported through Ethernet on a cheap CAT 5+ 
cable.

> > What thruput do YOU see using a good GigE card under Linux?  Can you move
> > 100 Mbytes/sec from user process to user process with TCP, across two GigE
> > interfaces and a GigE switch?  If so, it's doing much better than USB2
> > ever will, and much better than any version of FireWire.
> 
> I'm usually not doing client-to-server TCP benchmarks over my test
> networks, since I'm more interested in small-packet forwarding
> performance.  I'm sure with the right tuning (and probably some of the
> recent work on TCP BIC etc.) you can saturate a 1000-base-tx link with a
> single tcp flow, no question on that. 

First of all, we have to forget about TCP. If you have to resend, it'll
be too late. Besides, implementing TCP in a FPGA or anything that
must sustain 1Gbps is no piece of cake. I would rather argue in favor
of either raw Ethernet frames or more likely, UDP+RTP.
UDP/RTP is easy to handle in a FPGA (almost dumb header), can be routed 
by IP routers if need be, and RTP has interesting timestamp support 
plus re-odering if need be.

Now talking about small-packet forwarding, this is not going to be the
case with a NetSRP, unless you want really low latency.
Small-packets are really knee-bending, and people achieving good 
performance with them deserve respect. However, if we're going to fill 
up a 1Gbps pipe, there's no point in having small packets. The bigger
the packet, the better. For those affraid by the latency, just think
of what the OS will add up. USB too already suffers from it, and from
the kernel/user fence.

Of course, we would not be the first ones to do that, professional
video is already streamed like that, from what I can see every day.
  
-- 
Stephane