|
| From: | Mostafa Alizadeh |
| Subject: | Re: [Discuss-gnuradio] Latency measurements |
| Date: | Mon, 8 Sep 2014 10:54:00 +0430 |
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" <address@hidden> 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,MostafaOn Sun, Sep 7, 2014 at 8:04 PM, Mostafa Alizadeh <address@hidden> 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,MostafaOn Fri, Sep 5, 2014 at 3:32 PM, Marcus Müller <address@hidden> 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 list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--***********************************************************Department of Electrical EngineeringAboureyhan BuildingMMWCL LABAmirkabir University Of TechnologyTehranIRANTel: +98 (919) 158-7730Homepage: http://ele.aut.ac.ir/~alizadeh/***********************************************************--***********************************************************Department of Electrical EngineeringAboureyhan BuildingMMWCL LABAmirkabir University Of TechnologyTehranIRANTel: +98 (919) 158-7730Homepage: http://ele.aut.ac.ir/~alizadeh/***********************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |