GNU Radio 3.8.2.0, CentOS 7. NDR-358 front end.
I am working on a modification to GNSS-SDR (which is an application built upon gnuradio). It has the option to add a file_sink as a consumer of nearly every block. However, if I enable dumping in one of the upstream blocks, the performance downstream changes, as if data is being dropped so the demodulated signal becomes incoherent.
Conventional wisdom is that file_sink is very slow, so I can imagine that adding it to my flowgraph causes things to back up enough that we can’t keep up with the real-time input. (As an aside, file_sink could probably improve performance by setting an output multiple so it is called less frequently)
In trying to troubleshoot/characterize this situation, I added a monitor thread to periodically dump buffer stats for my signal source (it was originally monitoring a different block, which is why it prints both input and output buffer stats):
void stats_thread(gr::block* item)
{
while (true)
{
std::this_thread::sleep_for(1s);
LOG(INFO) << "source: "
<< "\n input 0 full: " << item->pc_input_buffers_full(0) << "%"
<< "\n input 0 avg: " << item->pc_input_buffers_full_avg(0) << "%"
<< "\n input 0 var: " << item->pc_input_buffers_full_var(0) << "%"
<< "\n output 0 full: " << item->pc_output_buffers_full(0) << "%"
<< "\n output 0 avg: " << item->pc_output_buffers_full_avg(0) << "%"
<< "\n output 0 var: " << item->pc_output_buffers_full_var(0) << "%"
;
}
}
My output always prints 0 for each of these numbers.
Do these methods work? Is there some other direction I should take to identify the problem? I’m willing to write a non-blocking archiving module, but if I can’t prove I’m overflowing the buffer, I need to re-think my strategy.
---
Jim Melton
Principal Software Engineer
Sierra Nevada Corporation
No comments:
Post a Comment