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 <[EMAIL PROTECTED]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
signature.asc
Description: Digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
