---
title: "미리 받은 스위치 통과권을 언제 버려야 할까"
author: "브레이브브라우저쓰자"
published_at: "2026-10-29T06:50:04.559Z"
updated_at: "2026-10-06T03:11:12.999Z"
tags: ["speculative router"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EB%AF%B8%EB%A6%AC-%EB%B0%9B%EC%9D%80-%EC%8A%A4%EC%9C%84%EC%B9%98-%ED%86%B5%EA%B3%BC%EA%B6%8C%EC%9D%84-%EC%96%B8%EC%A0%9C-%EB%B2%84%EB%A0%A4%EC%95%BC-%ED%95%A0%EA%B9%8C"
ai_assisted: true
---

# 미리 받은 스위치 통과권을 언제 버려야 할까

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EB%AF%B8%EB%A6%AC-%EB%B0%9B%EC%9D%80-%EC%8A%A4%EC%9C%84%EC%B9%98-%ED%86%B5%EA%B3%BC%EA%B6%8C%EC%9D%84-%EC%96%B8%EC%A0%9C-%EB%B2%84%EB%A0%A4%EC%95%BC-%ED%95%A0%EA%B9%8C)

새 패킷이 라우터에 도착하면 다음 대기열을 먼저 얻고 스위치 통과권을 신청할 수 있다. 두 일을 순서대로 하면 이해하기 쉽지만 한 단계의 기다림이 추가된다. speculative router는 대기열 할당이 성공할 것으로 가정하고 스위치 신청을 겹친다. 이때 절약하는 시간은 실패한 가정을 데이터 이동으로 확정하지 않을 때만 의미가 있다.

## 먼저 얻어야 하는 것과 미리 신청하는 것

패킷의 head에는 다음 출력 VC를 배정하는 단계가 필요하다. VC는 패킷의 대기열과 경로 상태를 유지하는 자원이다. 스위치 할당은 그 cycle에 어떤 입력 flit을 어떤 물리 출력으로 보낼지 정한다. 이름은 비슷해도 얻는 자원과 유지 시간이 다르다.

순차 설계에서는 출력 VC를 얻은 다음에만 스위치 요청을 만든다. 추측 설계에서는 VC를 얻는 중인 head도 스위치 후보로 낸다. 이미 VC를 가지고 준비된 flit의 요청은 추측이 아니므로, 새 head의 불확실한 요청이 이를 밀어내지 않도록 중재한다.

Mullins 등의 원문은 두 할당을 병렬로 진행하고, 기존 요청을 우선하며, 실제 전송 전에 VC 할당과 수신 공간을 확인하는 구조를 설명한다. [원문 PDF 4쪽, 2.6절](https://web.stanford.edu/group/comparch/papers/mullins04.pdf)

## 성공한 head가 한 단계를 아끼는 계산

자체 파이프라인을 정해 보자. head는 cycle 0 시작에 이미 버퍼에 있으며 출력 경로도 계산돼 있다. VC 할당과 스위치 할당은 각각 한 cycle, 실제 crossbar 통과는 다음 한 cycle을 쓴다. cycle 종료에 얻은 결과는 다음 cycle부터 사용한다.

순차 방식은 cycle 0에 VC를, cycle 1에 스위치를 할당한다. cycle 2에 crossbar를 지나고 그 종료에 출력으로 보낸다. 추측 방식은 cycle 0에 두 할당을 동시에 하고, 둘 다 성공하면 cycle 1에 통과한다. 이 예에서는 head의 출력이 한 cycle 앞당겨진다.

새 패킷마다 이 이득이 생긴다고 모든 body flit의 처리율이 두 배가 되지는 않는다. body는 이미 할당된 VC를 사용하며 물리 출력은 여전히 한 cycle에 정해진 수의 flit만 보낸다. 시작 지연을 줄인 것과 지속 전송 용량을 늘린 것을 구별한다.

## 서로 다른 head를 선택하면 무엇을 취소할까

이번에는 A와 B의 head가 같은 출력에 남아 있는 VC 하나를 요구한다고 하자. cycle 0의 VC 할당기는 A를 선택했는데, 독립적으로 진행한 추측 스위치 할당기는 B를 선택했다고 정한다. 출력 자체는 비어 있고 수신 슬롯도 하나 있지만, B는 자기 VC를 얻지 못했다.

B의 스위치 승리를 그대로 전송으로 확정하면 수신기가 어느 패킷 상태에 저장해야 할지 어긋난다. 따라서 그 승리는 무효로 처리하고 B를 입력에 남긴다. A에게는 VC가 배정되었으므로 cycle 1에 일반 스위치 요청을 하고 cycle 2에 통과할 수 있다. VC 할당까지 모두 되돌려야 하는 것은 아니다. 어느 결과를 유지하는지 설계에 명시한다.

cycle 1에 즉시 통과할 flit은 없어 이 추측은 기대했던 이득을 놓쳤다. 실제 실패 원인은 두 할당기의 선택 불일치이며, 수신 credit 부족이나 기존 패킷의 스위치 승리와는 다른 경우다. 실패 횟수만 합치기보다 이유를 구별하면 어떤 후보 제한이나 중재 연동이 필요한지 알 수 있다.

## 데이터의 상태 변화는 검증 뒤에 확정한다

전송을 확정하려면 선택한 입력 flit이 아직 유효하고, 올바른 출력 VC가 배정됐고, 수신 공간이 있으며, 출력의 중재 권한이 유지되는지 확인한다. 검증 전에 입력 FIFO를 pop하거나 credit을 사용했다가 전송만 취소하면 데이터나 공간의 계수가 맞지 않는다.

검증 결과에 맞춰 pop과 전송, 점유량 갱신을 함께 확정하거나, 미리 바꾼 상태를 되돌리는 정확한 복구 기능이 필요하다. 단순한 모델에서는 확정 조건을 통과할 때만 이 상태를 갱신하면 된다. 같은 flit을 중복으로 보내지 않고 실패한 flit을 잃지 않는지 시간축에서 확인한다.

BookSim은 speculative 옵션으로 두 할당을 겹치며, 실제 구현에는 기존 요청이나 승리 때문에 추측 승리를 버리는 처리도 있다. [공식 설정](https://github.com/booksim/booksim2/blob/master/doc/manual.tex), [iq_router.cpp의 speculative grant 처리](https://github.com/booksim/booksim2/blob/master/src/routers/iq_router.cpp)

## 줄어든 cycle이 실제 시간도 줄이는지 본다

병렬 후보를 만드는 논리와 성공 검사가 길어지면 clock period가 늘 수 있다. 두 cycle에 1ns씩 걸리던 부분이 한 cycle에 2.2ns가 되면 단계 수는 줄어도 시간이 2ns에서 2.2ns로 늘어난다. 이 수치는 회로 측정이 아닌, cycle 수만 비교하는 판단의 반례다.

speculative router를 평가할 때는 성공한 head의 지연, 실패 때 남는 상태, 기존 패킷의 전송 기회와 clock period를 함께 본다. 추측의 장점은 필요한 자원을 얻는 기다림을 겹치는 데 있다. 실제로 얻지 못한 자원에 데이터를 보내지 않는 계약을 먼저 지키면, 가벼운 부하에서 기대한 지연 감소와 혼잡에서의 비용을 정확히 비교할 수 있다.