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

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@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@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >

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@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@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@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >

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@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@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@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@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >

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@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@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@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@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@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

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@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@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@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@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@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@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 > >

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@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@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@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@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@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@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@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 >> >>

- 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).

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@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@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@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@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@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@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@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@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 >>> >>> >> > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >

     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@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@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@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@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@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@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
             
     
     

The error message is: "UHD Warning: get_time: ValueError: get_nmea(): no GPRMC message found" which is originating from here: https://github.com/EttusResearch/uhd/blob/release_003_008_000/host/lib/usrp/gps_ctrl.cpp#L272 But one dropped UDP packet is enough to account for this error, so I'm not worried about it. Time marches on, and I get the next $GPRMC the next second. I only mentioned it as a symptom that may have been related to thread safety. Since it happened so rarely, I thought it may have been indicative of a race. After reading Balint's analysis and looking at what I'm doing, I don't have "thread safety" problems. Regards, Andy On Thu, 2014-12-11 at 19:28 -0500, Andy Walls 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@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@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@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@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@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@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@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 > > >

Thanks for the details. Sounds like everything I’m doing should be ok, although I’m doing it with N2x0s. Are there any significant differences for the N2x0? -Nathan From: Balint Seeber [mailto:balint.seeber@ettus.com] Sent: Thursday, December 11, 2014 7:07 PM To: Andy Walls Cc: Ben Hilburn; Ben Hilburn via USRP-users; Perelman, Nathan Subject: Re: [USRP-users] UHD and Thread Safety 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@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@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@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@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@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@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