Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Eric Blossom]

On Wed, Feb 11, 2009 at 10:26:25PM +0100, Dominik Auras wrote:
> Hi!
>
> An additional note: using usrp_siggen.py with sine, const and uniform at  
> 8 MHz bandwidth actually works. It is unlikely that my EHCI controller  
> does not support 32 MB/s on transmit.

OK.

> Could this be a timing problem? I mean, that the data is generated very  
> fast, but then the generator waits, e.g. because the buffer is full.  
> Does the double buffering of the TPB scheduler work as supposed? Using  
> STS scheduler with usrp_siggen didn't change anything.

Yes. Double buffering works.

> Summary:
> The application supports 12.5 complex MS/s (100 MB/s) if using USRP2,  

Uhh, 12.5 MS/s is 50MB/s (16-bit I&Q across the wire).

> but can't sustain 8 complex MS/s with USRP1, even though usrp_siggen.py  
> does support 8 MS/s with the generators sine,const and uniform on the  
> USRP1 (and test_usrp_standard_tx estimates an achievable rate of 32  
> MB/s). Furthermore, this behavior shows up on 2 different machines.

> Do you have an idea how I could benchmark the application, e.g. to  
> characterize the stream timing in front of the USRP?

Yes, there are lots of ways to do this.  In this particular case,
you're going to want to keep track of the worst case and average run
times. 

Are you really trying to use the Gaussian PRNG?  If so you'll have to
fix it.  If you look at the code for it, you'll see that it samples a
distribution until it gets something it likes.  The worst case time
can be huge.  The difference between the USRP1 and the USRP2 is the
amount of buffering available in the Tx path in the kernel and on the
board.

If you're not using the Gaussian PRNG, I suggest that you stop worrying
about it.  Virtually all of the signal processing algs we run are
designed so that there's not much difference between the average and
worst cases.

Eric