The second problem I encountered that I forgot to mention is: when I send multiple of packets from a source block to a sink block and I measure the latency for each packet, the latency is increasing constantly as time advances. Why is this happening?
Best, Mostafa On Sun, Sep 7, 2014 at 8:04 PM, Mostafa Alizadeh <m.alizade...@gmail.com> wrote: > 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/ > *********************************************************** > -- *********************************************************** 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
