다수의 interconnection network 응용은 높은 신뢰성과 가용성을 요구한다. 대형 병렬 컴퓨터는 interconnection network가 수천 시간 동안 packet 손실 없이 동작해야 한다. Internet router는 소량의 packet 손실은 허용될 수 있지만, router 자체는 연간 5분의 다운타임만 허용되는 99.999%의 가용성을 유지해야 한다. I/O system 역시 유사한 가용성 요건을 가진다.
Interconnection network는 일반적으로 수백 개(또는 수천 개)의 구성 요소—router, channel, connector—로 구성되며, 이들은 전체적으로 봤을 때 응용이 요구하는 것보다 높은 고장률을 가진다. 따라서 이러한 network는 오류 제어(error control)를 사용하여 구성 요소의 일시적 또는 영구적인 고장에도 불구하고 운영을 중단하거나 packet을 손실하지 않고 계속 동작할 수 있어야 한다.
21.1 적을 알라: 고장 방식과 fault 모델
오류를 다루는 첫 번째 단계는 구성 요소 고장의 본질을 이해하고, 이를 통해 고장을 분석하고 처리 방법을 논의할 수 있도록 단순한 모델을 개발하는 것이다. 시스템에서 발생할 수 있는 고장을 고장 방식(failure mode)이라 부른다. 고장 방식은 오류의 물리적인 원인을 의미한다. channel의 Gaussian noise, connector의 부식, 냉땜(cold solder joint) 불량, power supply 출력 드라이버의 open, 알파 입자(alpha-particle) 충돌, chip 내 도체의 전자이동(electromigration), 소자의 문턱 전압(threshold voltage) 변화, 잘못된 모듈 제거, 소프트웨어 오류 등이 그 예다.
이러한 고장 방식은 대개 복잡하고 난해하기 때문에, 우리는 해당 고장 방식의 관련 동작만을 묘사하고 대부분의 불필요한 복잡성을 숨기는 간단한 fault model을 개발한다. 표 21.1은 interconnection network에서 흔히 발생하는 고장 방식의 일부를 보여준다. 또한 각 고장 방식의 일반적인 고장률 값도 함께 제시한다. Gaussian noise나 alpha-particle 충돌과 같은 일부 고장은 일시적(transient) 오류를 유발하며, 이는 한두 개의 비트에 오류를 발생시키지만 시스템 동작에는 영구적인 영향을 주지 않는다. 반면 connector 고장이나 도선의 electromigration 등은 모듈의 영구적인 고장을 일으킨다.
일시적 고장은 일반적으로 bit-error rate (BER) 또는 soft-error rate (SER)로 모델링한다. 이러한 수치는 단위 시간당 오류 발생률(s⁻¹)을 가지며, 이 값의 역수는 오류 사이의 시간 간격을 의미한다. 한편, 영구적 고장은 stuck-at fault 모델로 모델링되며, 이는 어떤 논리 노드가 logic 1 또는 0에 고정되었다고 가정한다. 다른 영구 고장은 fail-stop fault로 모델링되며, 이는 구성 요소(예: link 또는 router)가 동작을 멈추고 인접한 모듈에 자신이 서비스를 중단했음을 알리는 것이다. 이러한 고장은 평균 고장 간격(mean-time between failures, MTBF)으로 표현되며, 시간 단위(보통 시간 또는 failures in 10⁹ hours, 즉 FITs)로 나타낸다. 설계 시 stuck-at fault나 지나치게 잦은 일시적 고장을 fail-stop fault로 전환하는 방식도 고려된다. 예를 들어, channel은 자체 동작을 모니터링하다가 오류를 감지하면 스스로 fail-stop 상태로 전환할 수 있다.
표 21.1 일반적인 interconnection network의 고장 방식과 fault 모델
channel의 Gaussian noise | Transient bit error | 10⁻²⁰ | BER (errors/bit) |
memory에서의 alpha-particle 충돌 | Soft error | 10⁻⁹ | SER (s⁻¹ per chip) |
logic에서의 alpha-particle 충돌 | Transient bit error | 10⁻¹⁰ | BER (s⁻¹ per chip) |
도선의 electromigration | Stuck-at fault | 1 | MTBF (FITs) |
소자(threshold)의 전압 변화 | Stuck-at fault | 1 | MTBF (FITs) |
connector의 부식 | Stuck-at fault | 10 | MTBF (FITs) |
냉땜(cold solder joint) | Stuck-at fault | 10 | MTBF (FITs) |
전원 공급 장치 고장 | Fail-stop | 10⁴ | MTBF (FITs) |
정상 모듈을 사용자가 제거 | Fail-stop | 10⁵ | MTBF (FITs) |
소프트웨어 고장 | Fail-stop or Byzantine | 10⁴ | MTBF (FITs) |
처음 표 21.1에 나온 오류율을 보면 매우 작아 보이지만, 대형 시스템에서는 이 수치들이 누적되어 상당한 수준이 된다. 예를 들어, 1,024개의 노드를 가진 3차원 torus 네트워크에서 10 Gbits/s의 channel을 사용하고, 각 channel의 BER이 10⁻¹⁵인 경우를 보자. 처음엔 10⁻¹⁵이라는 수치가 매우 작게 느껴지지만, channel 속도인 10¹⁰ bits/s와 곱하면 channel 당 오류율이 10⁻⁵ errors/s가 된다. 이 시스템에는 총 6,144개의 channel이 있으므로 전체 오류율은 6 × 10⁻² errors/s, 즉 16초마다 한 번의 오류가 발생한다. BER이 10⁻²⁰으로 더 낮은 경우라도 전체 오류율은 6×10⁻⁷로, 한 달에 약 2건의 오류가 발생한다. 이러한 오류의 영향을 잘 제어하면, 이러한 link로도 매우 신뢰성 높은 시스템을 구축할 수 있다.
일부 고장은 Byzantine 형태인데, 이는 시스템이 작동을 멈추는 대신 악의적인 방식으로 동작을 계속하면서 protocol을 위반하여 인접 모듈을 고장나게 하려는 동작이다. Byzantine 고장은 처리하기 매우 어렵고, 실제로는 드물다. 이를 방지하기 위해 시스템을 스스로 점검하는 기능을 갖추고, 문제가 있는 모듈이 이상 동작을 하기 전에 셧다운되도록 설계한다. 소프트웨어 고장도 때때로 Byzantine 동작을 보일 수 있지만, 이 또한 하드웨어 고장처럼 실행을 감시하고 불변 조건을 위반할 경우 중단시킴으로써 처리할 수 있다.
전원공급 장치, 냉각 팬, 클럭 생성기 등의 구성 요소 고장은 여분(redundancy)과 현장 교체(field replacement)를 통해 처리한다. 전원공급 장치는 여유 전원을 확보하여 하나가 고장나도 나머지로 동작을 유지할 수 있도록 하고, 고장 여부는 모니터링 하드웨어로 쉽게 감지되어 교체할 수 있도록 한다. 냉각 팬도 N + 1 방식의 redundancy를 사용한다. 전역 클럭이 필요한 시스템에서는 여러 개의 클럭을 분산 배치하고, 클럭 고장이 감지되면 각 모듈이 스스로 다른 클럭으로 전환하여 PLL을 통해 안정적인 클럭을 제공한다. 이후 이 장에서는 전원, 냉각, 클럭 등 인프라는 좋은 엔지니어링 관행으로 잘 처리되었다고 가정하고, link와 router의 고장에 집중한다.
표 21.1에 제시된 고장률은 구성 요소의 수명 대부분 동안의 평균적인 고장률이다. 많은 구성 요소는 초기와 말기에 훨씬 높은 고장률을 보이며, 이는 그림 21.1의 배스타브 곡선(bathtub curve)에 나타나 있다. 초기에는 일부 불량한 부품이 몇 시간 이내에 고장나는데, 이를 infant mortality라 한다. 몇 백 시간 동안 정상적으로 동작한 부품은 그 이후부터는 비교적 일정한 고장률을 보이다가 수명이 다할 무렵 다시 고장률이 높아진다. infant mortality를 제거하기 위해 burn-in 과정을 거쳐 부품을 일정 시간(그리고 스트레스 환경 하에서) 동작시켜 불량 부품을 걸러낸 후 시스템에 탑재한다. wearout을 방지하기 위해 수명이 짧은 부품은 일정 시간이 지나기 전에 교체한다. 예를 들어, router chip은 시스템에 탑재하기 전에 고온, 고전압, 고속 환경에서 100시간 burn-in을 실시하며, 10년 수명을 가진 디스크 드라이브는 5년 후에 교체한다.
이후부터는 21.2절 "오류 제어 과정"과 21.3절 "Link 수준의 오류 제어"에 대한 내용입니다:
21.2 오류 제어 과정: 검출, 격리, 복구
모든 오류 제어는 다음 세 가지 기본 단계로 구성된다: 검출(detection), 격리(containment), 복구(recovery).
문제를 해결하기 위해 가장 먼저 해야 할 일은 문제가 존재함을 인식하는 것이다. interconnection network에서는 이것이 오류 검출 단계에 해당한다. 예를 들어, flit의 패리티(parity)나 check character를 확인함으로써 channel에서의 bit 오류를 감지할 수 있다. 오류나 고장을 검출한 이후에는 오류가 퍼지지 않도록 격리해야 한다. 예를 들어, 오류가 flit 내 virtual channel identifier를 손상시켰다면, 잘못된 virtual channel의 상태가 업데이트되는 것을 막아야 한다. 마지막으로, 오류 제어의 세 번째 단계는 오류로부터 복구하고 정상 동작을 재개하는 것이다. 예를 들어, bit 오류가 발생했다면 flit을 다시 전송하여 복구할 수 있다. 이 재전송은 link 수준이나 원래 송신자로부터 수행될 수 있다.
21.3 Link 수준의 오류 제어
대부분의 interconnection network는 오류 제어를 계층적으로 수행한다. 물리적인 link 수준에서 시작하여 router, network, system 또는 end-to-end 수준까지 이어진다. link 수준에서는 link 논리가 link 오류를 가려서 처리하거나(지연이 추가될 수 있음), 마스킹할 수 없는 경우 link를 종료(fail-stop)시켜 오류를 제어한다. link의 양 끝에 위치한 논리 모듈은 협력하여 link 상의 bit 오류를 검출, 격리, 복구한다. 치명적인 오류가 발생하면 link 논리는 해당 오류를 우회하도록 link를 재구성하거나 link를 종료시킨다.
21.3.1 Link 모니터링
link 수준에서의 오류 검출은 ECC(error control code)를 사용하여 link에 중복 정보를 추가하는 방식으로 수행된다. 단순한 parity로는 단일 bit 오류를 검출할 수 있지만, 대부분의 link는 CRC(cyclic-redundancy check)를 사용하며, 이때 CRC의 길이가 충분하면 다중 bit 오류가 검출되지 않을 확률은 극히 낮다. n-bit CRC는 n개 미만의 비트를 포함하는 오류는 모두 검출하고, 2ⁿ분의 1 확률로 나머지 오류를 검출하지 못할 수 있다.
오류 검출은 flit, packet, multipacket frame 등 다양한 크기로 수행될 수 있다. frame처럼 큰 단위로 검사하면 효율적이지만, 오류가 발생한 사실을 frame 전체를 받은 후에야 알 수 있어 격리에 불리하다. frame-level CRC가 오류를 검출할 때쯤이면, 이미 해당 오류는 여러 channel을 지나며 router들의 내부 상태를 손상시켰을 수 있다. 이를 방지하기 위해 많은 router들은 flit마다 검사하고, 특히 중요한 header 정보는 flit 전체를 받기 전에 별도로 보호하여 즉시 처리할 수 있도록 한다.
link 모니터링의 예로, 그림 21.2는 link 상의 bit 오류를 검사하기 위해 두 개의 CRC 필드를 포함한 flit 포맷을 보여준다. CRC1은 virtual-channel ID, flit type, credit 등 첫 cycle에서 수신되는 header 필드를 검사한다. CRC2는 flit 전체에 대한 CRC로, CRC1을 포함하여 검사한다. header에 대해 별도의 CRC를 제공하면, flit 전체가 도착하기 전이라도 해당 정보를 안전하게 사용할 수 있다. CRC1 필드에 문제가 없었더라도 CRC2에서 오류가 검출될 수 있기 때문에, 결과적으로 header 필드도 CRC2에 의해 더 강한 오류 검출 보호를 받게 된다.
link 모니터링은 연속적으로 수행되어야 한다. idle 상태인 channel을 검사하지 않으면 오류가 오랫동안 잠복하다가 다음 flit이 도착했을 때 드러날 수 있다. link가 idle인 경우에는 임의의 데이터를 담은 idle flit을 전송하여 link를 지속적으로 테스트해야 한다. 또는 flit 기반 검사 외에 frame 기반 검사 방식도 병행할 수 있다.
21.3.2 Link 수준의 재전송
오류가 검출되면 link 논리는 다음 단계인 격리를 수행해야 한다. 대부분의 link 오류는 router 논리에 노출되지 않도록 오류를 마스킹함으로써 격리된다. 마스킹은 오류를 격리하고 복구하는 두 가지 작업을 동시에 수행한다. 오류가 있는 flit을 재전송하는 것이 가장 단순한 마스킹 방법이다. 마스킹은 FEC(forward error-correcting) code를 사용하는 방법으로도 수행할 수 있다. FEC를 사용하면 보호 단위(보통 flit)에 충분한 정보를 담아 오류를 감지할 뿐만 아니라 수정도 할 수 있다. 하지만 round-trip latency가 짧은 interconnection network에서는 재전송 방식이 더 단순하고, 적은 오버헤드로 더 많은 오류를 수정할 수 있어 일반적으로 선호된다.
그림 21.3은 간단한 재전송 시스템을, 그림 21.4는 그 타이밍을 보여준다. 송신기는 flit을 전송할 때마다 transmit flit buffer에 사본을 저장하고, 수신 확인(ACK)이 올 때까지 유지한다. 일반적으로 switch output speedup을 위해 output buffer를 사용하는 구현에서는, transmit flit buffer는 output buffer와 결합되어 사용된다.
송신기가 각 flit을 전송할 때마다, 해당 flit은 작은 transmit flit buffer에 저장된다. 오류가 감지되면 이 buffer에서 해당 flit을 다시 전송하여 오류를 마스킹한다. 각 flit에는 식별을 위해 일반적으로 transmit flit buffer 내 주소와 같은 태그가 붙는다. 수신기는 수신된 각 flit에 대해 오류를 검사하며, flit이 올바르게 수신되었을 경우 acknowledgment를 송신기에게 전송한다. 이 acknowledgment에는 어떤 flit에 대한 응답인지 나타내는 태그와 함께 수신 상태(정상 수신, 오류 수신, 무시됨)가 포함된다. acknowledgment를 받은 송신기는 해당 flit의 사본을 삭제한다. 오류가 발생한 경우 송신기는 멀티플렉서를 전환하여 해당 flit을 재전송한다. 대부분의 경우 오류는 일시적이므로, 재전송된 flit은 올바르게 수신된다.
물론 acknowledgment 자체도 오류 검사가 필요하며, 오류가 있을 경우 재전송되어야 한다. 이는 일반적으로 반대 방향으로 이동하는 flit에 acknowledgment를 piggyback하는 방식으로 처리되며, flit의 일부라도 오류가 있으면 전체 flit을 재전송한다.
실제로는 오류가 발생한 하나의 flit만 재전송하면 되지만, 이는 channel 상의 flit 순서를 어지럽혀 router의 입력 논리를 복잡하게 만든다. 예를 들어 body flit이 head flit보다 먼저 수신될 수 있다. 이러한 복잡성을 피하기 위해, 오류가 발생한 지점부터 buffer에 있는 모든 flit을 다시 전송하는 방식이 더 간단하다. 이때 새로운 flit이 도착하면 flit buffer의 끝에 추가된다. 송신 포인터가 buffer의 끝에 도달하면, 멀티플렉서를 전환하여 switch에서 직접 flit을 전송하게 된다.
그림 21.4의 타이밍 다이어그램은 이러한 재전송의 예를 보여준다. 송신기는 flit을 보낼 때마다 수신기로부터 acknowledgment 또는 오류 알림을 받는다. flit 2가 전송 중 손상된다. 수신기는 flit 2의 CRC를 검사하여 오류를 감지하고, 송신기에게 오류를 알린다. 송신기는 오류 알림을 받기 전까지 flit 3~6을 계속 전송하며, 수신기는 이 flit들을 무시한다. 이후 송신기가 오류를 인지하면 전송을 flit 2부터 되돌리고, 그 이후 모든 flit을 다시 전송한다. 수신기는 재전송된 flit 2를 받은 시점부터 다시 정상 동작을 시작한다. 수신기의 관점에서는 단지 flit 5개만큼 지연되었을 뿐이며, 오류는 마스킹된다.
transmit flit buffer는 세 개의 포인터로 관리된다. 오류가 없을 경우 transmit 포인터와 tail 포인터는 FIFO transmit queue에서 head와 tail 포인터처럼 동작한다. 새로운 flit은 tail 포인터 위치에 추가되고, transmit 포인터 위치부터 flit이 전송된다. router가 switch로부터 직접 전송 중일 경우 transmit 포인터와 tail 포인터는 동일 위치를 가리킨다. 하지만 FIFO와 달리, flit이 전송되었다고 해서 해당 위치를 즉시 재사용할 수는 없다. 해당 flit이 acknowledgment를 받을 때까지 buffer에 유지되어야 한다. acknowledgment 포인터는 아직 acknowledgment를 받지 않은 가장 오래된 flit을 나타낸다. acknowledgment를 수신할 때마다 acknowledgment 포인터가 전진하며, buffer 한 칸이 해제된다. 오류 알림을 받으면 transmit 포인터는 acknowledgment 포인터 위치로 되돌아간다.
21.3.3 Channel 재구성, 성능 저하, 종료
격리(containment) 과정의 한 측면은 문제가 있는 구성 요소가 계속해서 트래픽에 영향을 미치지 않도록 차단하는 것이다. channel에서 오류가 반복되거나, 예상보다 높은 BER을 보일 경우 channel의 일부가 치명적인 고장을 겪었을 가능성이 높다. 이러한 지속적인 오류를 감지하기 위해 각 channel에는 오류 카운터가 존재하며, 해당 channel의 오류율을 추적한다. 오류율이 임계값을 넘으면 해당 channel은 고장으로 판단되어 서비스에서 제외된다. 예를 들어, 기대하는 오류율이 초당 10⁻⁵ errors (하루에 약 1건)인 channel에서 10⁴초(약 3시간) 동안 10건 이상의 오류가 기록되면 해당 channel은 고장으로 간주되어 종료된다. 이러한 BER 모니터링 및 고장 판단은 일반적으로 network 구성 요소 상태를 주기적으로 점검하는 supervisor 소프트웨어에 의해 수행된다.
일부 멀티비트 channel은 예비 신호선(spare bit)을 포함하여 하나의 비트에 문제가 생겼을 때 channel을 재구성할 수 있다. 이러한 channel에서 치명적인 오류가 감지되면, 진단 절차를 통해 어느 비트가 고장났는지 파악한 후 해당 비트를 우회하여 channel을 재구성할 수 있다.
그림 21.6은 예비 비트 1개를 포함한 8비트 channel의 예이다. 송신기와 수신기에 위치한 2:1 멀티플렉서 8쌍을 통해 d0d7의 데이터를 9개의 신호선 s0s8 중 동작 가능한 8개에 실어 보낼 수 있다. 예를 들어 s3에 문제가 생기면, 송신기는 d3d7을 왼쪽으로 한 칸씩 밀어 s4s8을 통해 전송하고, 수신기에서 이를 다시 되돌린다.
일부 channel은 예비 비트를 제공하지 않지만, channel의 정상적인 신호선을 사용하는 방식으로 전송 속도를 낮춰 재구성할 수 있다. 예를 들어 8비트 channel의 신호선 중 1개가 고장나면 나머지 7개 신호선을 사용하여 원래 속도의 7/8로 계속 전송할 수 있다. 이러한 재구성은 graceful degradation의 예이며, 첫 번째 비트가 고장났다고 해서 channel 전체를 정지시키지 않고, 대역폭만 점진적으로 줄여나간다. 심지어 hard bit 오류 발생 시 link가 fail-stop 방식으로 동작하더라도, network 수준에서 graceful degradation을 적용할 수 있다.
channel이 재구성될 수 없는 경우에는 해당 channel을 종료시켜 오류를 fail-stop으로 축소하며, 오류 제어는 다음 계층인 network 수준에서 수행된다. 종료 당시 transmit flit buffer에 있는 flit들은 입력 컨트롤러로 반환되어 다른 경로로 재전송되거나 폐기된다.
패킷이 고장 난 channel을 경유하던 중 분리(split)될 경우 문제가 발생한다. head flit은 여러 hop 아래쪽에 있고, tail flit은 고장 난 channel의 위쪽에 남아있을 수 있다. 고립된 tail flit은 head flit에 포함된 라우팅 정보를 참조할 수 없기 때문에 목적지를 알 수 없으며 폐기해야 한다. 더 심각한 문제는 head flit이 tail 없이 계속 전파되는 경우이다. 이 head flit은 경로상 virtual channel들을 점유하면서 목적지까지 이동한다. 이때 해당 virtual channel을 필요한 다른 패킷은 진행할 수 없게 된다. 이런 자원을 회수하기 위해서는 입력 컨트롤러는 고장 난 channel에 연결된 각 virtual channel이 아직 packet 전송 중이었다면 tail flit을 합성하여 전송한다. 고장으로 인해 분리되어 폐기된 packet은 end-to-end 오류 제어(21.6절)를 통해 복구할 수 있다.
21.4 Router 수준의 오류 제어
일부 고장 방식은 link 오류를 유발하지만, 다른 고장 방식은 router에 일시적 또는 영구적인 오류를 발생시킨다. 이러한 router 오류는 channel 상의 bit 오류보다 빈도는 낮지만, 신뢰성 높은 대규모 시스템을 구축하기 위해 반드시 제어되어야 한다. link 오류처럼 router 오류도 검출, 격리, 복구의 원칙을 따른다.
router 오류는 router 논리를 복제하고, cycle마다 대표적인 신호를 exclusive-OR 방식으로 비교하여 가장 쉽게 검출할 수 있다. 한 쪽 복제본은 master로서 주 출력 신호를 생성하고, 다른 하나는 shadow 복사본으로서 동일한 입력을 받지만 출력은 비교를 위한 용도로만 사용된다. checker는 두 복사본의 출력과 내부 신호를 비교한다. 두 모듈의 출력만 비교하는 것은 많은 오류를 제때 검출하지 못하므로 충분하지 않다. 많은 오류는 router의 내부 상태만 손상시키고, 출력에는 수천 cycle 후에야 드러나기 때문이다. 이를 단순화하기 위해 master와 shadow는 수천 개의 내부 신호 및 모듈 출력을 exclusive-OR로 압축하여 소수(예: 32개)의 compressed state line을 만든다. checker는 이 compressed line을 비교하고, 내부 신호 하나라도 다르면 오류로 감지된다.
router 내부 메모리나 버스에서 발생하는 오류는 ECC로 검출할 수 있다. 메모리와 버스에서는 주로 SECDED(Single Error Correcting, Double Error Detecting) 코드가 사용되며, n비트 메모리나 버스에는 log₂(n) + 1개의 check bit를 추가하여 보호한다. 메모리 오류를 마스킹하기 위해서는 주기적으로 메모리를 sweep하여 각 위치를 읽고 단일 bit 오류를 수정해야 한다. 오류가 발생한 직후에 이를 검출하고 수정함으로써 두 번째 오류가 발생하여 복구 불가능한 상태가 되기 전의 위험을 줄일 수 있다.
router 오류는 일관성 검사(consistency check)를 통해서도 검출된다. 예를 들어 protocol 일관성 검사에서는 head flit 사이에 적어도 하나의 tail flit이 존재해야 한다는 조건을 확인한다. credit 일관성 검사에서는 channel의 수신 측 입력 컨트롤러와 송신 측 출력 컨트롤러가 buffer 가용량에 대해 일치된 값을 갖고 있는지를 점검한다. 상태 일관성 검사에서는 현재 input controller나 virtual channel의 상태에 맞는 입력이 들어왔는지를 확인한다. 이러한 조건이 위반되면 오류로 간주되고 격리 조치가 필요하다.
오류가 검출되면 해당 router 또는 오류가 발생한 router 일부(예: input controller)를 중지시켜 격리할 수 있다. 구성 요소를 중지시키면 오류를 fail-stop으로 바꾸어 인접 router의 상태가 손상되는 것을 막는다. 이를 위해 router를 fault-containment region으로 나눈다. 보통 input controller는 각각 독립적인 fault-containment region이며, router 전체는 더 상위의 fault-containment region으로서, allocator나 공통 논리에서 오류가 검출되었을 때 router 전체가 중지된다.
오류가 일시적이면, 해당 router 또는 input controller는 상태를 초기화한 뒤 재시작할 수 있다. 이 경우 해당 구성 요소를 지나던 packet은 link 고장 시처럼 폐기된다. 재시작 중인 구성 요소는 인접 모듈들과 상태를 동기화해야 한다. 예를 들어 router가 재시작할 때는 인접 router마다 control flit을 보내 channel을 재설정하고, credit 수치를 초기화해야 한다.
영구적 오류가 발생한 경우 해당 구성 요소는 재시작할 수 없고 교체되어야 한다. 신뢰성 있는 설계를 위해 시스템이 동작 중에도 고장난 모듈을 교체할 수 있도록 하는 방식(hot swapping)을 도입한다. 대부분의 경우 router 같은 능동 구성 요소는 이런 방식으로 교체가 가능하다. 다만 교체 단위(field replaceable unit, FRU)는 보통 router 단위보다 클 수 있다. 예를 들어, 4개의 router가 하나의 PCB(card)에 실려 있다면, 하나의 router만 고장나더라도 전체 카드(4개 router)를 교체해야 한다.
field 교체의 대안으로는 시스템에 충분한 여분(router, channel 등)을 미리 포함시켜 전체 수명 동안 요구되는 성능을 확보하는 방법이 있다. 이 방법은 field servicing이 어려운 위치(예: 우주)에서 시스템이 배치될 때 유리하다.
21.5 Network 수준의 오류 제어
network 수준은 link 수준에서 시작한 오류 제어 계층에서 다음 단계이다. 이 수준에서는 link와 router 고장을 fail-stop link와 router로 모델링하며, packet은 이러한 고장난 구성 요소를 우회해야 한다. network 수준 오류 제어는 adaptive routing을 이용하면 가장 쉽게 구현된다. service에서 제외된 link는 adaptive routing 기능에서 제외되며, 모든 packet은 나머지 가용 link를 통해 전송된다.
network 수준 오류 제어는 table 기반 oblivious routing을 통해서도 실현 가능하다. 고장 직후에는 routing table을 그대로 사용하여 전송을 시도하며, 고장 link가 포함된 경로를 선택한 packet은 폐기되거나 local rerouting된다. local rerouting은 고장난 link(예: 동쪽)를 건너뛰기 위해 (북→동→남) 등의 대체 hop을 선택하는 것이다. 이후 routing table은 고장 link를 피하도록 재계산된다.
21.6 End-to-End 오류 제어
link 또는 router 고장 격리 도중에 packet이 폐기되었을 경우, end-to-end packet 재전송 방식으로 복구할 수 있다. 이 방식은 link 수준의 flit 재전송과 유사하나, packet 단위로 source부터 destination까지 전체 경로를 따라 재전송이 이루어진다는 점이 다르다.
재전송을 위해 송신 노드는 전송한 각 packet의 복사본을 유지하며, acknowledgment가 도착할 때까지 이를 보관한다. acknowledgment가 일정 시간 내에 도착하지 않거나, negative acknowledgment가 수신될 경우 재전송이 발생한다. acknowledgment가 올 때까지 이 과정은 반복되며, 성공적으로 수신되면 해당 packet 복사본은 폐기되어 transmit packet buffer의 공간이 해제된다.
이 방식에서는 destination이 동일한 packet을 두 번 수신하는 경우도 발생할 수 있다. 예를 들어, 재전송이 일어난 직후에 acknowledgment가 지연되어 도착하는 경우가 이에 해당한다. 이러한 중복 packet은 packet에 serial number를 부여하고, 각 노드가 마지막 T flit 간격 동안 수신한 일반 packet과 재전송 packet 리스트를 유지함으로써 탐지 및 폐기할 수 있다. 재전송 packet은 header의 특정 비트로 식별되며, 그 serial number가 일반 리스트에 있으면 중복으로 간주된다. 일반 packet은 재전송 리스트와 비교한다. 일반 리스트 확인은 비용이 크므로 드물게 수행되고, 재전송 리스트 비교는 대부분 1~2개 이내이므로 비용이 적다.
이처럼 end-to-end packet 재전송이 network, router, link 수준 오류 제어 위에 계층적으로 쌓이면 interconnection network는 임의의 수준까지 신뢰성을 높일 수 있다. 물론 interconnection network의 client (예: processing node, network line card, I/O device) 역시 고장의 대상이 되지만, 이러한 장치에도 동일한 신뢰성 설계 원칙을 적용할 수 있다. 예를 들어 서로 다른 terminal에 연결된 중복 client를 통해 전체 시스템 신뢰성을 확보할 수 있다.
'System-on-Chip Design > NoC' 카테고리의 다른 글
Performance Analysis (2) | 2025.06.16 |
---|---|
Buses (0) | 2025.06.16 |
Network Interfaces (0) | 2025.06.16 |
Allocation (1) | 2025.06.16 |
Arbitration (1) | 2025.06.16 |