I set
set_thread_priority(99);
in the block constructor and retrieved it in the work function, it
returns the correct priority.
Therefore, can I neglect the UHD warning and set the priority in this
way?
Il 21.02.2016 12:50 Marcus Müller ha scritto:
> 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
>> #@student hard nproc 20
>> #@faculty soft nproc 20
>> #@faculty hard nproc 50
>> #ftp hard nproc 0
>> #ftp - chroot /ftp
>> #@student - 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
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment