discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] FreeBSD - more


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] FreeBSD - more
Date: Thu, 13 Oct 2005 10:06:28 -0700
User-agent: Mutt/1.5.6i

On Thu, Oct 13, 2005 at 09:24:35AM -0500, LRK wrote:
> On Thu, Oct 13, 2005 at 12:35:50AM -0700, Eric Blossom wrote:
> > > 
> > > I believe it was gnuradio-examples/python/usrp/benchmark_usb.py that
> > > triggered the problem here.
> > 
> > That should be the right answer, but is not completely reliable.
>  
> Since I don't have a Tx board, I couldn't run that test "as is". It
> tries to open the Tx board first. I'll do a little hacking on something
> and then see if I encounter the problem doing something similar with
> two Rx boards or opening the Rx board first.
> 
> 
> > Try running test_usrp_standard_rx with different values of the 
> > -D <decim> option.  Start with -D 128, then try -D 64, -D 32, -D 16, -D 8.
> > 
> >   -D 128    500kS/sec      2MB/sec
> >   -D  64    1MS/sec        4MB/sec
> >   -D  32    2MS/sec        8MB/sec
> >   -D  16    4MS/sec       16MB/sec
> >   -D   8    8MS/sec       32MB/sec
>  
> These tests show the apparent 4MB/s limit which Wulf has mentioned. There
> also seem to be something that is related to the 4MB points in the actual
> transfers. I have run tests with 3.9 MB transfers with no overruns and 
> 4.0 MB transfers with exactly 1. I would also expect the noverruns to go up
> as -D goes down.
> 
> Clues there. Just don't know what they mean yet.

Don't use the -M option with small values.  You won't get a good
answer unless you let it run for 10 - 20 seconds or so.  We want to
know what it will sustain over an extended period of time.  You'll
probabably want to run each test a couple of times too.  [There may be
a problem where the fifo's aren't flushed between runs which is
another reason to use longer test periods.  I think that may be why
usb_benchmark doesn't work as expected.]

> ./test_usrp_standard_rx -M 16 -D 128
> xfered 1.68e+07 bytes in 8.4 seconds. 1.998e+06 bytes/sec. cpu time = 0.1549
> noverruns = 1
> ./test_usrp_standard_rx -M 16 -D 64
> xfered 1.68e+07 bytes in 4.19 seconds. 4e+06 bytes/sec. cpu time = 0.1501
> noverruns = 0
> ./test_usrp_standard_rx -M 16 -D 32
> xfered 1.68e+07 bytes in 4.11 seconds. 4.078e+06 bytes/sec. cpu time = 0.152
> noverruns = 20
> ./test_usrp_standard_rx -M 16 -D 16
> xfered 1.68e+07 bytes in 4.1 seconds. 4.094e+06 bytes/sec. cpu time = 0.155
> noverruns = 10
> ./test_usrp_standard_rx -M 16 -D 8
> xfered 1.68e+07 bytes in 4.1 seconds. 4.095e+06 bytes/sec. cpu time = 0.1483
> noverruns = 5

Looks like you get something on the order of 4MB/sec.
Not surprising given that it's not pipelining the requests.

If you've got a logic analyzer available and want to play, I can give
you some suggestions of things to watch.  I suspect that what you'll
see are *highly* variable inter-packet arrival times.

> > Likewise, try test_usrp_standard_tx with different values of the 
> > -I <interp> option.  Start with -I 256, then try -I 128, 64, 32, 16.
>  
> Can't, no Tx board.

The measurement should work fine with no Tx board.

Eric




reply via email to

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