실시간 성능 분석 — WCET·Jitter·Deadline Miss 측정

#한 줄 요약

**“평균이 아니라 worst”**입니다. Real-time에서는 max ≤ deadline이 기준이며, 일반 시스템과 평가 기준 자체가 다릅니다.

#Real-Time의 핵심 지표

#WCET — 측정 4 방법

#1. Static Analysis (정적 분석)

소스와 CPU 모델로부터 모든 path의 WCET를 계산합니다. 상용 도구로는 aiT(AbsInt)와 Bound-T가 있습니다.

$\text{WCET}_{\text{func}} = \max_{p \in \text{paths}} \text{WCET}(p)$

수학적 보장이 장점입니다. 다만 비싸고 setup이 복잡합니다.

#2. Measurement-Based

1
uint32_t max_cycles = 0;
2
for (int i = 0; i < N; i++) {
3
    uint32_t t = DWT->CYCCNT;
4
    work(input[i]);
5
    uint32_t elapsed = DWT->CYCCNT - t;
6
    if (elapsed > max_cycles) max_cycles = elapsed;
7
}
8
WCET_est = max_cycles * SAFETY_FACTOR;   // 보통 1.2-1.5×

Coverage가 보장되지 않습니다. 측정하지 않은 path가 더 느릴 가능성이 있습니다.

#3. Hybrid

Static analysis로 bound를 계산하고 measurement로 typical case를 잡습니다. 정밀도와 비용의 균형이 좋습니다.

#4. Probabilistic WCET (pWCET)

확률 분포로 표현합니다. 예를 들어 “99.999% 확률로 80 µs 미만”처럼 말합니다. Extreme Value Theory를 활용하며, 자동차나 항공 분야에서 도입되고 있습니다.

#Jitter 분석

1
// 1ms 주기 task
2
TickType_t xLast = xTaskGetTickCount();
3
while (1) {
4
    uint32_t t = DWT->CYCCNT;
5
    process();
6
    vTaskDelayUntil(&xLast, pdMS_TO_TICKS(1));
7

8
    uint32_t period_actual = DWT->CYCCNT - t;
9
    uint32_t period_expected = SystemCoreClock / 1000;
10
    int32_t jitter = period_actual - period_expected;
11
    log_jitter(jitter);
12
}

Jitter 분포를 보면서 기준 ±10% 안이면 OK로 판정합니다. 더 크면 원인을 추적합니다.

#Jitter 원인

• Higher-priority preemption
• ISR latency
• Cache miss (Cortex-A)
• DMA contention
• Tickless wake delay

#Deadline Miss 카운트

1
void task(void *arg) {
2
    TickType_t deadline = xTaskGetTickCount() + DEADLINE_TICKS;
3
    while (1) {
4
        if (xTaskGetTickCount() > deadline) {
5
            miss_count++;
6
        }
7
        process();
8
        deadline = xTaskGetTickCount() + DEADLINE_TICKS;
9
    }
10
}

Counter를 누적하고 주기적으로 출력합니다. Production에서는 miss rate에 대한 alerting을 둡니다.

#Tardiness — 얼마나 늦었나

Deadline을 넘긴 시간을 의미합니다. 단순 miss count보다 정보량이 많습니다.

1
int32_t tardiness = (now - deadline);  // > 0이면 늦음
2
log_tardiness(tardiness);

Tardiness 분포를 보면서 얼마나 심각한지를 판정합니다.

#Cyclictest — Linux RT 표준

1
sudo cyclictest -p 80 -t 1 -i 1000 -l 100000 -m
2

3
# T: 0 (12345) P:80 I:1000 C:100000 Min:5 Avg:7 Max:23

p99와 max latency를 측정합니다. PREEMPT_RT에서 worst-case를 검증할 때 씁니다. 핵심은 수일에 걸친 측정으로 outlier를 capture하는 것입니다.

#Latency Budget 분석

1
PID 1ms 주기, deadline 1ms
2

3
ISR latency      :  50 ns
4
Scheduler latency:  2 µs
5
Context switch  :  3 µs
6
PID compute    :  95 µs (WCET)
7
Actuator write  :  10 µs
8
────────────────────────
9
Total worst case: ~110 µs
10

11
여유 = 890 µs (89%) — 안전

Component별로 budget을 고정해 두고, 컴포넌트별로 WCET를 분석합니다.

#Hard vs Soft RT — 측정 차이

#Schedulability Analysis

WCET를 알면 전체 시스템의 schedulability를 증명할 수 있습니다.

#Utilization Bound (Liu-Layland)

$\sum_{i=1}^{n} \frac{C_i}{T_i} \leq n \cdot (2^{1/n} - 1)$

#Response Time Analysis (RTA)

각 task의 worst response time은 다음과 같이 구합니다.

$R_i = C_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil \cdot C_j$

Iterative하게 풉니다. $R_i \leq D_i$(deadline)이면 schedulable입니다.

Cheddar와 SymTA/S 같은 도구가 이 과정을 자동화합니다.

#Release Jitter

Task가 정확히 release되어야 할 시점과 실제 시작 시점의 차이를 의미합니다.

1
이상: release at t=0, 5, 10, 15, ... ms (정확 5ms 주기)
2
실제: t=0.05, 5.12, 9.98, 15.30, ...
3
release jitter = 5.30 - 5.00 = 0.30 ms

원인으로는 tick granularity, higher-priority preemption, ISR latency가 있습니다.

#측정 시 함정

#Probe Effect

측정 코드 자체가 측정 대상에 영향을 줍니다. printf를 추가하면 1 ms가 지연되기도 합니다.

해결책은 light-weight tracing(DWT, GPIO, ring buffer)입니다.

#Thermal Drift

장시간 부하가 걸리면 온도가 상승하고 throttling이 일어납니다. 측정 후반부의 latency가 증가합니다.

해결책은 fan이나 heatsink를 두고 thermal sensor로 모니터링하는 것입니다.

#Stationarity

부팅 직후에는 시스템이 cold 상태였다가 점차 warm해집니다. 최소 1분 warmup 후에 측정합니다.

#자주 하는 실수

⚠️ Avg WCET 사용

평균은 WCET가 아닙니다. Max에 safety factor를 곱한 값을 씁니다.

⚠️ Single workload만

Worst-case를 유발하는 input은 다릅니다. 대표 input set을 준비해야 합니다.

⚠️ Lab 환경 = production

Production 환경에는 DMA, noise, thermal이 추가됩니다. 실 환경에서 측정해야 합니다.

⚠️ Linux mainline = real-time

Mainline은 best-effort입니다. PREEMPT_RT 패치만 RT-capable입니다.

#정리

• Real-time에서는 WCET, jitter, deadline miss, tardiness를 측정합니다.
• WCET 측정에는 4가지 방법이 있습니다. static, measurement, hybrid, probabilistic입니다.
• Cyclictest가 Linux RT의 표준입니다.
• Latency budget 분석으로 컴포넌트별 WCET 책임을 나눕니다.
• Schedulability proof는 RTA와 WCET의 조합으로 가능합니다.

다음 편은 벤치마킹 기초입니다. 재현성과 warmup, 노이즈 제거를 다룹니다.

#관련 항목

• 1-04: 통계적 분석
• 1-06: 벤치마킹 기초
• Practical RTOS Internals 1-10