Hello, There is a mathematical relationship in the latency time? May be there is something related to Ethernet protocol to handle collicollisions. El 07/09/2014 09:39, "Mostafa Alizadeh" <m.alizade...@gmail.com> escribió:
> 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
