Marcus, That was a great answer. Now I know that this time mismatch is caused by buffer sizes. Thanks for these interesting materials. BR, Marcin
wt., 4 sty 2022 o 14:14 Marcus Müller <muel...@kit.edu> napisał(a): > 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 <mmuel...@gnuradio.org > > <mailto:mmuel...@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 < > mmuel...@gnuradio.org > > <mailto:mmuel...@gnuradio.org> > > >> <mailto:mmuel...@gnuradio.org <mailto:mmuel...@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 > > >> > > >> > > >> > > >
