Hi Mostafa, I never tire to say that such measurements are often meaningless, as a) on general purpose processors and operating systems *anything* can happen, stalling your flow graph, and b) as GNU Radio scales well on multiprocessor platforms and algorithms are steadily optimized, you can expect no two installations to exhibit the same latency. That being said, it's still a helpful measurement when actually implementing something for a given system configuration, so here's my advice:
Just compare the nitems_written() of an upstream block with the nitems_read() of a downstream block at singulare times, which will give you the numbers of items "in the flow" between these two. Also, take the nitems_read() of an upstream block, and measure the host time passing until nitems_read() of a downstream block is greater or equal that number. Apply statistics. The easiest way to find out how long an item has been "in the flight" would be adding a stream tag containing the current host time at an upstream block, and reading that tag somewhere downstream, comparing the contained timestamp with the now current system time. Also, since I bet this ends up on the Google search results for "GNU Radio latency" sooner or later, a word to the uninitiated reader: Usually, real time doesn't matter in DSP systems such as GNU Radio. Samples are not processed at their "signal theoretical" speed, but at the rate that they become available, limited by the speed at which the processor can process them. In the GNU Radio case, this is even more evident because normally, GNU Radio lets blocks process samples en bloc, meaning that you usually see something like 4096 samples going into a block, which then processes them, and outputs another chunk of samples (often of the same length), and then goes to sleep, until its woken up to process another chunk of samples at its input. Latency is thus strongly dependent on how big GNU Radio makes these chunks, which is a thing that as developer/user you can configure, but lowering buffer sizes usually decreases efficiency, and thus doesn't necessarily reduce latency. Generally, if you try to optimize something for throughput, just write your blocks as efficiently as possible and use GNU Radio/volk optimized things as often as sensible; if you try to optimize for latency, you need to put in more thought, optimize individual buffer sizes, consider what optimal work chunk sizes are and if you want to go as far as breaking up GNU Radios highly modular approach. Greetings, Marcus On 05.09.2014 12:14, Mostafa Alizadeh wrote: > Hi guys, > > In simulation, sometime we need to measure the latency of a packet in terms > of the duration is needed to perform some certain signal processing on the > packet. Assume that we have a source which generates packets with specific > lengths. I want to know how long does it take for the packet to go through > blocks and receive to a particular block? > > Is there any solution in GNURadio? I think it's possible with *performance > counters* but I don't know how? > > Best, > Mostafa > > > > _______________________________________________ > 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
