> 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.
why? the *HOST CONTROLLER* schedules the data transfers. if the program doesnt do a read() theres nothing to schedule... (unless its isochronous endpoint, in which case the controller dma's for you in the background at the specified sampling rate). > (I can knock down a Plan9 system with 56 Kb/s USB serial traffic.) that sounds seriously scewed up. i have no issues here reading a usb stick on my x230 with xhci at 32MB/s, not using any fancy streaming optimization. no load at all. and this is just some garbage from the supermarket. > 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? is this a isochronous endpoint? in that case you would not have to worry much as the controller does all the timing for you in hardware. > 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). ahhhh! we'r talking about some crappy raspi here... probably with all caches disabled... never mind. > --lyndon -- cinap
