Re: Round trip time calculation - simulation

[Johannes Demel]

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