Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Dominik Auras]

Hi!

Thanks for your answer.
And thanks Frank Brickle, too!

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

> 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. 
Hm run times may not be the appropriate performance measure in my case. 
The transmitter is of course designed to run continuously (until I 
interrupt him). What about interarrival times? I once had the idea to 
record every buffer update with a timestamp, the difference in the 
number of samples and the current processor the task is running on. Do 
you think that these samples may help to reveal the reason for the 
underruns in my transmitter code?

> 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.
No. Just for the case someone tries to reproduce the odd behavior, 
usrp_siggen is widely available. You may understand that I can't hand 
out my transmitter code. I could strip it down to the relevant parts, 
that reproduce the behavior, but since I don't know what could be the 
reason, this becomes an undirected search. Simply I hoped that the 
underruns of the Gaussian PRNG are caused by the same problem.

Will a big buffer in the USRP1 probably change the behavior? Am I right 
that with setting fusb_nblocks etc., the buffer size changes?

I have just confirmed that the Gaussian PRNG can't send at a bandwidth 
of near 8 MHz with the USRP2. That was definitely a bad example.

I will try to perform some measurements in the next week. Are there any 
gnuradio blocks, gnuradio utils available to find the average and worst 
cases? Oprofile will sample the whole application, not only the link 
between my last block and the USRP1 sink.
For your interest, I was measuring the throughput with a modified 
gr.throttle block. Instead of delaying the stream, I compute the 
momentaneous rate/throughput and average with a simple IIR (the rate 
estimate).

Thank you for your help.

Best regards
Dominik