GNSS SDR Flowgraph causes performance issues for real-time operations

[jwmelto]

This issue is for tracking performance issues noted in real-time processing.

I believe that there are design/implementation details in GNSS-SDR that work at odds to the GNU Radio scheduler. The scheduler is responsible for calling the work() (or general_work()) methods of each block. Basically, the scheduler is driven by available space in the output buffer. If there is insufficient space for a block to produce output, it won't be called. This ultimately backs up the flowgraph to the front end. If a real-time source is not called often enough, data will be dropped.

Obviously, logic based on maintaining phase lock and demodulating data from a signal is going to be sensitive to dropped data, because it affects the coherency of the decoded signal.

My initial investigation has shown that the default buffer sizes are too small for a moderate (8msps) throughput signal. Manually increasing the buffer size by calling set_min_output_buffer() has proven effective, until the start of PVT. Then the signal source backs up. I'm still investigating the behavior of downstream blocks.

[jwmelto]

Feel free to discuss this at https://matrix.to/#/#gnss-sdr:gnuradio.org

[jwmelto]

I have determined that the Tracking block (dll_pll_veml_tracking) is exerting pressure upstream. The first line in the ctor is

    // prevent telemetry symbols accumulation in output buffers
    this->set_max_noutput_items(1);

Does anyone have any insight as to what this code is trying to accomplish?

[jwmelto]

I believe I have identified my issue.

The signal source adds tags to the stream carrying VITA-49 metadata (tuned freq, ADC offset, sample rate, time, etc.). However, the Tracking block is more like a sink than a processing block (arguably, the interface should be changed to pass synchros as messages than streaming), so tag propagation is blocked. Eventually, the works get all gummed up and things back up.

I can address this by not propagating tags past my first interface. It does seem to me that there might be a place for explicitly inhibiting tag propagation in the tracking blocks.

This isn't an issue in Acquisition because the Acq block is a sink.

I'm going to leave this open for a bit, while I get some more experience with this fix.

[noelpedro]

Hi @jwmelto Im doing ad9361 signal source and noticing my hardware is overflowing when I reach PVT. I'm able to compute PVT and display it to std. out then shortly after I lose lock and all channels.

[jwmelto]

the ultimate fix is to add set_tag_propagation_policy(TPP_DONT); in the tracking block ctor. I'm working on a refactoring of dll_pll_veml_tracking.cc that may have wider application, but I am not in a position to test all algorithms

[noelpedro]

Didn’t solve the issue for my front end.