You might try nice : https://en.wikipedia.org/wiki/Nice_%28Unix%29
On Thu, Jul 23, 2020 at 1:13 PM David Carsenat <carse...@gmail.com> wrote: > > Many thanks but I am already in O3. > > Le jeu. 23 juil. 2020 à 15:46, Luke Whittlesey via USRP-users > <usrp-users@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@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@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 <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> 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 >> >>>> 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 >> > >> > >> > _______________________________________________ >> > USRP-users mailing list >> > 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 _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
