Re: [Discuss-gnuradio] USB throughput numbers for NetBSD (and Linux)

[Joanne M Mikkelson]

Hi, sorry for my long delay, I was on vacation and then playing
catch-up.

> I'm not sure I followed the explanation for why on NetBSD the
> unidirectional case isn't equal to the sum of the bidirectional case.
> Could you try explaining again?  On second thought, is the problem
> that there's only one request in the h/w endpoint queue for a given
> endpoint and direction?  If so, I think you could get the completion
> interrupt service time out of the critical path by ensuring that there
> are always two requests queued in each direction, not just one.

Yes, as the driver is currently implemented, there is only one
request queued for a given endpoint at a time.  You're correct that
having more than one would reduce the interrupt service time's effect
on performance, but doing this will require changes to more than just
ugen.  The ehci driver will need some work in order to work properly
with more than one bulk request queued at a time.  We haven't changed
the ehci driver, so until that happens, the ugen driver will have to
use just a single request at a time.

> I'd also be interested in seeing how the throughput holds up with
> smaller transfer sizes and smaller total amount of buffer space.

Because we only have one request at a time, the throughput will
suffer as request sizes get smaller.  In my experience the total
buffer space need not be more than a few requests' worth (and the
numbers showed that having the buffers too large hurts performance),
but this testing wasn't with much computation load.  At least the
latency should still be improved over what we had with ugen before.

Using test_usrp_standard_rx and _tx, a block size of 1024 only works
with decimation 64/interpolation 128 (4 MB/s) and a block size of
4096 works with decimation 16/interpolation 32 (16 MB/s).  This is
without real-time scheduling, which isn't working.

Joanne