Re: 2 SDRs – Parallel Programming

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.