<div dir="ltr"><div><div>Hello Gedare,<br><br></div>Okay, I see.<br>I will check the convention and follow the aforementioned rules.<br><br></div><div>Best,<br></div><div>Kuan-Hsun<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-04 19:02 GMT+02:00 Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Aug 4, 2016 at 12:41 PM, Kuan Hsun Chen<br>
<<a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><wbr>> wrote:<br>
> Hello all,<br>
><br>
> I just make a pull request including the enhancement and a heuristic<br>
> example.<br>
</span>We don't use pull requests on github. Please submit patches to<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a> for review, or if you think this is a bugfix or major<br>
improvement please open a ticket on our Trac and attach the patch to<br>
the ticket.<br>
<br>
Be sure you have followed the guidelines in<br>
<a href="https://devel.rtems.org/wiki/Developer/Coding/Conventions" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>Developer/Coding/Conventions</a><br>
<span class=""><br>
> I believe this patch is good for further use in more general real-time task<br>
> models.<br>
> To demonstrate the differences, a heuristic example called deadlinemiss is<br>
> prepared in testsuites/samples/ to show the benefit of the enhancement.<br>
> This enhancement only affect those timeout cases without changing any<br>
> behaviour in normal cases.<br>
><br>
</span>New test cases that are for the uniprocessor RTEMS usually go into the<br>
sptests directory. This might qualify as a new sprmsched01 or some<br>
such. Make sure you include the .doc and .scn files to provide<br>
adequate documentation of the example/test.<br>
<span class=""><br>
> However as Joel said, so far there is no standard requirements for how to<br>
> deal with missed periods.<br>
> Maybe RMS manger can have more flexibility to decide the way it reacts.<br>
> I can show some academic papers as the reference if it is necessary.<br>
><br>
</span>References are helpful.<br>
<div class="HOEnZb"><div class="h5"><br>
> Cheers,<br>
> Kuan-Hsun<br>
><br>
><br>
> 2016-08-02 10:45 GMT+02:00 Kuan Hsun Chen <<a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><wbr>>:<br>
>><br>
>> 2016-08-01 19:11 GMT+02:00 Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>>:<br>
>>><br>
>>> On Aug 1, 2016 1:04 PM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>> ><br>
>>> > On Mon, Aug 1, 2016 at 9:49 AM, Kuan Hsun Chen<br>
>>> > <<a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><wbr>> wrote:<br>
>>> > > Hello All,<br>
>>> > ><br>
>>> > > I have used rate_monotonic function series to do some cycle-accuracy<br>
>>> > > emulation quite a long time. I believe that some missing features of<br>
>>> > > scheduling are essentially required. As I'm not aware of any<br>
>>> > > discussion<br>
>>> > > about this before, please correct me if I misunderstand.<br>
>>> > ><br>
>>> > > If I understand correctly, the current implementation of<br>
>>> > > rtems_rate_monotonic_period() is explicitly assumed the implicit<br>
>>> > > deadline or<br>
>>> > > constraint deadline model that the task deadline is always less than<br>
>>> > > or<br>
>>> > > equal to the period deadline. If rtems_rate_monotonic_period() is<br>
>>> > > called, it<br>
>>> > > is the moment that either the task is finished on time or earlier<br>
>>> > > than its<br>
>>> > > period (or inactivate as the first call). If a task misses its<br>
>>> > > period, the<br>
>>> > > watchdog will mark the period as RATE_MONOTONIC_EXPIRED and update<br>
>>> > > the<br>
>>> > > deadline of watchdog.<br>
>>> > ><br>
>>> > Yes I think you understand correctly. Except, I don't think the<br>
>>> > deadline of the watchdog is updated by the watchdog.<br>
>>><br>
>>> +1<br>
>><br>
>> Aha yes, the deadline of watchdog is updated by<br>
>> _Rate_monotonic_Release_job() instead of itself.<br>
>>><br>
>>> > > However, the behavior is not correct currently. From my point of<br>
>>> > > view, the<br>
>>> > > periodic task should always release its workload on time, even it<br>
>>> > > misses its<br>
>>> > > deadline. If there are already two expired periods, the task should<br>
>>> > > have two<br>
>>> > > more remaining instances workload to execute.<br>
>>> > > Especially if the task has arbitrary deadline or even the task is a<br>
>>> > > soft<br>
>>> > > real time task, this feature should behave correctly.<br>
>>> > > (Soft Real Time task: If a task misses its deadline, it is still<br>
>>> > > valuable to<br>
>>> > > gather its result no matter when. If the utilization of uniprocessor<br>
>>> > > is not<br>
>>> > > 100%, the tardiness is proved to be bounded.)<br>
>>> > ><br>
>>> > > Here I aim at a case that the task misses its deadline with the<br>
>>> > > current<br>
>>> > > implementation.<br>
>>> > > If a task period is time out (marked as RATE_MONOTONIC_EXPIRED), by<br>
>>> > > referring to _Rate_monotonic_Block_while_<wbr>expired(), the next call of<br>
>>> > > rtems_rate_monotonic_period() will only release one following<br>
>>> > > instance and<br>
>>> > > manipulate the task period with the calling moment + the next length<br>
>>> > > of<br>
>>> > > period. However, this way of scheduling is in fact changing the<br>
>>> > > behaviour of<br>
>>> > > a periodic task:<br>
>>> > ><br>
>>> > > There may be more than one instances which are postponed due to the<br>
>>> > > preemption of higher priority tasks. Trivially release only one<br>
>>> > > instance is<br>
>>> > > not correct in the sense of scheduling.<br>
>>> ><br>
>>> > I understand that counting the number of missed deadlines could be<br>
>>> > correct for certain applications. The way to handle missed deadlines<br>
>>> > should be a parameter of the RM manager though, since handling missed<br>
>>> > deadlines is application specific property of how "soft" the deadlines<br>
>>> > are.<br>
>>><br>
>>> There are no standard requirements for how to deal with missed periods.<br>
>>> The current implementation does precisely what is required for RMS per the<br>
>>> original paper and nothing more.<br>
>>><br>
>>> We can discuss what to do on missed periods but having academic papers to<br>
>>> back that up would be ideal.<br>
>><br>
>> I can find some collections which are more related to this requirement.<br>
>> (Also my emulation I did for.)<br>
>>><br>
>>> > > The period of expired task is shifted and unpredictable. This should<br>
>>> > > be<br>
>>> > > calculated correctly and rapidly by taking the time point of first<br>
>>> > > period<br>
>>> > > released. The deadline of watchdog in this case should be assigned<br>
>>> > > with an<br>
>>> > > absolute tick.<br>
>>> > ><br>
>>> > Yes. I would deal with this by having the watchdog timeout reprogram<br>
>>> > itself with the next period immediately when it expires in<br>
>>> > _Rate_monotonic_Timeout, along with incrementing the RM_Control<br>
>>> > counter for currently missed deadlines/pending jobs. This way another<br>
>>> > expiration indicates another deadline miss, or so the task finishes<br>
>>> > its current job it can immediately start the next job with the correct<br>
>>> > deadline already programmed in the watchdog.<br>
>><br>
>> This is a great way. I deal with this by RM manager side.<br>
>> I should do this inside the watchdog for more precise control.<br>
>>><br>
>>> ><br>
>>> > > I have enhanced this feature in the system by adding three additional<br>
>>> > > counters in Rate_monotonic_Control structure and one more function to<br>
>>> > > do the<br>
>>> > > correct assignment of deadline and job release. I also prepare a<br>
>>> > > heuristic<br>
>>> > > example to demonstrate the results. I'm going to fix the case for<br>
>>> > > arbitrary<br>
>>> > > deadline later on.<br>
>>> > ><br>
>>> > By arbitrary deadline you mean explicit deadlines? I don't think this<br>
>>> > is a common requirement, but it would be a welcome addition if the<br>
>>> > complexity is not that great and the common case (implicit deadline)<br>
>>> > is negligibly affected.<br>
>><br>
>> The arbitrary deadline model is that the task relative deadline could be<br>
>> larger than its period as shown in [1-2] for example.<br>
>> In this model, a task may have multiple ready jobs. A common assumption is<br>
>> that those jobs are scheduled on a First-Come-First Serve basis.<br>
>> Therefore, the period is no longer "timeout". The deadline can only be<br>
>> expired by the task it belongs to.<br>
>><br>
>> I'm not sure how the others use RTEMS, but I make the application itself<br>
>> detect deadline misses with absolute tick instead of watching the status of<br>
>> period.<br>
>> In some common cases, the task deadline is no more than its period<br>
>> so-called constraint deadline model.<br>
>> Deadline monotonic is optimal in this model, which is similar to RMS.<br>
>><br>
>> I think implicit deadline case can always keep as it is, if we do it<br>
>> carefully.<br>
>> As Gedare said, it might be a good way to prepare a option there in RM<br>
>> manager.<br>
>> I believe having an enhanced scheduler is great to the community of RTEMS<br>
>> anyway.<br>
>> So I will do this right now and evaluate the overhead from my side.<br>
>><br>
>> [1] Andersson etal., Scheduling Arbitrary-Deadline Sporadic Task Systems<br>
>> on Multiprocessors, RTSS'08<br>
>> [2] Huang etal., Response time bounds for sporadic arbitrary-deadline<br>
>> tasks under global fixed-priority scheduling on multiprocessors. RTNS'15<br>
>>><br>
>>> ><br>
>>> > > Please let me know if this feature is sound and essential. I can<br>
>>> > > patch it.<br>
>>> > ><br>
>>> > The feature seems useful for some applications, but may be not all of<br>
>>> > them will want to have this behavior for a missed deadline.<br>
>>> ><br>
>>><br>
>>> > > Best Regards,<br>
>>> > > Kuan-Hsun<br>
>>> > ><br>
>>> > > --<br>
>>> > > M.Sc. Kuan-Hsun Chen<br>
>>> > ><br>
>>> > > TU Dortmund<br>
>>> > > Department of Computer Science 12<br>
>>> > > Design Automation of Embedded Systems<br>
>>> > > Otto-Hahn-Strasse 16, Room 102<br>
>>> > ><br>
>>> > > 44227 Dortmund<br>
>>> > > Germany<br>
>>> > ><br>
>>> > > Phone:  +49 231 755 6124<br>
>>> > > Mail:   <a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><br>
>>> > ><br>
>>> > > ______________________________<wbr>_________________<br>
>>> > > users mailing list<br>
>>> > > <a href="mailto:users@rtems.org">users@rtems.org</a><br>
>>> > > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
>>> > ______________________________<wbr>_________________<br>
>>> > users mailing list<br>
>>> > <a href="mailto:users@rtems.org">users@rtems.org</a><br>
>>> > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> M.Sc. Kuan-Hsun Chen<br>
>><br>
>> TU Dortmund<br>
>> Department of Computer Science 12<br>
>> Design Automation of Embedded Systems<br>
>> Otto-Hahn-Strasse 16, Room 102<br>
>><br>
>> 44227 Dortmund<br>
>> Germany<br>
>><br>
>> Phone:  <a href="tel:%2B49%20231%20755%206124" value="+492317556124">+49 231 755 6124</a><br>
>> Mail:   <a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><br>
><br>
><br>
><br>
><br>
> --<br>
> M.Sc. Kuan-Hsun Chen<br>
><br>
> TU Dortmund<br>
> Department of Computer Science 12<br>
> Design Automation of Embedded Systems<br>
> Otto-Hahn-Strasse 16, Room 102<br>
><br>
> 44227 Dortmund<br>
> Germany<br>
><br>
> Phone:  <a href="tel:%2B49%20231%20755%206124" value="+492317556124">+49 231 755 6124</a><br>
> Mail:   <a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">M.Sc. Kuan-Hsun Chen<br>
<br>
TU Dortmund<br>
Department of Computer Science 12<br>
Design Automation of Embedded Systems<br>
Otto-Hahn-Strasse 16, Room 102<br>
<br>
44227 Dortmund<br>
Germany<br>
<br>
Phone:  <u><span style="color:rgb(0,0,255)">+49 231 755 6124</span></u><br>
Mail:   <a href="mailto:kuan-hsun.chen@tu-dortmund.de" target="_blank">kuan-hsun.chen@tu-dortmund.de</a><a href="mailto:kuan-hsun.chen@tu-dortmund.de" target="_blank"></a></div></div>
</div>