On Mon, Jun 26, 2006 at 02:39:32PM -0400, Joanne M Mikkelson wrote: > Hi all, > > As was discussed here earlier (starting from > http://lists.gnu.org/archive/html/discuss-gnuradio/2006-05/msg00045.html > in the list archive), BBN has been working on improving the ugen(4) > driver for NetBSD. > > We've now implemented the changes to the driver and it's handling > transfer rates of at least 16 MB/s well. According to benchmark_usb.py > (and test_digital_loopback*) in gnuradio-examples, we are getting 32 > MB/s throughput (16 in each direction). Also, the test_usrp_standard_rx > and test_usrp_standard_tx programs indicate we're almost getting 25.6 > MB/s one-way (decimation 10 and interpolation 20), typically with 0-2 > overruns or underruns.
Definitely improved! > This is much improved over ~4 MB/s but the next step is to work on > optimizing what's needed to reach 32 MB/s reading or writing. If > you're interested, the current driver work can be found at: > http://acert.ir.bbn.com/cvs/?group=netbsd > primarily in: > http://acert.ir.bbn.com/viewvc/netbsd/netbsd/src/sys/dev/usb/ > > Also, interestingly, benchmark_usb always fails for 2 MB/s even > though the other rates are fine. I don't know yet why that might be, > but it always looks about like this, always around 940k samples: > gr_check_lfsr_32k: enter_SEARCHING at offset 0 (0x00000000) > gr_check_lfsr_32k: enter_LOCKED at offset 1452 (0x000005ac) > gr_check_lfsr_32k: enter_SEARCHING at offset 947028 (0x000e7354) > usb_throughput = 2M > ntotal = 1000000 > nright = 945576 > runlength = 0 > delta = 1000000 > FAILED > > Joanne There is a long outstanding bug in benchmark_usb that has it be unreliable. It's been a long time since I looked at it. The problem could be in the lfsr synchronization. test_usrp_standard_{tx, rx} seem to work fine, however. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
