Re: [USRP-users] Overflows at flowgraph start using gr-uhd

2020-11-19 Thread Josh via USRP-users 
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  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

Re: [USRP-users] Overflows at flowgraph start using gr-uhd

2020-11-19 Thread Josh via USRP-users 
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

Re: [USRP-users] Overflows at flowgraph start using gr-uhd

2020-11-19 Thread Ron Economos via USRP-users 
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 
mailto: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 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

Re: [USRP-users] Overflows at flowgraph start using gr-uhd

2020-11-19 Thread Josh via USRP-users 
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
>


test_usrp_rx.grc
Description: application/gnuradio-grc
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Overflows at flowgraph start using gr-uhd

2020-11-18 Thread Marcus D. Leech via USRP-users 

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] Overflows at flowgraph start using gr-uhd

2020-11-18 Thread Josh via USRP-users 
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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com