[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] issues with thread priority
From: |
Marcus Müller |
Subject: |
Re: [Discuss-gnuradio] issues with thread priority |
Date: |
Sun, 21 Feb 2016 12:50:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 |
Hi Simone,
In the scheduler, GR sets the thread priority of a block to the default
if it had been set before[1]:
// Set thread priority if it was set before fg was started
if(block->thread_priority() > 0) {
gr::thread::set_thread_priority(d->thread, block->thread_priority());
}
So, I'd actuall expect that to work if block->thread_priority() returns
the right value.
However, before the flowgraph is started,
> gr::thread::set_thread_priority(gr::thread::get_current_thread_id(),99);
doesn't set the right thread priority, because get_current_thread_id()
doesn't return the right id -- it's still running in the "main" thread
of the scheduler, not in the block thread.
So, what happens if you replace that line with
set_thread_priority(99);
in your block constructor?
Best regards,
Marcus
[1]
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/tpb_thread_body.cc#L87
On 21.02.2016 12:31, Simone Ciccia S210664 wrote:
> Hi Marcus,
> thank you for the support.
>
> Yes, I configured the files as follows:
>
> /etc/security/limits.conf
>
> #<domain> <type> <item> <value>
> #
>
> #* soft core 0
> #root hard core 100000
> #* hard rss 10000
> address@hidden hard nproc 20
> address@hidden soft nproc 20
> address@hidden hard nproc 50
> #ftp hard nproc 0
> #ftp - chroot /ftp
> address@hidden - maxlogins 4
> #di base:
> @usrp - rtprio 99
>
> # End of file
>
> /etc/group
>
> simone:x:1000:
> usrp:x:1001:simone
>
> I discovered that, testing the following code (e.g in codeblocks),
>
> #include <iostream>
> #include <sched.h> //cpu_set_t , CPU_SET
> #include <pthread.h> //pthread_t
> #include <stdio.h>
>
> using namespace std;
>
> int main()
> {
> int policy = SCHED_RR;
> int min_pri = sched_get_priority_min(policy);
> int max_pri = sched_get_priority_max(policy);
>
> sched_param sp;
> sp.sched_priority = int((max_pri - min_pri)) + min_pri;
>
> int ret1 = pthread_setschedparam(pthread_self(), policy, &sp);
> if (ret1 != 0)
> std::cout << "\nError in pthread_setschedparam\n";
> else
> std::cout << "\nPriority success\n";
> }
>
> it succeed to set priority.
> However, within a gnuradio block it fails.
> Any suggestion?
>
>
>
> Il 20.02.2016 15:57 Marcus Müller ha scritto:
>> Hi Simone,
>>
>> is your user allowed to set thread priority? See the Linux notes
>> under [1].
>>
>> Best regards,
>> Marcus
>>
>> [1] http://files.ettus.com/manual/page_general.html#general_threading
>>
>>
>> On 02/19/2016 12:22 PM, Simone Ciccia S210664 wrote:
>>> Hello,
>>>
>>> I'm experiencing some issue trying to set block thread priorities.
>>>
>>> I discovered that my USRP is not able to set thread priorities since
>>> the function pthread_setschedparam(pthread_self(), policy, &sp); fails.
>>>
>>> Therefore, I tryed to test a simple block (whatever), inserting the
>>> core affinity to a processor (e.g. CPU 0) directly in the block GUI,
>>> then, in the block constructor I set the thread priority with
>>>
>>> gr::thread::set_thread_priority(gr::thread::get_current_thread_id(),99);
>>>
>>>
>>> The priority value is retrieved in the work function, and tells that
>>> the thread priority is set to 0 (wrong).
>>>
>>> I suspect that there is a limitation somewhere (probably in the linux
>>> kernel or in some configuration file), I tryed it on another machine
>>> without problems (all works correctly).
>>>
>>> Can you help me?
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>