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.
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
