[PATCH 2/2] doc: Clarify rate-monotonic statistics

[Joel Sherrill]

On 12/12/2014 08:22 AM, Sebastian Huber wrote:
> On 12/12/14 15:10, Joel Sherrill wrote:
>> On December 12, 2014 8:04:39 AM CST, Sebastian Huber<sebastian.huber at embedded-brains.de>   wrote:
>>>> ---
>>>> doc/user/rtmon.t | 18 ++++++++++++++----
>>>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/doc/user/rtmon.t b/doc/user/rtmon.t
>>>> index 7786e76..92f6b0b 100644
>>>> --- a/doc/user/rtmon.t
>>>> +++ b/doc/user/rtmon.t
>>>> @@ -52,10 +52,10 @@ A clock tick is required to support the
>>>> functionality provided by this manager.
>>>>
>>>> @subsection Period Statistics
>>>>
>>>> -This manager maintains a set of statistics on each period.  These
>>>> -statistics are reset implictly at period creation time and may be
>>>> -reset or obtained at any time by the application.  The following
>>>> -is a list of the information kept:
>>>> +This manager maintains a set of statistics on each period object.
>>>> These
>>>> +statistics are reset implictly at period creation time and may be
>>>> reset or
>>>> +obtained at any time by the application.  The following is a list of
>>>> the
>>>> +information kept:
>>>>
>> I am not spotting the language change in this.
> From
>
> This manager maintains a set of statistics on each period.
>
> to
>
>
> This manager maintains a set of statistics on each period object.
>
>
>
Oh.. just added the word "object". OK.
>>>> @itemize @bullet
>>>> @item @code{owner}
>>>> @@ -93,6 +93,16 @@ during executions of the periodic loop.
>>>>
>>>> @end itemize
>>>>
>>>> +Each period is divided into two consecutive phases.  The period starts
>>>> with the
>>>> +active phase of the task and is followed by the inactive phase of the
>>>> task.  In
>>>> +the inactive phase the task is blocked and waits for the start of the
>>>> next
>>>> +period.  The inactive phase is skipped in case of a period miss.  The
>>>> wall time
>>>> +includes the time during the active phase of the task on which the
>>>> task is not
>>>> +executing on a processor.  The task may be blocked waiting for a
>>>> resource or a
>>>> +higher priority task executes instead.  In case the wall time exceeds
>> The or a phrase seems like it cod be worded better.
> Sorry, what do you mean?
>
could be worded better. I must want fish this morning. :)

The task may be blocked waiting for a resource or a higher priority
task executes instead.

This leaves out the concept of delaying and the second phrase
might be better if "a higher priority tasks executes, thus preventing
it from executing."

I don't think there are other conditions. In general, a missed period
where CPU time is within normal bounds and wall time is high is an
indication of priority inversion or system overload. If the system
technically meets the schedulability rules, then it is likely a
priority inversion in my experience. Or someone just screwed up
the priorities. :)
>>>> the
>>>> +period time, then this is a period miss.  So the gap between the
>>>> maximum wall
>>>> +time and the period time is the safety margin between a period miss or
>>>> success.
>> Don't use So.
>>
>> I wouldn't call it a safety margin. Just a margin.
>>