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 [EMAIL PROTECTED] _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
