[USRP-users] C++ thread Priority.

David Carsenat carsenat at gmail.com
Thu Jul 23 13:13:04 EDT 2020


Many thanks but I am already in O3.

Le jeu. 23 juil. 2020 à 15:46, Luke Whittlesey via USRP-users <
usrp-users at lists.ettus.com> a écrit :

> This is probably not the issue, but sometimes I forget to turn the
> compiler optimizations on and that can give you a little boost
> depending on the code. gcc -O2 ...
>
> On Wed, Jul 22, 2020 at 4:20 PM Marcus D. Leech via USRP-users
> <usrp-users at lists.ettus.com> wrote:
> >
> > On 07/22/2020 03:18 PM, Rob Kossler wrote:
> >
> > If you are using X310 or N310, you might try DPDK. Even though it is a
> pain, it would be a whole lot easier than trying a new OS, I believe.
> Using DPDK enabled my application (which was storing Rx samples to SSD) to
> run a bunch faster than without DPDK.
> >
> > Thanks, Rob.  DPDK does facilitate lower-cost higher data transfer into
> the application.  That may, or may not, be the issue here.
> >
> >
> >
> > On Wed, Jul 22, 2020 at 1:47 PM Marcus D. Leech via USRP-users <
> usrp-users at lists.ettus.com> wrote:
> >>
> >> 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 <patchvonbraun at 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 at 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 at lists.ettus.com
> >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> USRP-users at lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200723/8b376946/attachment.html>


More information about the USRP-users mailing list