discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] NetBSD USB progress


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] NetBSD USB progress
Date: Mon, 26 Jun 2006 13:06:34 -0700
User-agent: Mutt/1.5.9i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]