[USRP-users] Are timed-configuration blocking calls?

Marcus D. Leech patchvonbraun at gmail.com
Wed Mar 13 18:36:50 EDT 2019


On 03/13/2019 05:39 PM, Felipe Augusto Pereira de Figueiredo via 
USRP-users wrote:
> Dear all,
>
> I've got an application that uses timed commands to change Tx
> frequency and gain and sent at to schedule the transmission of my
> data, however, I noticed that the time it takes for my app to generate
> and transfer the data to the USRP increased after the introduction of
> the timed configuration. My app works like this
>
> 1) Generate data at upper layer with timestamp t0+2ms (i.e., send at t0+2ms)
> 2) Execute timed configuration (Tx freq. and/or gain) at t0+2ms-300us
> (i.e., the 300 us before the actual transmission time)
> 3) Encode the data and transfer to USRP.
>
> Before the introduction of timed configuration the step 3) would take
> around 300/400 us but after I started using timed configuration it
> went to more than 1 ms.
>
> Based on what I have explained, my questions are:
>
> 1) Are timed-configuration blocking calls?
> 2) Is there a non-blocking way of doing this?
> 3) Is there a way of scheduling data transmission at t0+2ms and timed
> config at t0+2ms-300us in the same timed configuration?
>
> I'm looking for a way to avoid this blockage. I have tried to create a
> thread that would only apply the timed config and another one that
> would encode data and transmit at the specified time, however, the UHD
> seems not to like being played with in separate threads (I have
> mutexes in my calls, but is doesn't help). My app crashes with a
> message saying UHD was waiting for message 1234 but received
> acknowledgement for message 2000. I use jumbo frames (MTU 9000) with
> 10 Gb ethernet card and probably the crash is related to aggregation
> and or reordering. BTW, I would like to change the MTU size right now.
> I would like to find a better solution to the blocking call, if
> possible.
>
> Many thanks in advance,
>
> Felipe
>
>
I believe that "clear_timed_command" is effectively a blocking call, 
since it waits for that time to happen.

There are plenty of applications out there that do UHD things in at 
least two threads--one for command/control, the other for data.

You can only have a single thread "harvesting" data from the stream, but 
you can then use that thread to populate a ring buffer that could be
   consumed by multiple threads.







More information about the USRP-users mailing list