When configuring orchestration as:
design.add_program("cvd_adaptive", move |design, builder| {
builder.with_start_action(Invoke::from_tag(&t1_tag, design.config())) // This action sleeps 5s
.with_run_action(
SequenceBuilder::new()
.with_step(SyncBuilder::from_design("cyclic_evt", &design)) // This is cyclic event, ie 50ms
.with_step(Invoke::from_tag(&t2_tag, design.config()))
.build(),
).with_stop_action(Invoke::from_tag(&t3_tag, design.config()),Duration::from_secs(10));
It will lead to very fast programs runs untill the Sync action does not catch up on a missed ticks during init sleep time.
So it will simply be always ready until it compensate 5s / 50ms ticks that it shall have handled before.
We need to:
- Expose time event strategy for this issues, ie
- Bulk - does what it does now
- Delay - schedule at a regular period from the place where a
tick is requested
- Skip - keep up with regular ticks at
period counting from start. This means that is something is delayed, next tick will be sonner then period time but will be aligned to start + tick*period timepoint
At the end probably for Orchestrator the last one is the use case mostly used.
@PiotrKorkus missing CIT for that -> #401
Original report: https://github.com/qorix-group/inc_orchestrator_internal/issues/400
When configuring orchestration as:
It will lead to very fast programs runs untill the Sync action does not catch up on a missed ticks during init sleep time.
So it will simply be always ready until it compensate 5s / 50ms ticks that it shall have handled before.
We need to:
tickis requestedperiodcounting from start. This means that is something is delayed, next tick will be sonner thenperiod timebut will be aligned to start + tick*period timepointAt the end probably for Orchestrator the last one is the use case mostly used.
@PiotrKorkus missing CIT for that -> #401