Hi Jeon, only output buffers are counted -- because they are the input buffers of the next block "downstream" in your flow graph. Also, a single buffer can only have one block writing to it, but multiple blocks reading from it, so it's logical to only count the "outputs"; hence, sinks don't count at all. Would that explain the difference in numbers?
Best regards, Marcus On 06.08.2015 14:14, Jeon 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. > > 2015-08-06 19:31 GMT+09:00 Jeon <sjeon87+gnura...@gmail.com > <mailto:sjeon87+gnura...@gmail.com>>: > > 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. > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
