discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work we


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
Date: Wed, 10 May 2006 21:13:09 -0700
User-agent: Mutt/1.5.9i

On Sun, May 07, 2006 at 05:50:48PM -0500, LRK wrote:
> On Sun, May 07, 2006 at 12:06:31PM -0400, Greg Troxel wrote:
> > 
> > > It appears the attempts to read the USRP at more than 4 MB/s just
> > > lock and transfer no data.
> > 
> > What system?  Could you be more precise?  On NetBSD one gets missing
> > data according to the test program (presumably due to overruns in the
> > on-USRP buffer because USB transactions don't happen fast enough).
> > But nothing else bad happens.
> 
> This test used FreeBSD 6.1-RC and GR updated from CVS a couple of weeks
> ago. 1.8 GHz 686-class CPU, VIA VT6202 USB 2.0 controller on motherboard.
>  
> 
> This was discussed before and there seemed to be agreement that it does
> not look right:
> 
>   Running test_usrp_standard_rx with different decimation ( -D ) values.
> 
> xfered 1.34e+08 bytes in 68.1 seconds.  1.97e+06 bytes/sec.  cpu time = 0.3424
> noverruns = 3
> xfered 1.34e+08 bytes in 33.6 seconds.  3.998e+06 bytes/sec.  cpu time = 
> 0.3356
> noverruns = 1
> xfered 1.34e+08 bytes in 32.8 seconds.  4.088e+06 bytes/sec.  cpu time = 
> 0.3381
> noverruns = 167
> xfered 1.34e+08 bytes in 32.8 seconds.  4.091e+06 bytes/sec.  cpu time = 0.334
> noverruns = 83
> xfered 1.34e+08 bytes in 32.8 seconds.  4.092e+06 bytes/sec.  cpu time = 
> 0.3337
> noverruns = 41
> 
>   Note that the overrun counts go down as the speed should be going up.
> The USRP is queried for overruns and answers some with the error code.
> How many seems only to depend on the decimation rate. The first two tests
> may have different overrun counts but the last three are always the same
> as seen above (maybe +/- 1 count).

As currently implemented, the overrun/underrun detection is
implemented by the host library polling the USRP at approximately
10Hz, based on sample counting.  Thus the absolute number of overruns
returned does not mean what you might expect.  You should think of it
as more of a binary value:  overruns <= 1 implies things are "good".

Eric




reply via email to

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