From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lyndon Nerenberg To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83091.1539128604.1@orthanc.ca> Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2018 16:43:24 -0700 Message-Id: <7aa1f8ae5b628668@orthanc.ca> Cc: Lyndon Nerenberg Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: ea7b6af2-ead9-11e9-9d60-3106f5b1d025 cinap_lenrek@felloff.net writes: > > The big one is USB. disk/radio->kernel->user-space-usbd->kernel->appl= icati > 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