Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD

[LRK]

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).


> > Changing the 'read' in libusb to just return as though it had
> > finished results in the 'test_usrp_standard_rx' giving similar
> > results at all speeds including the pattern of overrun errors.
> 
> You mean if you change the code to just skip the reads?  I don't see
> what you are trying to find out from this experiment.

I changed libusb to skip the actual reads. Since this happens fast, one
would expect the USRP to return every call as an error since no read was
actually done. The test doesn't actually check the data so it thinks it
got the data in the time it took to run the test and calculates the high
transfer rate:

xfered 1.34e+08 bytes in 0.157 seconds.  8.523e+08 bytes/sec.  cpu time = 
0.01688
noverruns = 614
xfered 1.34e+08 bytes in 0.0817 seconds.  1.642e+09 bytes/sec.  cpu time = 
0.01491
noverruns = 319
xfered 1.34e+08 bytes in 0.0422 seconds.  3.178e+09 bytes/sec.  cpu time = 
0.01432
noverruns = 164
xfered 1.34e+08 bytes in 0.0211 seconds.  6.372e+09 bytes/sec.  cpu time = 
0.01363
noverruns = 82
xfered 1.34e+08 bytes in 0.0207 seconds.  6.475e+09 bytes/sec.  cpu time = 
0.01324
noverruns = 41

> >  The transfer rate calculated is very fast so the overrun error
> > count seems to be a function of the USRP code rather than actual
> > overruns.
> 
> I don't see how this follows.

Since the modified test doesn't actually transfer data and now gets similar
results for the first two tests, it appears the last three probably never
actually transfer the data.

It also seems that if I command the USRP to send data but never issue a read,
it would return an error on every call to check overrun and the numbers from
the test are not powers of two.


Doesn't make sense to me so I mentioned it as a possible clue.


-- 
LRK
address@hidden