On 07/22/2020 01:40 PM, David Carsenat wrote:
It just put received samples in a circular buffer and transmit this
buffer. A delay line.
But the SR is 50 Msps... 8 bits.
Do you have ideas about OS ?
Thanks.
There are commercial real-time low-latency OS "out there" that aren't
free, and UHD has not been ported to them as far as I know.
Le mer. 22 juil. 2020 à 19:33, Marcus D. Leech
<patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>> a écrit :
On 07/22/2020 01:22 PM, David Carsenat wrote:
Ok thanks. The code is really simple and i don't think it can be
optimized.
Is there other linux OS i can try ?
Thanks again.
If it's really simple, what is the sample-rate? Is it trying to
write data to the filesystem at high rates? No amount of code
optimization can get
around the fact that the disk subsystem is very slow compared to
other parts of the computer, like memory, CPU, etc.
Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
a écrit :
On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
> Hello, I have made a c++ code which sends samples in the
main function
> and receives samples in a thread launched in this main
function.
> I have read that we can set the real time priority with the
> set_thread_priority function.
> I have tried to call this function (with parameters
(1,true) inside
> the main function but it doesn't seem to change the
priority of the
> executable. When I launch another application, I have lots
of U and O.
>
> Do you have an idea how to achieve what I want ? i.e.
allocate almost
> all computer resources to my uhd program ? What is the best
way ?
> I have already tuned my ubuntu with advice given on Ettus
site.(
> cpu-freq set etc...)
>
> Many thanks
>
> David
>
In general, applications have only very-rough control over
the behavior
of the scheduler. This is true in most general-purpose
operating system
environments, whether it's Windows, Linux, *BSD, MacOS, etc.
If you've played with priorities, and starting up other
programs causes
OU to happen, you should probably consider:
(A) Optimizing your code -- find out where the hot-spots are,
and see if
they can be improved
(B) Choosing a faster CPU
The CPU usage of a DSP flow is roughly proportional to:
inherent-per-sample-complexity X sample-rate
Can you lower the sample rate and still achieve what you need to
achieve? Can you improve the main-path per-sample complexity?
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
