Re: [Discuss-gnuradio] extremely low buffer usage on perf monitor

[Tom Rondeau]

On Thu, Aug 6, 2015 at 8:14 AM, Jeon <address@hidden> wrote:

I'm sorry for something that I didn't write on the previous post.

Comparing runtime and buffer, runtime and buffer have different number of blocks.

In many cases of mine, buffer shows a fewer blocks than runtime.

My guess is that, it's because buffer of sink blocks don't have to be monitored.

Is what I guess is correct?

If so, this might be a problem when I want to monitor a certain block

which has an optional output signature so that it is recognized as a sink block.

Is there a way to monitor a such block?

Regards,

Jeon.

If it's a sink block, then no, it doesn't have an output buffer and so cannot be monitored this way. If it has an output buffer, it will show up here.

 

2015-08-06 19:31 GMT+09:00 Jeon <address@hidden>:

I am looking into CPU and buffer usage of my OOT module via CtrlPort Performance Monitor.

I have two flow graphs, a transmitter and a receiver.

I can see a quite reasonable performance measures on the receiver side:

However, on the transmitter side, buffer usage shows very weird values:

It says, the transmitter of my OOT module rarely uses buffer. But, i don't think so, and actually it uses buffers! At least, I think encoders on the transmitter should use buffers as much as decoders on the receiver does. (Of course, it's not true that encoder and decoder require same computational cost. But, what I mean is that such tiny value is ridiculous.)

I've executed the transmitter flow graph several times again and again, that number (1.52...e-5) never changes.

My guess is, that number is a floating point representation of 1/(2^16).
And 2^16 is 64k. But I have no idea what it means.

Can anyone give me a tiny hint of it?

Regards

Jeon.

Those are strange numbers. They should represent a percentage, so all of the numbers in these tables should add up to 1. It's possible that one buffer is empty during some calls to get the performance counter and we're not protecting against that, which is causing strange behavior (not exactly a divide-by-zero, but maybe similar?). So no, I don't quite know.

Also, please be careful when sending images in your emails. They make them overly large, and our system might catch and block them instead of letting the pass. Better to either copy the values into a table or post this as a screenshot somewhere and send the link instead.

Tom