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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
