RgMaxTime Telemetry

[Nathan Cheek]

I tried to use the `RgMaxTime` telemetry channel provided by `ActiveRateGroup`. The comment for this channel is "Max execution time rate group", so I assumed it tracked the most time spent running that specific rate group in any cycle.

However, this does not seem to be the case. Tracing the timer values used, I see that a `cycleStart` timer value is passed into the `RateGroupDriver`. The driver then loops through all RateGroup outputs and calls the `CycleOut` port for each RateGroup where currentTick % rgDivider == 0. That same `cycleStart` timer value is passed into each RateGroup's `CycleIn` port where it is used to calculate the `RgMaxTime`.

This means that `RgMaxTime` for one RateGroup actually depends on the execution time of any other RateGroups with lower port numbers that happen to fire during the same cycle (i.e. a RateGroup with Divider=5 and a lower port number would always fire in the same cycle as a RateGroup with Divider=10, and the RGDiv5 execution time would be included in the RGDiv10 calculated execution time).

Is that expected behavior, or maybe I'm misunderstanding something? Should the channel description be changed to account for this?

Otherwise, as long as it's being denoted "rate group execution time" I think the counter should only compare start and end time within each RateGroup's `CycleIn` port, instead of using the upstream `cycleStart` time.

[Nathan Cheek]

I guess I should respond to myself to clarify one important thing. I'm running on a single-threaded processor with a bare metal scheduler.

I suppose how the `ActiveRateGroup` is currently written, a multithreaded system could run multiple RateGroups simultaneously, and it could make sense to see how long it takes from queuing up the RateGroup to actually finishing its execution.

I'd still argue though that it's confusing to call that execution time. It's more like <time in scheduler queue> + <execution time>.

[Peet, Sterling L]

Perhaps what you really want is called “Wall Clock Time”?  Or rather, that is what seems to be measured, rather than the CS definition of execution time?  Just trying to sort out what you are asking about…

Thanks,

Sterling Peet

Space Systems Design Lab at Aerospace Engineering
Engineering Science and Mechanics Building
Georgia Institute of Technology
620 Cherry St. N.W. Atlanta GA 30332

Web: http://ssdl.gatech.edu/sterling-peet
Ph: (404) 385-7641

On Mar 25, 2021, at 4:10 PM, Nathan Cheek <natha...@gmail.com> wrote:

NATHA...@GMAIL.COM appears similar to someone who previously sent you email, but may not be that person. Learn why this could be a risk

Feedback

-- 
You received this message because you are subscribed to the Google Groups "F´ Community Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fprime-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fprime-community/CA%2BEfFvb%3DD7Lvn%2BoRQx4jir4t9nsQcJckCjP%2BCn6EGzjg9sc%2BJw%40mail.gmail.com.

[lestarch]

My understanding is that time is used to look for failures to keep up with deadlines.  Thus is must time from the scheduled execution time through the completion of the rate group.  If that number exceeds the expected cycle time it has failed to meet this deadline.  This number is used to to update or adjust the cycle time during testing in case one needs to slow down the cycle because it is slipping.

In fully threaded systems, this "max cycle time" should account for delays caused by not having the thread scheduled as these delays are likely to be encountered for each run of the rategroup and will always burden the cycle time and affect deadlines.

With the baremetal scheduler all threading is run sequentially and it pretends to be a multi-threaded system.  In this case the timing breaks down entirely as **all** of the time of other rategroups is added to the rategroup, not just scheduling delays.  The active rate group wasn't ever intended to be run on a fake scheduler and a "passive rate group driver" was expected.  By executing everything serially, we may be keeping deadlines just from the execution of the individual rate group.

I see what you mean by the name confusion and we could track an issue about cleaning that up a bit so the name is more precise.

-Michael

[Timothy Canham]

Michael is correct. In a true multitasking system with rate groups, it is typical that a rate group is started by a periodic hardware interrupt, and it has to finish by the time the next interrupt fires. If you want to measure the rate group execution time, you need to start when the interrupt fires and end when the rate group task execution ends to see how close you are getting to overrunning your cycle. This measurement starts outside the rate group ideally by an ISR that calls the RateGroupDriver, and ends in the ActiveRateGroup when the last port call has completed.