[Discuss-gnuradio] usrp_siggen.py underruns

[Dominik Auras]

Hi!

I am currently observing an odd behavior of usrp_siggen.py.

When I start the program as follows

./usrp_siggen.py -f 2.40G -i 16 --gaussian

there are a lot of underruns (uU). However, for all other signal 
generation options except gaussian, it works fine (i.e. const, sine, 
uniform). Just to see, I have modified usrp_siggen to enable realtime 
scheduling. It didn't make the underruns go away.
My /etc/security/limits.conf contains the line
@usrp           -       rtprio          90
as suggested by a recent post to mailing list (though I increased the 
maximum priority). libgruel realtime functions sets the priority -30 
(checked with top). CPU usage is ~ 103%.

I have observed a similar behavior with my transmitter system, if I set 
the bandwidth to 8 MHz, which should be the maximum. To me, it seems 
like the GnuRadio USRP driver can hardly keep up with this rate (it 
should be the maximum supported). Measurements without the USRP sink 
revealed that my transmitter actually sustains rates over 30 MS/s. 
Though I didn't test what rate the gaussian noise source in usrp_siggen 
achieves if connected to a nullsink.
Further, with the USRP2, my transmitter sends continuously at a 
bandwidth of 12.5 MHz, no problem. However I need the USRP1 too.

My gnuradio version is from the svn trunk, but it's not the latest one. 
Some revision above 10000. If necessary, I could do a test with the 
latest revision.

The program test_usrp_standard_tx reports
xfered 1.34e+08 bytes in 4.19 seconds.  3.2e+07 bytes/sec.  cpu time = 0
0 underruns

My machine is a Core i7 940, 3 Gb RAM. I am using a fresh install of 
Ubuntu 8.10. The USRP owns his proper USB root hub, i.e. no other 
devices connected. Hence I think it is unlikely to be caused by the machine.

Best regards
Dominik