Part 2: PAS 시뮬레이터 / 에뮬레이터

시뮬레이터 vs 에뮬레이터

두 도구는 모두 PAS 알고리즘의 동작을 시각화하지만, sleep 결정이 다음 I/O에 미치는 영향을 반영하는지 여부에 핵심적인 차이가 있습니다.

	시뮬레이터 (Simulator)	에뮬레이터 (Emulator)
입력	사전에 주어진 I/O latency trace	사전에 주어진 I/O latency trace
I/O latency	trace 값을 그대로 사용 (sleep 결정과 무관)	oversleep 시, 앱이 관측하는 latency에 sleep 시간이 반영됨
피드백 루프	없음 — sleep duration이 길어져도 trace의 다음 latency는 변하지 않음	있음 — 과도한 sleep → oversleep → 관측 latency 증가 → 다음 결정에 영향
목적	PAS의 트래킹 능력 확인: 주어진 trace를 얼마나 잘 따라가는가?	PAS의 실제 동작 확인: oversleep이 실제로 발생할 때 알고리즘이 어떻게 반응하는가?
shelving 관찰	불가 (피드백이 없으므로)	가능 — LHP 에뮬레이터에서 shelving 발생을 관찰할 수 있음

왜 구분이 중요한가? 시뮬레이터에서 PAS가 trace를 잘 추적한다고 해서, 실제 시스템에서도 잘 동작한다고 단정할 수 없습니다. 에뮬레이터는 oversleep → 관측 latency 증가라는 현실의 피드백 루프를 재현하므로, 알고리즘의 안정성을 더 엄밀하게 검증할 수 있습니다.

예: 시뮬레이터에서는 step-down trace(latency 급감)에서 PAS가 문제없이 추적하지만, 에뮬레이터에서는 잠시 oversleep이 발생하고 이를 복구하는 과정이 나타납니다.

도식으로 보는 차이

[시뮬레이터]
trace: 50us, 50us, 10us, 10us, ...    (고정 입력)
PAS:   40us, 45us, 48us, 30us, ...    (sleep 결정)
                                       sleep이 길어져도 trace는 변하지 않음

[에뮬레이터]
trace: 50us, 50us, 10us, 10us, ...    (디바이스 실제 latency)
PAS:   40us, 45us, 48us, 30us, ...    (sleep 결정)
                 ↓ step-down 발생
sleep=48us > device=10us → oversleep!
→ 앱 관측 latency = 48us + cs_overhead (실제 10us가 아님)
→ 다음 PAS 결정에 이 부풀려진 값이 영향

도구 실행

먼저 시뮬레이터로 PAS의 기본 트래킹 동작을 확인한 뒤, 에뮬레이터에서 동일한 trace로 oversleep 효과를 비교하세요.

PAS 시뮬레이터

피드백 루프 없음.
PAS가 주어진 latency trace를 얼마나 잘 추적하는지 확인합니다. 파라미터(UP, DN, 초기값)를 조절하며 수렴 속도를 관찰하세요.

시뮬레이터 실행 →

PAS 에뮬레이터

피드백 루프 있음.
Oversleep 시 관측 latency가 증가하는 효과가 반영됩니다. Step-down trace에서 시뮬레이터와 다른 결과가 나타나는지 비교하세요.

에뮬레이터 실행 →

실습 가이드

시뮬레이터에서 "step" 패턴을 선택하고 실행 → PAS가 latency 변화를 추적하는 과정을 관찰
에뮬레이터에서 동일한 "step" 패턴을 실행 → step-down 구간에서 oversleep이 발생하는지 확인
두 결과를 비교: 시뮬레이터에서는 즉시 적응하지만, 에뮬레이터에서는 oversleep → 복구 과정이 보임
"ZSSD" 실제 trace로도 비교해 보세요 — 실제 디바이스의 latency 변동성을 확인할 수 있습니다

다음 단계

PAS의 동작을 확인했다면, LHP 에뮬레이터에서 기존 hybrid polling의 문제점을 관찰하고 PAS와 비교해 보세요.

Part 3: LHP 에뮬레이터로 이동 → LHP의 epoch 기반 조정과 latency shelving 문제를 직접 관찰합니다