Re: [Discuss-gnuradio] Struggling with gr-perf-monitorx

[Marcus Müller]

Hi Dennis,
> I'm looking for why I am getting "O"s on the console but I don't see
> full buffers (worst is 9%). I assume I'm doing something pragmatically
> stupid or graph stupid, which is the usual case.
> SDR is HackRF. I wasn't seeing Os with bladeRF.
I can really only tell from the USRP side of life [1], but since we're
talking about hardware:

This could happen because if, after the source block has produced a
number of samples that it took from the hardware, it needs to be called
again to be able to get more samples. If that "calling again" doesn't
happen, at some points, the receive buffers flow over.
The calling again, however, will only happen if GNU Radio sees reason
for it, which would typically mean that something in the output buffer
reader changed.
If, for example, the block that you connect to the source, just sits
there and blocks in its (general_)work(), there's no chance that it
could yet take more input data -- and hence, GNU Radio doesn't ask for
more samples from the source. If that's the case, try to connect a null
sink in parallel to the first block after the source. Does that change
things.
> What does "nproduced -2.0" mean? Is there a paper somewhere?
I'd rather point you to the right source directly [2]. I don't really
know why that appears; it's a "magic value" that your block's
(general_)work can return to tell the scheduler that the return value is
not the number of items that were produced, and that the significant
number is the sum of items that were specified using produce()[3] calls.
>
> While I'm asking stupid questions, :), 
still waiting for your first :)
> it would be handy for this tool
> to spit out something textual so I can post-process, such as graphing a
> parameter. Is that possible? I don't see anything obvious in the
> immediate Python code.
Well, the idea is that controlport allows you to more or less easily
write your own clients that just directly ask. Now, there's two things:
if you need something specific, it might be easier to just write a
client of your own.
If you want to be awesome, and think your visualization or output
facility is helpful for anyone but you, too, you might want to work with
gr-perf-monitorx's source code itself and make upstream pull requests --
it's very seldom that GNU Radio can't use a GUI developer :)
> Perhaps I should also mention two things. First, I've only been working
> with GRC for a few months and I'm not signals literate. 
Well, I think you're becoming more and more literate :)
> Second, I'm processing samples using OpenMP (in some cases nested) plus some 
> data
> structures background maintenance threads, and written in C++11. Seems
> to all work fine. Not sure that matters. 
It's generally cool to see someone do additional acceleration! OpenMP
sounds exiting, as it covers a field that differs from the "raw"
data-parallelism that VOLK[4] tries to achieve using SIMD on different
platforms. What's your application's purpose?

Greetings,
Marcus

[1] Idle, Eric: Why to permanently consider the less strenuous side of
existence, in: Proceedings of the Life of Brian, final notes, 1978.
Editors: Chapman, Cleese, Gilliam, Idle, Jones, Palin.
[2]
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L66
[3]
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#aa5581727d057bdd8113f8b2a3fc5bd66
[4] http://libvolk.org
On 06/17/2015 06:27 AM, Dennis Glatting wrote:
> On Tue, 2015-06-16 at 23:43 -0400, Tom Rondeau wrote:
>> On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting <address@hidden>
>> wrote:
>>         
>>         I have this "nearly" working. MX brings up a window, connects
>>         to GRC,
>>         briefly displays a graph, then blanks out. Displayed in the
>>         command line
>>         window:
>>         
>>         gr-perf-monitorx: radio.getKnobs threw exception (math domain
>>         error).
>>         ...
>>         (repeats)
>>         
>>         I'm not sure what that message is telling me in the
>>         operation/debug
>>         domain. Clue please.
>>         
>>         The paper "Inspecting GNU Radio Applications with ControlPort
>>         and
>>         Performance Counters" shows various blocks in Figures 2 and 5
>>         named
>>         "Ctrlport...". Are those necessary for MX? I haven't found
>>         anything that
>>         indicates yes or no. Clue please.
>>         
>>         Operationally:
>>         
>>         address@hidden:~/thrift# gnuradio-companion  --version
>>         GNU Radio Companion v3.7.7.1-131-g71ab508d
>>         
>>         
>>         address@hidden:~/thrift# lsb_release  -a
>>         No LSB modules are available.
>>         Distributor ID: Ubuntu
>>         Description:    Ubuntu 15.04
>>         Release:        15.04
>>         Codename:       vivid
>>
>>
>>
>>
>> I'm not sure what MX is? Are you using that as shorthand for
>> gr-perf-monitorx?
>>
>>
>> If that's the case, then no, the Ctrlport Probes are there for other
>> purposes and not necessary for Performance Monitor.
>>
>>
>> I'm seen that Math Domain error before, but I've never been able to
>> replicate it reliably. I think it's something related to a divide by
>> zero and I think happens when one block's performance measure of work
>> time comes back with 0 -- which doesn't often happen. Are you using
>> any of your own blocks in the flowgraph? What if you run the
>> Controlport Monitor tool instead of Performance Monitor? That will
>> just show you a list of all available parameters exposed by the
>> application over ControlPort.
>>
> That's an interesting tool. Thanks for pointing it out. 
>
> I'm looking for why I am getting "O"s on the console but I don't see
> full buffers (worst is 9%). I assume I'm doing something pragmatically
> stupid or graph stupid, which is the usual case.
>
> What does "nproduced -2.0" mean? Is there a paper somewhere?
>
> While I'm asking stupid questions, :), it would be handy for this tool
> to spit out something textual so I can post-process, such as graphing a
> parameter. Is that possible? I don't see anything obvious in the
> immediate Python code.
>
> Perhaps I should also mention two things. First, I've only been working
> with GRC for a few months and I'm not signals literate. Second, I'm
> processing samples using OpenMP (in some cases nested) plus some data
> structures background maintenance threads, and written in C++11. Seems
> to all work fine. Not sure that matters. 
>
> SDR is HackRF. I wasn't seeing Os with bladeRF.
>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio