How do I find an appropriate WCET value for a runnable?

[jiangxiaoke]

Please provide the following info (tick the boxes after creating this topic):
Software Version
[*] DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
[*] Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
[*] DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
1.9.2.10884
other

Host Machine Version
[*] native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

How do I find an appropriate WCET value for a runnable? What other effects does WCET have on task scheduling, apart from causing some runnables fusion? What happens if the actual execution time of a runnable exceeds the WCET?

[VickNV]

I’ll check these with our team and get back to you. Thanks.

[VickNV]

@jiangxiaoke

How do I find an appropriate WCET value for a runnable?

The stmanalyze tool generates csv and html reports that show the runtime distributions of the execution time for each runnable. Depending on prioritization between safety and performance, an appropriate percentile value should be chosen for the WCET value. 99 percentile (99p) will provide a large cushion but it can waste utilization if the runnable’s execution distribution is not tight (i.e. worst case seen is far from the average case), whereas 50 percentile (50p) will provide no cushion, and you’ll see a lot of overruns. The balance between these is use-case dependent.

@jiangxiaoke

What other effects does WCET have on task scheduling, apart from causing some runnables fusion?

WCET helps us decide the order of scheduling on each individual engine, and across all the engines collectively.

@jiangxiaoke

What happens if the actual execution time of a runnable exceeds the WCET?

The runtime mechanism has slack redistribution built into it. If one runnable overruns but another in the same dependency chain runs for lesser time than its WCET, it will automatically be compensated, and the frame won’t be delayed. We do not preempt runnables. If, however, a lot of runnables overrun resulting in a frame overrun, there are two policy decisions available: skip the next frame and wait until the next period boundary, or start the next frame immediately, which can be covered by the -m/--no-skip-on-overrun flag for stm runtime.