🔧 버스 Utilization(점유율)의 비밀: 왜 100%를 목표로 하지 않는가?
SoC 설계와 컴퓨터 구조에서 버스 Utilization(점유율)은 시스템 성능을 좌우하는 핵심 지표입니다. 대역폭이 아무리 넓어도 점유율 관리를 잘못하면 시스템 전체가 멈출 수 있습니다. 이 글에서는 왜 버스 점유율을 100%로 쓰면 안 되는지, 그 기술적 배경과 실무 가이드라인을 상세히 정리합니다.
📊 1. Utilization(점유율)이란 무엇인가?
버스 Utilization은 전체 가동 시간 중 실제로 데이터가 전송되고 있는 시간의 비율을 의미합니다. 수식으로 표현하면 다음과 같습니다.
Utilization(%) = (실제 처리량 / 이론적 최대 대역폭) × 100
점유율 수준에 따른 버스 상태를 살펴보면:
✅ Utilization 10% — 버스가 한가한 상태. 요청이 오면 즉시 처리됩니다.
⚠️ Utilization 50% — 적당한 부하. 약간의 대기가 발생하지만 안정적입니다.
🔴 Utilization 90% — 과부하 상태. 새 요청은 긴 대기열에 합류해야 합니다.
핵심은 버스가 '공유 자원(Shared Resource)'이라는 점입니다. CPU, GPU, DMA 컨트롤러 등 여러 마스터가 하나의 버스를 나누어 쓰기 때문에, 점유율이 높다는 것은 자원 경쟁(Contention)이 치열하다는 의미입니다.
📈 2. 왜 100%를 쓰면 안 될까? — 대기행렬 이론의 경고
점유율을 40~60%로 제한하는 가장 큰 이유는 대기 시간(Latency)의 급격한 증가 때문입니다. 이는 통계학의 대기행렬 이론(Queuing Theory)으로 정확히 설명됩니다.
M/M/1 큐 모델 핵심 공식
Latency ∝ 1 / (1 - ρ)
ρ = Utilization (0 ~ 1)
이 공식의 의미를 구체적인 수치로 살펴보겠습니다.
| 점유율 (ρ) |
1/(1-ρ) 배수 |
체감 상태 |
| 10% |
1.1배 |
매우 쾌적 |
| 30% |
1.4배 |
쾌적 |
| 50% |
2배 |
보통 (권장 한계) |
| 70% |
3.3배 |
⚠️ 주의 필요 |
| 90% |
10배 |
🔴 위험 |
| 99% |
100배 |
🚨 시스템 마비 |
점유율이 50%일 때 대기 시간은 기본의 2배 수준이지만, 90%가 되면 10배, 99%면 100배로 폭증합니다. 100%에 도달하면 이론적으로 대기 시간이 무한대가 되어 시스템이 완전히 멈춥니다.
💥 3. 임계치를 넘으면 발생하는 4가지 기술적 재앙
점유율이 Safe Zone을 벗어나면 다양한 연쇄 장애가 발생합니다. 각각의 메커니즘을 깊이 살펴보겠습니다.
⚡ ① 중재(Arbitration) 오버헤드 증가
버스를 쓰려는 마스터가 많아지면 누가 먼저 사용할지 결정하는 Arbiter의 부담이 급증합니다. AMBA AXI 같은 프로토콜에서는 Round-Robin, Fixed Priority, Weighted Fair 등의 중재 방식을 사용하는데, 경쟁이 치열해지면 중재 알고리즘 자체가 병목이 됩니다.
데이터 전송보다 "순서 정하기"에 더 많은 사이클이 소모되는 역설적 상황이 발생합니다. 특히 AXI의 경우, Outstanding Transaction이 많아지면 ID 관리와 reordering 로직까지 복잡해져 실질적인 throughput이 급감합니다.
📦 ② 데이터 버스트(Burst) 전송의 파괴
효율적인 전송을 위해 AXI는 데이터를 INCR, WRAP, FIXED 같은 Burst 모드로 묶어 전송합니다. 하지만 점유율이 높으면 다른 마스터가 중간에 끼어드는 Preemption이 빈번해집니다.
연속적인 Burst가 끊기면 매번 새로운 Address Phase부터 시작해야 하므로 프로토콜 오버헤드가 가중됩니다. 예를 들어, 16-beat Burst 하나가 4-beat Burst 네 개로 쪼개지면, Address Phase가 1회에서 4회로 증가하여 유효 대역폭(Effective Bandwidth)이 크게 떨어집니다.
🔄 ③ 우선순위 역전(Priority Inversion)과 지터(Jitter)
실시간성이 중요한 작업(오디오 DMA, 디스플레이 컨트롤러, 비디오 디코더 등)은 정해진 데드라인 안에 데이터가 도착해야 합니다.
점유율이 높으면 우선순위가 낮은 긴 Burst가 버스를 점유하는 동안 높은 우선순위의 짧은 요청이 대기하는 Priority Inversion이 발생합니다. 이로 인해:
→ 디스플레이 화면이 깨지거나(Tearing) 끊기는 현상
→ 오디오 스트리밍에서 팝/클릭 노이즈 발생
→ 센서 데이터 수집의 타이밍 오차(Jitter) 누적
💾 ④ 버퍼 오버플로우(Buffer Overflow)와 Stall
버스가 데이터를 빠르게 수용하지 못하면, 데이터를 보내려는 마스터 내부의 FIFO 버퍼가 가득 찹니다.
Write Buffer가 Full이 되면 CPU Pipeline 자체가 Stall되어 명령어 실행이 멈추고, Read Data가 제때 오지 않으면 Cache Miss 처리가 지연되어 전체 프로세서 성능이 급락합니다. 최악의 경우 데이터 손실(Data Loss)이 발생하여 시스템 안정성까지 위협합니다.
🎯 4. 실무 가이드라인: Safe Zone은 어디인가?
고성능 SoC 설계에서 권장하는 버스 점유율 타겟은 애플리케이션 도메인에 따라 다릅니다.
| 도메인 |
권장 점유율 |
비고 |
| 🚗 실시간 시스템 (RTOS, Automotive) |
30~40% 미만 |
안전성 최우선, ISO 26262 등 기능안전 규격 준수 |
| 📱 일반 SoC (Mobile, PC) |
50~60% |
성능과 비용의 균형점, 트래픽 스파이크 대응 여유 확보 |
| 💿 벌크 데이터 전송 (Storage, DMA) |
70~80% |
Latency 희생 감수, Throughput 최대화 목적 |
성능 평가에서 "Utilization 50%에서 Latency가 일정하게 유지되는가?"를 확인하는 이유는, 갑작스러운 트래픽 부하(Traffic Spike)에도 시스템이 안정적으로 동작할 수 있는 여유(Headroom)가 있는지 검증하기 위함입니다.
🛠️ 5. 점유율 문제를 해결하는 설계 기법
점유율 문제에 직면했을 때 설계자가 활용할 수 있는 대표적인 해결 방법들입니다.
▶ 버스 분리(Bus Splitting) — 하나의 버스를 기능별로 분리하여 트래픽을 분산합니다. AMBA의 경우 AXI Interconnect를 다중 포트로 구성하여 병목을 제거합니다.
▶ QoS(Quality of Service) 설정 — 실시간 트래픽(Display, Audio)에 높은 QoS 레벨을 부여하여 버스 점유율이 높아져도 우선 처리되도록 보장합니다. AXI QoS 시그널(AxQOS)을 활용합니다.
▶ 캐시 최적화 — L2/L3 캐시 적중률을 높여 메모리 버스 접근 자체를 줄입니다. 캐시 프리페치(Prefetch)와 캐시 라인 크기 조정이 핵심입니다.
▶ 대역폭 조절(Bandwidth Regulation) — 특정 마스터가 버스를 독점하지 못하도록 Token Bucket이나 Rate Limiter를 적용합니다. 과도한 벌크 전송으로 인한 다른 마스터의 Starvation을 방지합니다.
🔍 6. 도로 교통과 버스 점유율의 비유
버스 Utilization을 제한하는 것은 고속도로에 차를 100% 꽉 채우지 않는 것과 동일한 원리입니다.
🛣️
30% 점유
자유 흐름 — 원하는 속도로 주행
🚗🚕🚙
60% 점유
원활한 흐름 — 가끔 감속 필요
🚗🚗🚗🚗
95% 점유
완전 정체 — 아무도 못 움직임
도로에 차가 100% 차 있으면 아무도 움직이지 못하는 교통 체증이 발생하듯, 버스도 적절한 빈 공간이 있어야 데이터가 막힘없이 흐를 수 있습니다.
✅ 핵심 정리
→ 버스 Utilization은 단순 처리량이 아닌 시스템 안정성의 바로미터입니다.
→ 대기행렬 이론에 의해 점유율 70% 이상에서 Latency가 기하급수적으로 증가합니다.
→ 점유율 초과 시 Arbitration 오버헤드, Burst 파괴, Priority Inversion, Buffer Overflow 등이 연쇄적으로 발생합니다.
→ 성능 평가의 핵심은 최대 대역폭이 아닌 점유율 상승에 따른 Latency Curve의 기울기를 파악하는 것입니다.
→ 올바른 Safe Zone 설정과 QoS, 캐시 최적화, 버스 분리 등의 기법으로 점유율을 관리하는 것이 진정한 시스템 최적화입니다.
📄 Raw Data
### 버스 Utilization(점유율)의 비밀: 왜 100%를 목표로 하지 않는가?
컴퓨터 구조나 SoC(System-on-Chip) 설계에서 버스(Bus)의 성능을 평가할 때, 가장 먼저 눈에 들어오는 지표는 '대역폭(Bandwidth)'입니다. 하지만 실제 설계 현장에서는 단순히 "이 버스는 10GB/s를 처리할 수 있다"는 사실보다 **"현재 Utilization(점유율)이 몇 %인가?"**를 훨씬 더 중요하게 따집니다. 특히 성능 평가를 할 때 점유율이 일정 수준(예: 50%)을 넘지 않도록 가이드라인을 잡고 테스트를 진행하곤 합니다.
왜 대역폭이 남아있는데도 점유율을 낮게 유지해야 할까요? 그리고 점유율이 한계치를 넘어가면 시스템에는 어떤 일이 벌어지는지 기술적인 관점에서 정리해 보겠습니다.
---
### 1. Utilization(점유율)의 정의와 의미
버스 Utilization은 전체 가동 시간 중 **실제로 데이터가 전송되고 있는 시간의 비율**을 의미합니다. 수학적으로는 `(실제 처리량 / 이론적 최대 대역폭) × 100`으로 계산됩니다.
* **Utilization 10%:** 버스가 아주 한가한 상태입니다. 요청이 오면 즉시 처리됩니다.
* **Utilization 90%:** 버스가 쉴 새 없이 몰아치고 있습니다. 새로운 데이터 요청이 들어오면 앞선 작업이 끝날 때까지 한참을 기다려야 합니다.
여기서 핵심은 버스는 **'공유 자원'**이라는 점입니다. 여러 개의 마스터(CPU, GPU, DMA 등)가 하나의 버스를 나누어 쓰기 때문에, 점유율이 높다는 것은 그만큼 자원을 차지하려는 경쟁(Contention)이 치열하다는 뜻입니다.
### 2. 왜 100%를 쓰지 못할까? (대기행렬 이론의 경고)
성능 평가 시 점유율을 40~60% 수준으로 제한하는 가장 큰 이유는 **대기 시간(Latency)의 급격한 증가** 때문입니다. 이는 통계학의 '대기행렬 이론(Queuing Theory)'으로 설명됩니다.
시스템 내의 지연 시간은 점유율($\rho$)에 대해 다음과 같은 비례 관계를 갖습니다.
$$Latency \propto \frac{1}{1 - \rho}$$
이 공식에 따르면 점유율이 0%에서 50%로 올라갈 때는 지연 시간이 완만하게 증가하지만, **70~80%를 기점으로 지연 시간은 기하급수적(Exponential)으로 치솟습니다.** 점유율이 100%에 도달하면 이론적으로 대기 시간은 무한대가 됩니다. 즉, 버스가 꽉 차 버리면 데이터 전송 효율은 오히려 떨어지고 시스템 전체가 먹통이 되는 현상이 발생합니다.
### 3. Utilization이 임계치를 넘으면 발생하는 문제들
만약 설계자가 욕심을 내어 버스 점유율을 너무 높게 잡으면 다음과 같은 기술적 재앙이 발생합니다.
**① 중재(Arbitration) 오버헤드 증가**
버스를 쓰려는 마스터가 많아지면 누가 먼저 쓸지 결정하는 'Arbiter'의 고민이 깊어집니다. 복잡한 우선순위 알고리즘이 돌아가면서 데이터 전송 그 자체보다 "순서 정하기"에 더 많은 시간이 소모됩니다.
**② 데이터 버스트(Burst)의 파괴**
효율적인 전송을 위해 데이터를 묶어서 보내는 'Burst 전송'이 끊기게 됩니다. 점유율이 높으면 다른 마스터가 중간에 끼어들기(Preemption) 때문에 연속적인 데이터 흐름이 방해받고, 이는 프로토콜 오버헤드를 가중시켜 실질적인 유효 대역폭(Effective Bandwidth)을 갉아먹습니다.
**③ 우선순위 역전(Priority Inversion)과 지터(Jitter)**
실시간성이 중요한 작업(예: 오디오, 비디오 스트리밍)은 정해진 시간 안에 데이터가 도착해야 합니다. 하지만 점유율이 높으면 우선순위가 낮은 작업에 밀려 중요한 데이터가 제때 도착하지 못하는 '지터' 현상이 발생하여 화면이 끊기거나 시스템이 멈추는 원인이 됩니다.
**④ 버퍼 오버플로우(Buffer Overflow)**
버스가 데이터를 빨리 받아주지 못하면 데이터를 보내려는 마스터 내부의 버퍼(FIFO)가 가득 차게 됩니다. 결국 데이터 손실이 발생하거나 마스터 자체가 동작을 멈추는(Stall) 상황이 벌어집니다.
### 4. 실무적인 가이드라인: "Safe Zone"은 어디인가?
일반적으로 고성능 SoC 설계에서 권장하는 버스 점유율 타겟은 다음과 같습니다.
* **실시간 시스템 (RTOS, Automotive):** 30~40% 미만 유지. (안전성을 위해 매우 보수적으로 잡음)
* **일반적인 SoC (Mobile, PC):** 50~60% 수준. (성능과 비용의 타협점)
* **벌크 데이터 전송 (Storage, Memory Copy):** 70~80%까지 허용하기도 하지만, 이 경우 Latency 희생을 감수함.
성능 평가를 할 때 **"Utilization 50%에서 Latency가 일정하게 유지되는가?"**를 보는 이유는, 시스템에 갑작스러운 트래픽 부하(Traffic Spike)가 걸려도 대응할 수 있는 '여유(Headroom)'가 있는지를 확인하기 위함입니다.
### 요약 및 결론
버스 Utilization을 제한하는 것은 도로에 차를 100% 꽉 채우지 않는 것과 같습니다. 도로에 차가 100% 차 있으면 아무도 움직이지 못하는 '교통 체증'이 발생하듯, 버스도 적절한 빈 공간이 있어야 데이터가 막힘없이 흐를 수 있습니다.
성능 평가 시 대역폭 숫자만 볼 것이 아니라, **점유율 상승에 따른 Latency Curve가 얼마나 완만한지**를 파악하는 것이 진정한 시스템 최적화의 핵심입니다.
---
## References
- [AMBA AXI Protocol Specification](https://developer.arm.com/documentation/ihi0022/latest/)
- [Performance Analysis of On-Chip Bus Architecture](https://www.sciencedirect.com/topics/engineering/bus-utilization)
댓글
댓글 쓰기