[USRP-users] C++ thread Priority.

David Carsenat carsenat at gmail.com
Wed Jul 22 13:40:52 EDT 2020


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 <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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200722/6534af2d/attachment.html>


More information about the USRP-users mailing list