Measure Scheduling Latency Using Clock Functions

Latency Is What Users Feel

Throughput averages hide scheduling latency: the time from a thread becoming runnable to actually receiving CPU. A web server can post high requests-per-second while still stuttering if wakeups wait milliseconds behind a long-running batch job.

Measuring Wake-to-Run

Use monotonic clocks around scheduler events:

• Record CLOCK_MONOTONIC when marking a task RUNNABLE
• Record again on first dispatch after wakeup
• Latency = dispatch_time - wakeup_time

For example, if a thread becomes ready at t=1000 us and runs at t=1450 us, scheduling latency is 450 us for that event.

Why This Matters in Production

Scheduling latency is precisely what tools like cyclictest measure to certify Linux's PREEMPT_RT patches for real-time use in robotics and audio production, where a single 50-microsecond spike can cause an audible glitch or a missed control loop deadline. Using CLOCK_MONOTONIC instead of CLOCK_REALTIME here matters in practice too: NTP adjustments to wall-clock time have caused real latency-measurement bugs in production monitoring code.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will instrument your simulator or harness with timestamp hooks and print percentile summaries (p50/p95). This task asks you to compare RR quantum sizes and show how smaller slices cut latency at the cost of more context switches.