[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Darrell Harmon
Subject: Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
Date: Mon, 06 Jun 2005 17:28:56 -0500
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)

Harald Welte wrote:

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
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.
Unfortunately it seems that all the PCI express parts have their documentation only available under NDA.

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 ;)


Discuss-gnuradio mailing list
I would agree that ethernet is not ideal for this type of usage.

My plans have changed a bit. I am now not sure the DSP is fast enough to handle even a 10 MHz sampling rate. The DSP only board would have just been a side project which I though might be useful. I had already done the design work for the DSP portion of the board with the intention of using it along with an FPGA. The plan now is to have a board containing the DSP and FPGA, and a seperate board containing ADCs and DACs. If I have any FPGA IO left over, I will provide a connector for possible expansion such as 1394 or GMII.

Darrell Harmon
100x100mm SBC running GNU/Linux:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]