Hi all,
I connected two analog-to-digital converters to a BeagleBoneBlack (with
kernel version 3.14.33-ti-r51.2) and tried to use the deadline scheduler
to get samples at a constant rate. In my C++/Qt application the ADCs are
represented by a class which is derived from QThread. The run() method
is basically:
run()
{
unsigned int flags;
struct sched_attr attr;
attr.sched_policy = SCHED_DEADLINE;
attr.sched_runtime = 600 * 1000;
attr.sched_deadline = 1250 * 1000;
attr.sched_period = 1250 * 1000;
sched_setattr(0, &attr, flags);
while (active) {
/* code that gets a sample from adc, takes around 500 ms */
sched_yield();
}
}
to get samples at a rate of 800 Hz. However, once sched_yield() is
called, the threads do not seem to be scheduled again (no samples are
acquired and when the application shuts down the threads remain as zombies).
As far as I understand, I have to call sched_yield() if the the
execution time of one loop iteration is either not constant or unknown
(both cases being very likely), because if I do not, a new loop
iteration could be started if the time budget is not empty.
Have I missed something? Any ideas or alternative approaches are welcome!
Thanks a lot in advance!
Best regards, Michael
Hi Michael,
On 11/08/15 11:49, Michael Riesch wrote:
> Hi all,
>
> I connected two analog-to-digital converters to a BeagleBoneBlack (with
> kernel version 3.14.33-ti-r51.2) and tried to use the deadline scheduler
> to get samples at a constant rate. In my C++/Qt application the ADCs are
> represented by a class which is derived from QThread. The run() method
> is basically:
>
> run()
> {
> unsigned int flags;
> struct sched_attr attr;
> attr.sched_policy = SCHED_DEADLINE;
> attr.sched_runtime = 600 * 1000;
> attr.sched_deadline = 1250 * 1000;
> attr.sched_period = 1250 * 1000;
> sched_setattr(0, &attr, flags);
>
> while (active) {
> /* code that gets a sample from adc, takes around 500 ms */
>
> sched_yield();
> }
> }
>
> to get samples at a rate of 800 Hz. However, once sched_yield() is
> called, the threads do not seem to be scheduled again (no samples are
> acquired and when the application shuts down the threads remain as zombies).
>
As you are running a 3.14 kernel, you probably missed this fix
5bfd126e80dc "sched/deadline: Fix sched_yield() behavior". Can
you please check?
> As far as I understand, I have to call sched_yield() if the the
> execution time of one loop iteration is either not constant or unknown
> (both cases being very likely), because if I do not, a new loop
> iteration could be started if the time budget is not empty.
>
It depends. The sched_yield() semantic for SCHED_DEADLINE might
be used to implement some sort of reclaiming mechanism (not
there yet) where you inform the scheduler that you are not going
to use the remaining runtime in this period; and the scheduler
could recycle this spare runtime for other tasks that are running
short of it.
However, I'd say that in your case you can also live without it.
SCHED_DEADLINE can handle sporadic tasks, it depends on how you
implement your userspace loop I guess. If you just check the active
flag, and this flag is always set, you are right that you may
end up executing back to back, though; in which case it seems that yield
semantic could do the trick.
Best,
- Juri
Hi Juri,
On 08/11/2015 01:55 PM, Juri Lelli wrote:
> As you are running a 3.14 kernel, you probably missed this fix
> 5bfd126e80dc "sched/deadline: Fix sched_yield() behavior". Can
> you please check?
I stumbled over this commit but somehow managed to ignore it. Anyway, I
upgraded to 4.1, now the application shows the expected behavior.
>> As far as I understand, I have to call sched_yield() if the the
>> execution time of one loop iteration is either not constant or unknown
>> (both cases being very likely), because if I do not, a new loop
>> iteration could be started if the time budget is not empty.
>>
>
> It depends. The sched_yield() semantic for SCHED_DEADLINE might
> be used to implement some sort of reclaiming mechanism (not
> there yet) where you inform the scheduler that you are not going
> to use the remaining runtime in this period; and the scheduler
> could recycle this spare runtime for other tasks that are running
> short of it.
>
> However, I'd say that in your case you can also live without it.
> SCHED_DEADLINE can handle sporadic tasks, it depends on how you
> implement your userspace loop I guess. If you just check the active
> flag, and this flag is always set, you are right that you may
> end up executing back to back, though; in which case it seems that yield
> semantic could do the trick.
Since samples are generated and the resulting curve looks like it was
sampled with a constant frequency, I think that sched_yield() is to be
used in this context. Before I used sched_yield(), I had to use some
sleep statements, which made the sample frequency not deterministic and
filled the CPU up. Now it seems to work pretty well.
Congrats on the deadline scheduler - it is a great way to introduce some
real-time capability - and thank you for your help.
Best regards, Michael
Hi,
On 12/08/15 10:10, Michael Riesch wrote:
> Hi Juri,
>
> On 08/11/2015 01:55 PM, Juri Lelli wrote:
>> As you are running a 3.14 kernel, you probably missed this fix
>> 5bfd126e80dc "sched/deadline: Fix sched_yield() behavior". Can
>> you please check?
>
> I stumbled over this commit but somehow managed to ignore it. Anyway, I
> upgraded to 4.1, now the application shows the expected behavior.
>
>>> As far as I understand, I have to call sched_yield() if the the
>>> execution time of one loop iteration is either not constant or unknown
>>> (both cases being very likely), because if I do not, a new loop
>>> iteration could be started if the time budget is not empty.
>>>
>>
>> It depends. The sched_yield() semantic for SCHED_DEADLINE might
>> be used to implement some sort of reclaiming mechanism (not
>> there yet) where you inform the scheduler that you are not going
>> to use the remaining runtime in this period; and the scheduler
>> could recycle this spare runtime for other tasks that are running
>> short of it.
>>
>> However, I'd say that in your case you can also live without it.
>> SCHED_DEADLINE can handle sporadic tasks, it depends on how you
>> implement your userspace loop I guess. If you just check the active
>> flag, and this flag is always set, you are right that you may
>> end up executing back to back, though; in which case it seems that yield
>> semantic could do the trick.
>
> Since samples are generated and the resulting curve looks like it was
> sampled with a constant frequency, I think that sched_yield() is to be
> used in this context. Before I used sched_yield(), I had to use some
> sleep statements, which made the sample frequency not deterministic and
> filled the CPU up. Now it seems to work pretty well.
>
Great!
Is there any way you can share your application sources? Maybe
it is already on Github or something? I'd be really curious to
have a look at it :).
> Congrats on the deadline scheduler - it is a great way to introduce some
> real-time capability - and thank you for your help.
Sure, no problem. Thanks a lot for asking your question on the
list!
Best,
- Juri