[USRP-users] UHD and Thread Safety

Michael West michael.west at ettus.com
Thu Dec 11 19:42:03 EST 2014


Hi Andy,

There are some issues that have come up with NMEA string freshness.  The
attached patch fixed the issue another user was having where occasionally
he would see the time skip a second, but I believe it may resolve your
issue as well.  It basically increases the frequency that the gps_ctrl
polls for updated NMEA strings.  Give it a try and let us know if it
works.  If it does, we will see if we can get it worked into UHD.

Regards,
Michael E. West

On Thu, Dec 11, 2014 at 4:28 PM, Andy Walls via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Hi Balint,
>
> I force a UHD NMEA cache refresh by fetching gps_time 26 msec after the
> PPS. See the code segment here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-August/010469.html
> . I dont think it is a freshness issue.
>
> I'll reproduce the error tomorrow at work to hunt down the message. It
> happens less than once per hour as an estimate. It has no ill effects for
> me, so meh.
>
> -Andy
>
>
> On December 11, 2014 7:06:36 PM EST, Balint Seeber <
> balint.seeber at ettus.com> wrote:
>>
>> Hi all,
>>
>> Apologies - I advised Ben a little too soon before double checking all
>> the code paths.
>>
>> The following applies to third generation radios (B2x0, E310 & X3x0) -
>> these use radio_ctrl_core_3000 so send control/configuration packets to the
>> radios on these devices:
>>
>> Settings bus registers are updated in/results are read back from each
>> radio core in the FPGA by performing a peek or poke. peek32, peek64 and
>> poke32 are provided by radio_ctrl_core_3000, and each of these individual
>> operations are thread safe (there is a mutex in each function). These calls
>> are also blocking, so they will wait for an ACK to come back from the core
>> (this contains the result in the case of a peek). As a side note, if you
>> have a transport failure, then you'll see the standard 'timed out waiting
>> for ACK' exception thrown from radio_ctrl_core_3000.
>>
>> Now to those specific functions:
>>
>>    - get_time_now (from time_core_3000): a single peek64, so it *is*
>>    thread safe (you can call this from any thread, and probably will in
>>    complex applications that might have a main app thread, a thread for RX,
>>    another for TX, and perhaps something to handle TX asynchronous messages
>>    and/or other device status like PLL/ref lock, GPS, etc). Same applies to
>>    'get_time_last_pps'.
>>
>>    set_time_now/set_time_next_pps are implemented as three poke32 calls,
>>    and those calls are *not* in a mutex, so you wouldn't want to call
>>    them from different threads - but then again you probably would never do
>>    this anyway, since it doesn't make sense to do so (you generally would call
>>    one of the two once during device init).
>>
>>    - Anything to do with the GPS is *not* thread safe. You should
>>    synchronise calls to the sensors API only if you're doing this from
>>    different threads. If you know you'll only be doing this from one thread
>>    *only*, then it's *not* necessary to synchronise (i.e. you don't need
>>    to synchronise *all* accesses to *any* function in one multi_usrp
>>    instance).
>>
>> Moreover, since much of multi_user actually sets/gets items on the device
>> instance's property tree, it's worth noting that manipulating the
>> *structure* of the property is thread safe, but actually setting/getting
>> node values (i.e. triggering publishers/subscribers/coercers) is *not*
>> thread safe (i.e. thread safety relies on the underlying implementation(s)
>> that get(s) called).
>>
>> Andy, when you say 'complain' you mean UHD output a log message, but
>> didn't throw an exception? I imagine this had to do with the last received
>> RMC not being considered 'fresh' any more, and perhaps a new one has not
>> arrived yet in the buffer due to delays on the transport. You might want to
>> match the message up with uhd/host/lib/usrp/gps_ctrl.cpp.
>>
>> Hope that helps and doesn't cause any race conditions for you!
>>
>> Kind regards,
>> Balint
>>
>> On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> FWIW, I use a custom GNURadio block for closed loop monitoring of GPSDO
>>> and USRP time between the host and the USRP. Polling every two seconds, 25
>>> msec after the PPS, I occasionally see UHD gripe about the GPRMC message
>>> not being available. I never bothered to track down the cause.
>>>
>>> -Andy
>>>
>>>
>>> On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>>
>>>> Okay, we are debating the safety of polling for sensor data here within
>>>> the R&D team. At this point, we have flip-flopped several times.
>>>>
>>>> Balint will respond shortly with our final guidance =)
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <ben.hilburn at ettus.com>
>>>> wrote:
>>>>
>>>>> Actually, what I just said is wrong, because calling those functions
>>>>> will result in packets being sent from the device.
>>>>>
>>>>> So, no. Nothing is thread safe, and even polling for sensor data could
>>>>> cause issues.
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <ben.hilburn at ettus.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Nathan -
>>>>>>
>>>>>> Generally, any UHD function that doesn't involve streaming is *not *thread-safe.
>>>>>> So if you called "get_time_now" from two separate threads at the same time,
>>>>>> that is *not* a thread-safe operation.
>>>>>>
>>>>>> If all you are doing is polling sensors from a thread that is
>>>>>> different from the thread in which you started streaming, you should be OK.
>>>>>> But, it is not technically thread safe.
>>>>>>
>>>>>> Cheers,
>>>>>> Ben
>>>>>>
>>>>>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>
>>>>>>> I’ve been assuming that calls to UHD functions that don’t change
>>>>>>> settings on the USRP are generally thread safe and can be called from
>>>>>>> another thread even while a capture is ongoing. Is this an accurate
>>>>>>> assumption? The functions I’m calling are get_mboard_sensor() (for GPS
>>>>>>> information and ref_locked) and get_time_now(). Thanks.
>>>>>>>
>>>>>>> -Nathan Perelman
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> USRP-users at lists.ettus.com
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ------------------------------
>>>>
>>>> USRP-users mailing list
>>>> USRP-users at lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141211/bbfdd874/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gps_freshness.patch
Type: text/x-patch
Size: 2410 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141211/bbfdd874/attachment.patch>


More information about the USRP-users mailing list