Scheduler Tick

A scheduler tick is a periodic timer event used by an operating system or RTOS to update time, release timed work, account execution and trigger scheduling decisions. In simple systems, many delays, timeouts and task releases are rounded to this tick.

The scheduler tick matters because it turns continuous time requirements into discrete timer events. A 1 ms tick may be acceptable for a supervisory task and unacceptable for a 500 us control loop. The tick is not just a software constant; it is tied to a timer source, interrupt priority, clock tolerance and scheduler implementation.

Tick Period

If the tick frequency is:

then the tick period is:

For:

the tick period is:

Timed work released on the next tick can see quantization delay up to nearly one tick before interrupt latency and scheduler delay are added.

Quantization Delay

If a requested wakeup time falls between ticks, the scheduler may round it to a later tick. A conservative quantization bound is:

For deadline analysis, a simple bound may use:

unless the implementation proves tighter behavior. This quantization can appear as release jitter:

where J_ISR is timer-interrupt latency and J_sched is scheduler dispatch delay.

Rounding Rule

The scheduler should document how requested times are mapped to ticks. A delay request may be rounded up, rounded down, or converted to a minimum number of complete ticks. For hard deadlines, rounding down can wake a task early, while rounding up can consume measured deadline margin.

A safe timing review usually treats the rounding error as:

unless the kernel documentation and trace evidence justify a smaller value. The rule should be tested with requests placed just after a tick boundary and just before the next boundary, because those cases reveal the maximum and minimum delay behavior.

Worked Timing Screen

Suppose a task has deadline:

bounded execution and interference:

and a tick period:

Using a conservative one-tick release quantization allowance:

The margin is:

If the same task moves to a 2 ms tick:

and:

The software workload did not change, but the timer base broke the deadline.

Tickless Behavior

Tickless kernels avoid periodic ticks when no timed event is due. They can reduce power and interrupt overhead, but they move correctness into one-shot timer programming, wakeup latency and clock-source behavior.

Tickless mode is not automatically better for real time. The review should show timer compare accuracy, wake-from-sleep latency, missed-compare handling, clock drift, interrupt priority and whether long sleep intervals affect watchdog or diagnostic timestamps.

Validation Evidence

Useful evidence includes timer source, clock frequency, prescaler, tick period, tick interrupt priority, measured tick jitter, timestamp placement, wakeup trace, task-ready trace, tickless configuration, timeout rounding rule, watchdog dependency and deadline-miss counters.

The measured tick interval should satisfy:

and the release path should preserve deadline margin:

Relationship To Neighbor Terms

Release jitter is the task-activation variation that may include tick quantization. Interrupt latency affects when the tick handler starts. Preemption latency affects when a released task actually runs. Timestamp uncertainty affects whether measured tick timing can be trusted.

Hyperperiod calculations should use periods that match the actual scheduler time base. Watchdog timers may depend on scheduler tick progress, but a watchdog tick does not prove task deadline compliance.

Common Mistakes

The most common mistake is choosing an RTOS tick because it is convenient rather than because it fits the timing budget. Another is measuring execution time but ignoring wakeup quantization. A third is enabling tickless sleep and assuming periodic timing remains unchanged.

A strong scheduler-tick review states the timer source, tick period, rounding rule, interrupt priority, release-jitter contribution, tickless behavior, measured trace and deadline margin.