Just to say how I have solved the problem : - Set the CPU gouvernor to performance with cpufreq-set -g performance - Use a low latency linux kernel, really simply installed following a tuto found on the net for ubuntu. - Add RT priority in the Cpp code (set_thread_priority()) - Reserve a CPU for my application, avoiding Kernet to preempt it
Add in Debian/Ubuntu in the file /etc/default/grub to the option GRUB_CMDLINE_LINUX: GRUB_CMDLINE_LINUX="isolcpus=X" X is the CPU allocated for my UHD application. Launch the application with taskset on the X CPU. Launched since 2 days without unerflow or overflow Hope this will help some peoples David 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
