cinap_len...@felloff.net writes: > > The big one is USB. disk/radio->kernel->user-space-usbd->kernel->applicati > on. > > Four copies. > > that sounds wrong. > > usbd is not involved in the data transfer.
You're right, I was wrong about 'usbd'. In the bits of testing I've done with this, 'usbd' is replaces with a user space file server that abstracts the hardware and presents a useful file system interface. (E.g. along the lines of the gps filesystem interface.) To address Hiro's comments, I have no benchmarks on Plan 9, because the SDR code I run does not exist there. But I do have experience with running SDR on Linux and FreeBSD with hardware like the HackRF One. That hardware can easily saturate a USB2 interface/driver on both of those operating systems. Given my experience with USB on Plan 9 to date, it's a safe bet that all the variants would die when presented with that amount of traffic. (I can knock down a Plan9 system with 56 Kb/s USB serial traffic.) I can see about twisting up some code that would read the raw I/Q data from the SDR via USB and see how it stands up. But the real question is what kind of delay, latency, and jitter will there be, getting that raw I/Q data from the USB interface up to the consuming application? Eliminating as much of the copy in/out WRT the kernel cannot but help, especially when you're doing SDR decoding near the radios using low-powered compute hardware (think Pies and the like). --lyndon
