Re: System Requirements for High Bandwidth SDRs Based on Your Experience

[Marcus Müller]

Hi Mutlu,

1600 MHz instantaneous bandwidth: You will be very hardly pressed building a PC-style 
system that even has the necessary external bandwidth to get that in. So, you're probably 
looking at hefty server systems, and more likely even, need to re-architect your system 
approach to allow for distributed computing on multiple computers.


For the lower bandwidths: Whether, and on what hardware, these are feasible 100% depends 
on what you're planning to do with these signals, what your reliability, latency and 
flexibility requirements are, and how you get data in and out of your system. For example, 
if you need to record 400 MHz of instantaneous bandwidth, you will need a rather hefty 
storage array. If you don't need to record, then not. Applying a 11-tap halfband filter is 
a lot easier than applying a 10003-tap channelizer.  No general statement can be given, 
not even on orders of magnitude, until you sat down and specified what you need in more 
detail. As a general rule of thumb: 1600 MHz of instantaneous bandwidth cost *a lot* in 
SDR hardware. Why would you even start to save money on a PC there? Buy the thing with the 
highest clock rate, highest memory bandwidth and most CPU cores that you can get on the 
market.


Best regards,
Marcus

On 19.10.22 07:54, Mutlu Aydın wrote:

Hello,

I am searching for a computer/workstation that will work with high bandwidth SDRs. Do you 
recommend computer/workstation systems for working with SDRs that are capable of 200MHz, 
400 Mhz, 800 MHz  and 1600 Mhz etc instantaneous bandwidth based on your experience? What 
are important specs (RAM CPU etc)  for receiving without dropping samples?


Thank you.

Mutlu AYDIN

GnuRadio within docker container access to ettus/n310 requires host mode network

[M Esc]

(similar cross post issued to uhd/usrp stack exchange)
I have a GNURadio/GNURadio Companion 3.10 on an Ubuntu 20.0.4 docker image, 
where the image is also loaded up  with the 4.10 UHD N310 libraries and osmocom 
libraries (and some Xterm stuff).  I'm running the container of the image on an 
Ubuntu 20.0.4 host.
I can connect my N310 (also running 4.10 UHD libs) to the host and ping the 
N310.I can fire up the docker image as a container and ping the N310 from 
within the container.When I run "uhd_find_devices" within the container, the 
command reports No UHD Devices found.When I run GNR companion within the 
container and set up a USRP/UHD as a sink with a simple sine wave source, and 
try to run the blocks, it will fail.
However, if I run the container in the docker network=host mode, I can 
successfully run uhd_find_devices and see the N310's info and can successfully 
run the GNR companion with a simple USRP/UHD sink.
I had a similar experience running a nooelec USB SDR and a pluto USB SDR  on 
the same host, i.e. when attaching the USB radios and then running the 
container in network=host mode, I could run my GNR Companion blocks 
successfully, but only when in network=host mode.

So it would *appear* that the network=host mode is required to successfully run 
GNR (either headless or with GNR companion) is required.
I also set up and ran the sample non-GNR/headless container created by: 
https://hub.docker.com/r/openverso/ettus-uhd and found that I also had to add a 
network=host parameter to the commands listed on that page before I could 
successfully run a uhd_find_devices against my N310.
I'd prefer not to use host network mode for a number of reasons, so wondered if 
anyone else has experienced this apparent limitation and/or how they solved it.
By the way, our group considered trying to use a macvlan network rather than 
the host network mode, and that might help the N310 access problem, but we 
don't think that it will solve the same problem that we saw with the USB 
devices (nooelec/pluto).
Bottom line question: has anyone else run into the limitation of running 
gnuradio source/sink to an external SDR from within a docker container and 
being forced to use network=host mode?
ThanksMR

Re: GnuRadio within docker container access to ettus/n310 requires host mode network

[Jeff Long]

For UHD network-connected devices, it is possible the host mode is
required, not sure if there is another solution. USB connected device do
not require host mode, but do require the usb devices to be passed through
(e.g., --device or -v)..

On Wed, Oct 19, 2022 at 6:09 AM M Esc  wrote:

> (similar cross post issued to uhd/usrp stack exchange)
>
> I have a GNURadio/GNURadio Companion 3.10 on an Ubuntu 20.0.4 docker
> image, where the image is also loaded up  with the 4.10 UHD N310 libraries
> and osmocom libraries (and some Xterm stuff).  I'm running the container of
> the image on an Ubuntu 20.0.4 host.
>
> I can connect my N310 (also running 4.10 UHD libs) to the host and ping
> the N310.
> I can fire up the docker image as a container and ping the N310 from
> within the container.
> When I run "uhd_find_devices" within the container, the command reports No
> UHD Devices found.
> When I run GNR companion within the container and set up a USRP/UHD as a
> sink with a simple sine wave source, and try to run the blocks, it will
> fail.
>
> However, if I run the container in the docker network=host mode, I can
> successfully run uhd_find_devices and see the N310's info and can
> successfully run the GNR companion with a simple USRP/UHD sink.
>
> I had a similar experience running a nooelec USB SDR and a pluto USB SDR
> on the same host, i.e. when attaching the USB radios and then running the
> container in network=host mode, I could run my GNR Companion blocks
> successfully, but only when in network=host mode.
>
> So it would *appear* that the network=host mode is required to
> successfully run GNR (either headless or with GNR companion) is required.
>
> I also set up and ran the sample non-GNR/headless container created by:
> https://hub.docker.com/r/openverso/ettus-uhd and found that I also had to
> add a network=host parameter to the commands listed on that page before I
> could successfully run a uhd_find_devices against my N310.
>
> I'd prefer not to use host network mode for a number of reasons, so
> wondered if anyone else has experienced this apparent limitation and/or how
> they solved it.
>
> By the way, our group considered trying to use a macvlan network rather
> than the host network mode, and that might help the N310 access problem,
> but we don't think that it will solve the same problem that we saw with the
> USB devices (nooelec/pluto).
>
> Bottom line question: has anyone else run into the limitation of running
> gnuradio source/sink to an external SDR from within a docker container and
> being forced to use network=host mode?
>
> Thanks
> MR
>

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Ryan Volz]

Hi Michael,

On 10/18/22 5:47 PM, Michael Matthews wrote:

Hey Ryan,

I went ahead and ran that cmake trace and it did produce something 
interesting.  I seems that two cmake policies are not set and both have 
the behavior to not throw warnings by default. The offending policies are:


- CMP0060

- CMP0082


Those are nothing to be concerned about.


...
PS.

The trace output I received is below:

...
I don't actually see anything new in the trace, so I suspect it didn't 
work. Probably it's not loading that file from that exact path (maybe 
/usr/lib -> /lib would work?). Here's the option that should definitely 
work, although it will also produce much more than we need:


cmake .. --trace-expand


Cheers,
Ryan

RE: GnuRadio within docker container access to ettus/n310 requires host mode network

[Jim Melton]

MR,

Docker creates an abstraction over the physical machine, isolating the software 
inside from the rest of the machine.

What you are describing is the expected behavior of the default Docker network 
interface. When you run in --network=host mode, you are telling Docker to 
by-pass it’s networking layer and to share the host network as if you were a 
native application. This is the easiest way to get network applications working 
in Docker, but as you note, there are security issues.

Further complicating things, if you are running on Windows or Mac, is that your 
Docker image actually runs in a lightweight Linux VM running on your computer, 
because of host operating system limitations. I have no experience with 
non-native (Linux) Docker, so just know that dealing with physical devices is a 
non-trivial configuration.

Some things (like multicast) are darn near impossible using the Docker network. 
I don’t know how the UHD discovers the SDR. If you don’t run --network=host, 
you will to explicitly forward the port(s)/protocol(s) used by your radio to 
your Docker container. Note that TCP and UDP require separate forwarding rules 
as needed.

Similarly, access to USB devices requires some careful configuration. Again, 
the host device must be exposed (typically through a volume mount) into the 
container for the container to see it. The link you shared shows how the USB 
device is exposed. Note also that the container requires escalated privilege 
(--privileged) for this to work.

What you are observing is less a limitation of GRC and more the normal behavior 
of Docker.

---
Jim Melton



From: Discuss-gnuradio  On Behalf Of M Esc
Sent: Wednesday, October 19, 2022 06:51
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] GnuRadio within docker container access to ettus/n310 
requires host mode network

(similar cross post issued to uhd/usrp stack exchange)

I have a GNURadio/GNURadio Companion 3.10 on an Ubuntu 20.0.4 docker image, 
where the image is also loaded up  with the 4.10 UHD N310 libraries and osmocom 
libraries (and some Xterm stuff).  I'm running the container of the image on an 
Ubuntu 20.0.4 host.

I can connect my N310 (also running 4.10 UHD libs) to the host and ping the 
N310.
I can fire up the docker image as a container and ping the N310 from within the 
container.
When I run "uhd_find_devices" within the container, the command reports No UHD 
Devices found.
When I run GNR companion within the container and set up a USRP/UHD as a sink 
with a simple sine wave source, and try to run the blocks, it will fail.

However, if I run the container in the docker network=host mode, I can 
successfully run uhd_find_devices and see the N310's info and can successfully 
run the GNR companion with a simple USRP/UHD sink.

I had a similar experience running a nooelec USB SDR and a pluto USB SDR  on 
the same host, i.e. when attaching the USB radios and then running the 
container in network=host mode, I could run my GNR Companion blocks 
successfully, but only when in network=host mode.

So it would *appear* that the network=host mode is required to successfully run 
GNR (either headless or with GNR companion) is required.

I also set up and ran the sample non-GNR/headless container created by: 
https://hub.docker.com/r/openverso/ettus-uhd and found that I also had to add a 
network=host parameter to the commands listed on that page before I could 
successfully run a uhd_find_devices against my N310.

I'd prefer not to use host network mode for a number of reasons, so wondered if 
anyone else has experienced this apparent limitation and/or how they solved it.

By the way, our group considered trying to use a macvlan network rather than 
the host network mode, and that might help the N310 access problem, but we 
don't think that it will solve the same problem that we saw with the USB 
devices (nooelec/pluto).

Bottom line question: has anyone else run into the limitation of running 
gnuradio source/sink to an external SDR from within a docker container and 
being forced to use network=host mode?

Thanks
MR

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are 
confidential, may contain proprietary, protected, or export controlled 
information, and are intended for the use of the intended recipients only. Any 
review, reliance, distribution, disclosure, or forwarding of this email and/or 
attachments outside of Sierra Nevada Corporation (SNC) without express written 
approval of the sender, except to the extent required to further properly 
approved SNC business purposes, is strictly prohibited. If you are not the 
intended recipient of this email, please notify the sender immediately, and 
delete all copies without reading, printing, or saving in any manner. --- Thank 
You.

Re: GnuRadio within docker container access to ettus/n310 requires host mode network

[Marcus D. Leech]

On 2022-10-19 11:52, Jim Melton wrote:


MR,

Docker creates an abstraction over the physical machine, isolating the 
software inside from the rest of the machine.


What you are describing is the expected behavior of the default Docker 
network interface. When you run in *--network=host* mode, you are 
telling Docker to by-pass it’s networking layer and to share the host 
network as if you were a native application. This is the easiest way 
to get network applications working in Docker, but as you note, there 
are security issues.


Further complicating things, if you are running on Windows or Mac, is 
that your Docker image actually runs in a lightweight Linux VM running 
on your computer, because of host operating system limitations. I have 
no experience with non-native (Linux) Docker, so just know that 
dealing with physical devices is a non-trivial configuration.


Some things (like multicast) are darn near impossible using the Docker 
network. I don’t know how the UHD discovers the SDR. If you don’t run 
*--network=host*, you will to explicitly forward the 
port(s)/protocol(s) used by your radio to your Docker container. Note 
that TCP and UDP require separate forwarding rules as needed.


UHD uses a *broadcast* packet to do discovery, and even in a 
non-VM/docker environment, system security settings

  can prevent the non-privileged user from doing broadcast.


Similarly, access to USB devices requires some careful configuration. 
Again, the host device must be exposed (typically through a volume 
mount) into the container for the container to see it. The link you 
shared shows how the USB device is exposed. Note also that the 
container requires escalated privilege (*--privileged*) for this to work.


What you are observing is less a limitation of GRC and more the normal 
behavior of Docker.


---

*Jim Melton*



*From:*Discuss-gnuradio *On Behalf Of *M Esc
*Sent:* Wednesday, October 19, 2022 06:51
*To:* discuss-gnuradio@gnu.org
*Subject:* [EXTERNAL] GnuRadio within docker container access to 
ettus/n310 requires host mode network


(similar cross post issued to uhd/usrp stack exchange)

I have a GNURadio/GNURadio Companion 3.10 on an Ubuntu 20.0.4 docker 
image, where the image is also loaded up with the 4.10 UHD N310 
libraries and osmocom libraries (and some Xterm stuff).  I'm running 
the container of the image on an Ubuntu 20.0.4 host.


I can connect my N310 (also running 4.10 UHD libs) to the host and 
ping the N310.


I can fire up the docker image as a container and ping the N310 from 
within the container.


When I run "uhd_find_devices" within the container, the command 
reports No UHD Devices found.


When I run GNR companion within the container and set up a USRP/UHD as 
a sink with a simple sine wave source, and try to run the blocks, it 
will fail.


However, if I run the container in the docker network=host mode, I can 
successfully run uhd_find_devices and see the N310's info and can 
successfully run the GNR companion with a simple USRP/UHD sink.


I had a similar experience running a nooelec USB SDR and a pluto USB 
SDR  on the same host, i.e. when attaching the USB radios and then 
running the container in network=host mode, I could run my GNR 
Companion blocks successfully, but only when in network=host mode.


So it would *appear* that the network=host mode is required to 
successfully run GNR (either headless or with GNR companion) is required.


I also set up and ran the sample non-GNR/headless container created 
by: https://hub.docker.com/r/openverso/ettus-uhd 
 and found that I also 
had to add a network=host parameter to the commands listed on that 
page before I could successfully run a uhd_find_devices against my N310.


I'd prefer not to use host network mode for a number of reasons, so 
wondered if anyone else has experienced this apparent limitation 
and/or how they solved it.


By the way, our group considered trying to use a macvlan network 
rather than the host network mode, and that might help the N310 access 
problem, but we don't think that it will solve the same problem that 
we saw with the USB devices (nooelec/pluto).


Bottom line question: has anyone else run into the limitation of 
running gnuradio source/sink to an external SDR from within a docker 
container and being forced to use network=host mode?


Thanks

MR

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are 
confidential, may contain proprietary, protected, or export controlled 
information, and are intended for the use of the intended recipients 
only. Any review, reliance, distribution, disclosure, or forwarding of 
this email and/or attachments outside of Sierra Nevada Corporation 
(SNC) without express written approval of the sender, except to the 
extent required to further properly approved SNC business purposes, is 
strictly prohibited. If you are not the intended recipient of this 
email, please notify the sender immedi

RE: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Michael Matthews]

Hi Ryan,



It seems that changing the trace source path to start with /lib did produce a 
more meaningful output. When the target properties are set for 
gnuradio::gnuradio-runtime, the INTERFACE_INCLUDE_DIRECTORIES is correctly 
declared as /usr/include (gnuradio-runtimeTargets.cmake, line 66). I was unsure 
where or how that would change to /include and throw the error, so I decided to 
do the more expansive trace log to see if the libraries it was linked with 
could have any issues.



If I am reading the output correctly, it seems that Boost and pybind11 are two 
things having the path /include being added to their targets. So, I am still 
unsure why gnuradio-runtime is being affected. My next guess to try to resolve 
this is to update the versions for Boost and pybind11 on my machine. The GNU 
Radio Manual and API Reference only mentions needing boost >= 1.65 (mine is 
1.71.0.0ubuntu2) and does not mention pybind11 (my version is 2.4.3-2build2, 
which seems to be the latest available through apt on Ubuntu 20.04).



Thank you for bearing with me. As I said last time, I am more familiar with 
other build systems, not so much with cmake and I am completely new to gnuradio.



Cheers,

Michael



PS. These are the outputs I got, in case they are helpful



The trace output I received was:

~/gr-customModule/build$ cmake .. 
--trace-source=/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake
 --trace-expand

Running with expanded trace output on.

-- The CXX compiler identification is GNU 9.4.0

-- The C compiler identification is GNU 9.4.0

-- Check for working CXX compiler: /usr/bin/c++

-- Check for working CXX compiler: /usr/bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed

-- Looking for pthread_create in pthreads

-- Looking for pthread_create in pthreads - not found

-- Looking for pthread_create in pthread

-- Looking for pthread_create in pthread - found

-- Found Threads: TRUE

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")

-- Checking for module 'gmp'

--   Found gmp, version 6.2.0

-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Using GMP.

-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Found Boost: /lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake 
(found suitable version "1.71.0", minimum required is "1.71.0") found 
components: date_time program_options system regex thread unit_test_framework

-- Found Volk: Volk::volk

-- User set python executable /usr/bin/python3

-- Found PythonInterp: /usr/bin/python3 (found version "3.8.10")

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found suitable 
exact version "3.8.10")

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(3):  if(3.16 
LESS 2.5 )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(6):  
cmake_policy(PUSH )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(7):  
cmake_policy(VERSION 2.6 )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(13):  
set(CMAKE_IMPORT_FILE_VERSION 1 )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(16):  
set(_targetsDefined )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(17):  
set(_targetsNotDefined )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(18):  
set(_expectedTargets )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(19):  
foreach(_expectedTarget gnuradio::gnuradio-runtime )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(20):  
list(APPEND _expectedTargets gnuradio::gnuradio-runtime )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(21):  if(NOT 
TARGET gnuradio::gnuradio-runtime )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(22):  
list(APPEND _targetsNotDefined gnuradio::gnuradio-runtime )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(24):  
if(TARGET gnuradio::gnuradio-runtime )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(28):  if( 
STREQUAL gnuradio::gnuradio-runtime )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(36):  if(NOT 
 STREQUAL  )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(39):  
unset(_targetsDefined )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(40):  
unset(_targetsNotDefined )

/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake(41):  
uns