<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 4:03 PM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 3:00 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
>From the theory side, this problem is usually addressed using a<br>
(sporadic) server. Basically, you create some periodic task at the<br>
prioritization that you want (e.g., the shortest relative deadline in<br>
the system to usually get the highest priority) and then the server<br>
uses its budget to execute the event-based tasks. There are several<br>
variations with pros/cons. However, these do not allow for the<br>
event-based tasks to be the most responsive in general; with EDF,<br>
unless you use relative deadline = 1, there can always be some other<br>
task with a shorter absolute deadline. Also, if the server budget gets<br>
consumed you have to wait for replenishment. I'm not up-to-date with<br>
the latest in SMP schedulers with servers. (Shame on me.)<br></blockquote><div><br></div><div>I wondered about a band of high rate periodic tasks that check</div><div>for the condition and do it or go to sleep. Binds them to periods</div><div>which introduces latency so that's bad.</div><div><br></div><div>This would work but likely not be acceptable.</div></div></div></blockquote><div><br></div><div>A tickless scheduler would allow for a much finer scheduling quantum.  At that point, an ISR could waken a task and hand it a new deadline.  rtems_event_receive_periodic() combined with rtems_event_send_deadline()?  Or perhaps some kind of rate_monotonic_interrupt_server?  At least in my case, the task really is rate-monotonic, but the timing source is both asynchronous with respect to the kernel tick and much finer.<br></div><div> <br></div></div>-- <br><div dir="ltr" class="gmail_signature">Jonathan Brandmeyer<br></div></div>