[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Losing samples in the flowgraph

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Losing samples in the flowgraph
Date: Mon, 25 Jul 2011 22:50:56 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11

On 07/25/2011 02:30 PM, Höin Michael (hoim) wrote:

I labeled my block "ofdm_symbol_cutter", but he is not one out of the standard 
OFDM blocks. I wrote this block, because I want to isolate the sample loss problem.
I tested the flow with UHD source and the file source, so it's not only a 
simulation. There was all the times the same flow behaviour. I think there is a 
problem with the multi-threading or I understand something absolutely wrong.
In the example you gave earlier, using a file-source, you run the flow-graph for 13 seconds, then call tb.stop(), then harvest the vector
  sink.  You then make the observation that there are "missing samples".

Are you actually comparing samples, or simply observing that the number of samples harvested from the vector sink is different on a run
  to run basis?

If so, then this is entirely expected behaviour. Linux (and by implication, Gnu Radio on top) is *not*, in any way, shape or form, a "hard real-time" operating system with guaranteed scheduling and latency. The number of computations completed per unit time is not entirely deterministic, and furthermore, when you go to sleep for 13 seconds, you aren't necessarily guaranteed 13 seconds, it could be off by a significant factor (at least, significant at the level of granularity implied by 2Msps). What that means is that the number of samples delivered to you vector sink, when you call tb.stop() after 13 seconds of sleeping, is going to be variable.

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

[Prev in Thread] Current Thread [Next in Thread]