| If you’re using the packaged UHD on your particular distro, you are necessarily at the mercy of whatever decisions the packaging team made with respect to build options.
Sent from my iPhone On Sep 30, 2024, at 12:19 PM, Ron Economos <w...@comcast.net> wrote:
Here's the one NEON file in UHD.
https://github.com/EttusResearch/uhd/blob/master/host/lib/convert/convert_with_neon.cpp
On 32-bit ARM, I used to use this for the CMake invocation for my
Beagleboard X15:
cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard
-mfpu=neon -mtune=cortex-a15 -Wno-psabi"
-DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon
-mtune=cortex-a15 -Wno-psabi"
-DCMAKE_ASM_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard
-mfpu=neon -mtune=cortex-a15 -g" ../
I don't have any 64-bit ARM boards to test with (I'm all in on
RISC-V these days), so I'm not sure what's going on there. It's
possible NEON is enabled by default, but it needs to be checked.
Ron
On 9/30/24 08:56, Anıl Gürses wrote:
Also,
UHD is super tweaked on x86 but has almost nothing for ARM.
I'm not even sure the NEON code is enabled for 64-bit ARM. On
32-bit ARM, you had to compile UHD with specific CFLAGS to
enable NEON.
That's a good point. AFAIK even if you enable NEON
cflag, there are no SIMD instructions for NEON. There is most
likely a delay in data conversion. convert_benchmark.py in
uhd/host/utils can provide more insights about the delay.
Anil
The DVB-T2 transmitter is a continuous stream.
On x86, int8 gives a little help. int12 is worse than
int16.
Also, UHD is super tweaked on x86 but has almost nothing
for ARM. I'm not even sure the NEON code is enabled for
64-bit ARM. On 32-bit ARM, you had to compile UHD with
specific CFLAGS to enable NEON.
Ron
On 9/30/24 08:12, Anıl Gürses wrote:
Hi all,
960M
= 15M samples * 32 bits/sample (lime sdr sink/source
working with 32 bit float) * 2 (because Inphase and
Quadrature assuming you're working with complex
signals).
Sorry,
but UHD is a big CPU hog for transmitting (at least
with the B2X0 series of devices).
That's true but it also depends on how you handle
the transmit process. If you are using timed
commands to transmit the sample (ref. https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD),
it's easier to reach maximum throughput. Otherwise,
you have to wait for the end of the
burst/transmission, which comes with a data transfer
delay (both options have this delay but timed
commands save some time).
I suggest using smaller wire formats such as
complex int12 or int8. This might affect the
performance of your application (due to the
quantization) but it should eventually help you to
reach higher sampling rates.
PS. You are using an SBC to host your
application, which might not have enough computing
power or USB bandwidth as mentioned by others.
Cheers,
Anil
Hi all,
This is my point of view on the
issue:
15M sample rate is equal to 960M
bits/sec data transmission from your USB port to
your SDR device. 960M = 15M samples * 32
bits/sample (lime sdr sink/source working with 32
bit float) * 2 (because Inphase and Quadrature
assuming you're working with complex signals).
If you are using usb 2.0 port, which
has 480 Mbits/sec data rate, you cannot achieve
the desired data rate. Hence the underruns. On the
otherhand, if you're using USB 3.0 port on your
device, it should be *theoretically* able to
achieve that rate as its data transfer speed is
5Gbps. However, mind you that these values are
*the maximum* values that can ever be achieved.
I'm not the expert on USB communication but from
experience never ever was I able to achieve that
theoretical data rate from USB connections. This
is perhaps related to computer architecture and
how the bus is shared. For example your usb mouse
and keyboard *may* be sharing some of the
bandwidth allocated for USB connections in the
computer and hence "stealing" from the theoretical
maximum data transfer rate.
My suggestion is that if you ever
plan to go above 10M samples/sec, use an
ethernet-connected SDR.
Sorry, but UHD is a big CPU hog for
transmitting (at least with the B2X0
series of devices).
Ron
On 9/30/24 07:21, Marcus D. Leech wrote:
> You should investigate the transport
parameters for UHD USB devices here:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb
>
> UHD *IS* a large library, because it
kind of has to be. It supports
> many different hardware devices, going
back to the USRP1
> originally sold in 2004. But having
said that the "sample moving"
> pathways in the code are quite
efficient. One shouldn't
> confuse the size of the library with
the efficiency of the critical
> pathways.
>
>
|
