Part 2: PAS Simulator / Emulator — Systems Technology 2026

Simulator vs Emulator

Both tools visualize PAS algorithm behavior, but the key difference lies in whether sleep decisions affect the next I/O's observed latency.

	Simulator	Emulator
Input	Pre-defined I/O latency trace	Pre-defined I/O latency trace
I/O Latency	Uses trace values as-is (independent of sleep decisions)	On oversleep, observed latency reflects sleep time
Feedback Loop	None — longer sleep doesn't change the next trace latency	Present — excessive sleep → oversleep → increased observed latency → affects next decision
Purpose	Verify PAS tracking ability: how well does it follow the given trace?	Verify PAS real behavior: how does the algorithm react when oversleep actually occurs?
Shelving	Cannot observe (no feedback)	Observable — shelving can be seen in the LHP emulator

Why does this distinction matter? Even if PAS tracks the trace well in the simulator, it doesn't guarantee good performance in a real system. The emulator reproduces the real-world feedback loop of oversleep → increased observed latency, enabling more rigorous validation of algorithm stability.

Example: In the simulator, PAS tracks a step-down trace (sudden latency drop) without issues, but in the emulator, temporary oversleep occurs and the recovery process becomes visible.

Visual Comparison

[Simulator]
trace: 50us, 50us, 10us, 10us, ...    (fixed input)
PAS:   40us, 45us, 48us, 30us, ...    (sleep decisions)
                                       longer sleep doesn't change trace

[Emulator]
trace: 50us, 50us, 10us, 10us, ...    (actual device latency)
PAS:   40us, 45us, 48us, 30us, ...    (sleep decisions)
                 ↓ step-down occurs
sleep=48us > device=10us → oversleep!
→ app observed latency = 48us + cs_overhead (not the actual 10us)
→ this inflated value affects the next PAS decision

Launch Tools

First check PAS's basic tracking behavior with the simulator, then compare oversleep effects with the emulator using the same trace.

PAS Simulator

Feedback loop: None.
See how well PAS tracks a given latency trace. Adjust parameters (UP, DN, initial value) and observe convergence speed.

Launch Simulator →

PAS Emulator

Feedback loop: Present.
Oversleep is reflected in observed latency. Compare with the simulator on step-down traces to see the difference.

Launch Emulator →

Lab Guide

In the Simulator, select the "step" pattern and run → observe how PAS tracks latency changes
In the Emulator, run the same "step" pattern → check if oversleep occurs during step-down
Compare the results: the simulator adapts immediately, but the emulator shows oversleep → recovery
Try the "ZSSD" real trace as well — observe the latency variability of a real device

Next Steps

After observing PAS behavior, explore the LHP emulator to see the problems with existing hybrid polling and compare with PAS.

Part 3: LHP Emulator → Observe LHP's epoch-based adjustment and latency shelving problem