Hi Marcus, I did what you recommended for measuring latency which is defined as followed:
"the traveling duration of a packet through blocks until some specified processing in one block is done". However, there are obstacles again. Firstly, how can optimize I/O buffers of my blocks to obtain a minimum latency. I tried to use "set_alignment" for output buffers. When I change them a little, the latency will change within a hundred of milliseconds. Although, the input buffers must be determined in an efficient manner but how to do so? This is important to mention that the latency here is just accounted for GNURadio latency which is not included other delays such as hardware and UHD delays. Thanks in advance, Mostafa On Fri, Sep 5, 2014 at 3:32 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > 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 > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- *********************************************************** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ ***********************************************************
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
