<p dir="ltr"></p>
<p dir="ltr">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>> 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 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 deadline or<br>
> > constraint deadline model that the task deadline is always less than or<br>
> > equal to the period deadline. If rtems_rate_monotonic_period() is called, it<br>
> > is the moment that either the task is finished on time or earlier than its<br>
> > period (or inactivate as the first call). If a task misses its period, the<br>
> > watchdog will mark the period as RATE_MONOTONIC_EXPIRED and update 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.</p>
<p dir="ltr">+1</p>
<p dir="ltr">> > However, the behavior is not correct currently. From my point of view, the<br>
> > periodic task should always release its workload on time, even it misses its<br>
> > deadline. If there are already two expired periods, the task should have two<br>
> > more remaining instances workload to execute.<br>
> > Especially if the task has arbitrary deadline or even the task is a soft<br>
> > real time task, this feature should behave correctly.<br>
> > (Soft Real Time task: If a task misses its deadline, it is still valuable to<br>
> > gather its result no matter when. If the utilization of uniprocessor 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 current<br>
> > implementation.<br>
> > If a task period is time out (marked as RATE_MONOTONIC_EXPIRED), by<br>
> > referring to _Rate_monotonic_Block_while_expired(), the next call of<br>
> > rtems_rate_monotonic_period() will only release one following instance and<br>
> > manipulate the task period with the calling moment + the next length of<br>
> > period. However, this way of scheduling is in fact changing the 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 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.</p>
<p dir="ltr">There are no standard requirements for how to deal with missed periods. The current implementation does precisely what is required for RMS per the original paper and nothing more.</p>
<p dir="ltr">We can discuss what to do on missed periods but having academic papers to back that up would be ideal.</p>
<p dir="ltr">> > The period of expired task is shifted and unpredictable. This should be<br>
> > calculated correctly and rapidly by taking the time point of first period<br>
> > released. The deadline of watchdog in this case should be assigned 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>
> > I have enhanced this feature in the system by adding three additional<br>
> > counters in Rate_monotonic_Control structure and one more function to do the<br>
> > correct assignment of deadline and job release. I also prepare a heuristic<br>
> > example to demonstrate the results. I'm going to fix the case for 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>
> > Please let me know if this feature is sound and essential. I can 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>
> > 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>
> > _______________________________________________<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">http://lists.rtems.org/mailman/listinfo/users</a><br>
> _______________________________________________<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">http://lists.rtems.org/mailman/listinfo/users</a><br></p>