Re: Round trip time calculation - simulation
Hi Jiya, some inline comments. On 31.08.23 12:35, Jiya Johnson wrote: Hi Johannes, Thanks in advance for your valuable inputs! I appreciate your help so much. 1.I want to measure the time taken by 1 sample from the random source to the decoder unit-endpoint. My previous comment was targeted at the fact that FEC encoders and decoders work on blocks or frames. The concept of single samples or bits and how long they take to propagate through a flowgraph is probably not a good measure. It would probably make more sense to look at FEC frames and how long they take to propagate through a flowgraph. Depending on the exact position in your flowgraph, an FEC frame might imply that these are the info bits or a codeword. 2.Need more clarifications in throttle usage in terms of latency. The throttle block measures how many samples it passed to the output during a time period and will just stall if more samples could pass through. The GR buffer architecture tries to fill buffers. If you stall in any part of the flowgraph, it might take longer until your blocks where you want to measure latency are called by the scheduler. 3.Time stamp i have used is with two stamping before encoding and after decoding whether it will make sense ,what i understood is time delta if i am using it will be taking only the latest time key added. The "Add System Time" block is intended to be used together with https://github.com/gnuradio/gnuradio/blob/main/gr-pdu/include/gnuradio/pdu/time_delta.h There's a nice explanation in the wiki: https://wiki.gnuradio.org/index.php/Time_Delta 4.How can i use the control performance monitor for this FG. GNU Radio Companion 3.10.7.0 performance monitor is intended for things like load and buffer state. Latency needs extra info (the discussed timestamps). Thus, performance monitor won't report latency. I will upload a PDF of the flowgraph. smime.p7s Description: S/MIME Cryptographic Signature
Round trip time calculation - simulation
Hi Johannes, Thanks in advance for your valuable inputs! I appreciate your help so much. 1.I want to measure the time taken by 1 sample from the random source to the decoder unit-endpoint. 2.Need more clarifications in throttle usage in terms of latency. 3.Time stamp i have used is with two stamping before encoding and after decoding whether it will make sense ,what i understood is time delta if i am using it will be taking only the latest time key added. 4.How can i use the control performance monitor for this FG. GNU Radio Companion 3.10.7.0 I will upload a PDF of the flowgraph. Latency_CCSDS.pdf Description: Adobe PDF document
Re: Round trip time calculation - simulation
Hi Jiya, It seems like you want to measure the DSP latency in a flowgraph without hardware. For better readability, I suggest to use a service that lets you upload screenshots in higher resolution and you just share the link. In said screenshot, I suggest to mark your start end endpoint for your measurement. Thus, we all know exactly what you want to do. The "Throttle" block will have an influence on your measurement even if it is before your measurement starting point because it influences GR scheduler behavior. The timestamp and latency measurement approach seems sensible. I used the same approach for such investigations. How do you want to track the timing for 1 sample? Especially FEC works on blocks. A lot of blocks do. Not just in GR but just in principle. I assume that you want to measure the time it takes for a frame of specific size to be processed. Since I don't know which GR version you use, you might want to double check if all the rate changing blocks place the tags on the correct sample in the output. These are a few thoughts that came to mind when I looked at your flowgraph. Cheers Johannes On 30.08.23 11:40, Jiya Johnson wrote: Hello, community. I have attempted to create a system that uses 1. A random source as input 2. A time stamper.These inputs are provided to the encoder, which performs the modulation and demodulation 3.I want to track back the timing for 1 sample (latency) after using the decoder; can somebody tell me whether my flowgraph is correct? Screenshot from 2023-08-26 11-24-39.png smime.p7s Description: S/MIME Cryptographic Signature
