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

[Harald Welte]

On Thu, May 26, 2005 at 07:50:08AM -0700, John Gilmore wrote:
> You prefer USB2 over firewire or gigabit Ethernet?  It would be nice
> to have a radio spectrum interface that didn't have USB2's bandwidth
> as its bottleneck.  Gig E is always full duplex (no collisions between
> transmit and receive), and offers higher bandwidth.  GigE switches are
> now in the $100 range and dropping fast (or you can plug the board
> directly into a computer's GigE port, if it isn't on the Internet at
> the same time, e.g. for mobile laptop use).

While Gigabit Ethernet is certainly a ubiquitous and cheap interface, I
wouldn't recommend it's use for USPR or alike devices.

To those of you wo don't know my background: I'm a Linux kernel-level
networking hacker for a number of years, with special focus on
high-performance forwarding/packet filtering.

I'm actually not referring to the Ethernet hardware side, but to the
software stack.  Unless you want to write a special 'ursp network stack'
that sits directly on top of the hardware driver (like PF_RING, but
that's read only), you will go through the whole 'normal' Linux network
stack.  

For every packet you process, there's an enormous amount of overhead
you're going through, even if you choose to not use IP and play some
tricks with raw sockets.   Due to the sockets-based interface, you will
have additional copying of the data.

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.  

An USRP/gnuradio like application would not require any features of a
network stack, like addressing, multiplexing, ...

So I think there's too much of an 'impedance mismatch' between what
gnuradio needs and a GigE/network stack can provide.

Also, there are issues with the physical/link layer, too. So even if you
skip the whole TCP/IP stack and exchange native ethernet frames, you
have to have some form of (software-implemented) higher-level protocol
dealing with frame loss and reorering. While usually you don't see
reordering of packets, there is no guarantee that you won't see
reordering, at least not as soon as you have some kind of switch between
the devices and the host.  If you have SMP on the host, then you might
get reordering of packets because of the multiple concurrent cpu's
serving interrupts of the single device while experiencing different
processing overhead.

Ideally we want a PCI(-X,-E) attaching A/D converter hardware that can
do DMA the data directly into pinned userspace buffers. 

If you want to go for external connectors, I would go for
firewire/ieee1394.  There's a good example for streaming high-bandwidth
data: The dv1394 as used by DV camcorders. It uses isochronous channels
on the 1394 bus, and the linux dv1394 driver provides a mmap() interface
for receive and send from/to userspace programs.

just my two (euro-)cents ;)

-- 
- Harald Welte <address@hidden>                         http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

signature.asc
Description: Digital signature