Re: QT GUI Time Sink graph refresh rate

[Marcus Müller]

Hi Marcin,

the mechanism is very simple:

> - sampling frequency

That's just variable. It doesn't *mean* something to the GNU Radio scheduling mechanism – 
GNU Radio has no notion of "time". It just tries to process as much samples as quickly as 
possible.

Now, what happens by default is:
You set up your flow graph, and start it. That means GNU Radio goes and allocates buffers 
between these blocks – exactly these memory regions that your (general_)work functions 
write into, and read out of. For technical reasons[1], these buffers need to be multiples 
of 4 kB in size.

After the buffers have been allocated, GNU Radio figures out the sources in the flow graph 
- these are the first blocks that need to do anything, so that any other blocks actually 
have something to do – and calls their (general_)work function, asking them to fill up 
half their output buffer (or as much they can do). Depending on the size of the buffer 
(typical default, I think, currently is 16 kB), and the size of each item (e.g. 8 bytes), 
that can be thousands of samples.

So the source goes and calculates that many samples, puts them in the output buffer, and 
tells GNU Radio how much it has produced. GNU Radio then informs its downstream neighbor 
that there's these many samples in the buffer to be processed, and calls the 
(general_)work function of that block. In your case, that's the Throttle.

Now, the throttle block sees, let's say, 2048 samples, and knows it should be doing a rate 
of 1000 samples a second. It thus calculates that these samples should take 2.048 s, so it 
copies over the samples from its in- to its output, and sleep()s for 2.048 s, then tells 
GNU Radio it produced 2.048 samples. Thus, the next downstream neighbor gets notified that 
there's 2048 items waiting to be processed.

While the Throttle was copying and sleeping, the source has already been asked to produce 
more items (remember, the second half of the buffer is still free), so it's realistic it 
produced another 2048 items in the time. So, Throttle is immediately after being done with 
its work() being called again – since there's already new input waiting, it copies, sleeps 
for 2.048 s, and so on.

In effect, that means that the Sink gets data once every 2.048 s, and in chunks of 2048 
items, not in nice small packages. *In average*, the rate is 1 kS/s, but that just means 
it's "no data to be processed for what seems to be eternity" followed by "a large amount 
of samples".

I've done a talk trying to illustrate this a bit back on the European GNU Radio days in 
Besançon¹, I hope it's not to confused and too confusing, but maybe it's of interest to 
you[2].

Best regards,
Marcus

[1] https://www.gnuradio.org/blog/2017-01-05-buffers/
[2] https://www.youtube.com/watch?v=cTGxhsSvZ9c
¹ it was niiiice there!

On 04.01.22 13:23, Marcin Puchlik via GNU Radio, the Free & Open-Source Toolkit for 
Software Radio wrote:
> Dear Cyrille and Marcus
> Thanks for your answers.
> Cyrille: I get that there is no exact timing and the refresh rate on the Time Sink block 
> can deviate from one second (in this particular example) but what is the margin? Now, in 
> this configuration it takes apx 10 seconds to refresh the graph on the Time Sink, is this 
> correct observation? How exactly does the Throttle block behave then (assuming no timing)?
>
> Marcus: YES! Great! Now, the Time Sink behaves as expected! But let me understand what 
> happened:
> - sampling frequency: 1000
> - maximum number of output items for the Throttle block (during a call to 
> work): 1000/100 = 10
> - update period for the Time Sink: 1
> - number of points for the Time Sink: 100
>
> In this configuration now, the Time Sink receives the data at a proper speed and is able 
> to refresh the graph at a rate 1 (one time per second). Can you tell me the rationale for 
> this? Can we say how often the work function is called when there is the Throttle in the 
> flowgraph? Simple calculations would help.
>
> BR,
> Marcin
>
>
>
> czw., 30 gru 2021 o 15:28 Marcus Müller <mmueller@gnuradio.org 
> <mailto:mmueller@gnuradio.org>> napisał(a):
>
>     Ah, by the way, could you try the following dirty hack:
>
>     1. Copy the generated update_period.py file.
>     2. Find the place where self.blocks_throttle_0 = ... is done
>     3. after that, insert
>     self.blocks_throttle_0.set_max_noutput_items(int(samp_rate/100))
>
>     and report whether that works?
>
>     Best regards,
>     Marcus
>
>     On 30.12.21 13:54, Marcus Müller wrote:
>      > Exactly! Chances are even that the Throttle regularly sees very large 
> input blocks,
>     e.g.
>      > 8192 items at once, and then decides to sleep for loooooong before 
> telling GNU
>     Radio it's
>      > done copying the input to the output.
>      >
>      > Best regards,
>      > Marcus
>      >
>      > On 30.12.21 12:32, Cyrille Morin wrote:
>      >> Hi Marcin,
>      >> In this graph, the Time sink waits for chunks of 100 samples to display 
> at a time.
>      >> Since the Throttle is set to forward 1000 samples per second, it should 
> be able to
>      >> update up to 10 times per second.
>      >>
>      >> Keep in mind that this is an estimate since the Throttle block does not 
> enforce its
>      >> timing exactly. It depends on the size of sample blocks it operates on.
>      >> So it could be possible that the scheduler gives it a chunk of 1000 
> samples at a
>     time.
>      >> In this case, it would forward it whole, and the Time sink would only 
> display the 100
>      >> samples out of these 1000.
>      >> If that repeats, you would only get 1 update per second.
>      >>
>      >> Hope this makes sense,
>      >> Cyrille
>      >>
>      >>
>      >> Le 30 décembre 2021 10:38:06 GMT+01:00, "Marcin Puchlik via GNU Radio, the 
> Free &
>      >> Open-Source Toolkit for Software Radio" <discuss-gnuradio@gnu.org
>     <mailto:discuss-gnuradio@gnu.org>> a écrit :
>      >>
>      >>     Hi Marcus,
>      >>     Thanks for your answer. Please, check out this flowgraph.
>      >>     Shouldn't the Time Sink update its graph content every second in 
> this
>     configuration?
>      >>
>      >>     image.png
>      >> https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426
>     <https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426>
>      >>     
> <https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426
>     <https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426>>
>      >>     BR,
>      >>     Marcin
>      >>
>      >>
>      >>     śr., 29 gru 2021 o 19:27 Marcus Müller <mmueller@gnuradio.org
>     <mailto:mmueller@gnuradio.org>
>      >>     <mailto:mmueller@gnuradio.org <mailto:mmueller@gnuradio.org>>> 
> napisał(a):
>      >>
>      >>         Hi Marcin,
>      >>
>      >>         only if there's no other component that limits the speed of 
> processing. For
>      >>         example, if
>      >>         the samples come from an SDR, than that has a sampling rate, so 
> there's
>     only so
>      >> many
>      >>         samples per second that can reach your sink.
>      >>
>      >>           > I noticed that when I am using
>      >>           > throttle block along with QT GUI Time Sink the update 
> period is not
>     working
>      >>         properly (I
>      >>           > have to wait much longer to see the updated graph).
>      >>
>      >>         That only happens when the number of samples reaching the sink 
> isn't
>     sufficient to
>      >>         get one
>      >>         full vector of samples per update period.
>      >>
>      >>         Best regards,
>      >>         Marcus
>      >>
>      >>
>      >>

smime.p7s
Description: S/MIME Cryptographic Signature