[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] usrp_siggen.py underruns

From: Dominik Auras
Subject: Re: [Discuss-gnuradio] usrp_siggen.py underruns
Date: Thu, 12 Feb 2009 11:07:43 +0100
User-agent: Thunderbird (X11/20090105)


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]