Starting to get an idea what is going on with the startup overflows
First, suppose I have a raw UHD application that does the following:
{
instantiate usrp object, set freq, gain, samp_rate
issue stream cmd to start some time in the future (2 sec)
while(1)
{
call _rx_stream->recv()
print the error code
}
}
The output of this will be [ timeout, timeout, ... , none, none, ...] in
that it will timeout until the stream starts, then get valid samples
If I then put a very small delay (0.1 seconds in my case) when there is a
timeout, then I see the exact same behavior as in gr-uhd, which is:
[timeout, ..., overflow, overflow(seq), overflow(seq), none, ...] --> the
"ODD"
This corresponds to the behavior of gr-uhd, where inside work(), when
recv() returns a timeout, work() then returns a 0, and the scheduler calls
work again when it feels like it.
So if I modify the work() function of usrp_source_impl.cc to be:
case ::uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
// its ok to timeout, perhaps the user is doing finite streaming
// return 0;
return work(noutput_items, input_items, output_items);
Then the work() function keeps trying with no delay, and then there are no
overflows. Obviously this is not desirable behavior for the general case,
but this is what "made the problem go away" for me.
Josh
On Thu, Nov 19, 2020 at 7:09 AM Josh <jbm...@gmail.com> wrote:
> Same deal - with "num_recv_frames=128,master_clock_rate=" +
> str(samp_rate*4) I still get "ODD", just about every time.
>
> On Thu, Nov 19, 2020 at 6:52 AM Ron Economos via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> The automatic setting of the master clock seems to be getting in the way
>> after the PPS transition. Try explicitly setting the master clock.
>>
>> "num_recv_frames=128,master_clock_rate=" + str(samp_rate*4)
>>
>> Ron
>> On 11/19/20 03:33, Josh via USRP-users wrote:
>>
>> Marcus,
>>
>> This is naked hardware - B210 usb into a pretty beefy laptop running
>> Ubuntu 20.04, GNU Radio latest master (3.9)
>> Even with num_recv_frames = 128, still getting "ODD" at startup of the
>> flowgraph
>>
>> Any other optimizations I should be tuning? Getting no overruns in the
>> steady state, just at startup.
>>
>> Flowgraph is attached.
>>
>> Josh
>>
>> On Wed, Nov 18, 2020 at 4:46 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 11/18/2020 07:27 AM, Josh via USRP-users wrote:
>>>
>>> I'm seeing a difference in behavior between gr-uhd and plain uhd c++ api:
>>>
>>> Setup:
>>> B210, 2 channels, 5MSPS, master_clock_rate 20MSPS, PPS sync
>>> Receive only flowgraph
>>>
>>> With gr-uhd, there is always a "OOD" when the flowgraph first starts
>>>
>>> But, if I replicate the setup in a simple compiled program using the uhd
>>> API with all the same settings, this never occurs.
>>>
>>> So my question is - is the GR scheduler doing something at the beginning
>>> of the flowgraph that delays the work() calls and causes overflows, and are
>>> there settings I use to mitigate this? My problem is that once these
>>> overflows occur, I can't trust my timing synchronization on the received
>>> samples (or have to do further calculations on the rx_time tags).
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> _______________________________________________
>>>
>>>
>>> Try specifying "num_recv_frames=128" in your device arguments.
>>>
>>> Also, are you running this on naked hardware or through a VM?
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
