Re: 2 SDRs – Parallel Programming

[Marcus D. Leech]

On 05/01/2024 10:33, Jim Melton wrote:

This has less to do with GNU Radio and more to do with real-time programming.

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed.^[5] Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline

 

Things that affect order of execution include:

• The operating system scheduler
  • “Real-time” extensions are present in most Linux distros, but require explicit enabling; more common scheduling strategies include “round robin”; for precise scheduling, you would need a pre-emptive strategy.
  • You may need to pin your process to a particular CPU (core)
  • Note that (depending on your hardware) a “sleep” function, regardless of the requested delay, will not return in less that 50us or so (this one surprised us recently).
• Your hardware
  • in order for things to execute in parallel, there must be parallel execution paths. Most modern CPUs have multiple cores and threads within cores, so unless you are taxing your CPU (possible) there should be compute paths available
  • Control of the radios is via some hardware port. If the two devices use the same hardware (e.g., USB hub), there will be some serialization

 

Simply put, real-time execution constraints are difficult to satisfy, and I would be surprised if a python GNU Radio application could achieve them. Maybe my brain is frozen in the past and it is very doable now, but that hasn’t been my experience.

---

Jim Melton

    It has always come down to what is meant by "real time" and
    "happening at the same time".  It is the case these days that
      an ordinary OS on an ordinary CPU can satisfy what we might have
    called "soft real time" in the past without anything
      special.
    
    In the case at hand, there's ZERO chance that the two threads will
    execute at exactly the same cadence, and that has very
      little to do with Gnu Radio and its implementation and more to do
    with operating system design and computing in
      general.   Throw in the additional complication of the
    connectivity hardware not necessarily being "parallel" -- if
      the two devices go through the same USB controller, the
    transactions will be serialized.
    
    The "right" way to do what is wanted is using timed tuning, where
    you command both devices to tune at the same
      time *AS SEEN BY THE DEVICES*.  See:
    
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
    
    There are two complications here:
    
      (A)  I don't know how well timed commands are really integrated
    into gr-uhd for applications originating in GRC
      (B)  The PLL synthesizers in the B2xx series are not known to be
    super-fast, with tuning latency of 100ms not
             being particularly unusual.  Indeed, PLL synthesizers in
    general aren't always that fast, although the AD936x
             series are among the slowest.