Switching performance with clock tolerances

출처: http://blog.naver.com/cisluser/10003587075

         1. 개요

스위치는 기본적으로 네트워크 패킷의 방향을 바꾸어 주는 장비다. 입력되는 패킷을 적절한 경로로 출력될 수 있도록 흐름을 바꾸어 주는 기능을 담당하는데, 인터페이스 사양이 점점 고성능으로 진화함에 따라 스위치에서 처리해 주어야 할 용량도 매우 빠른 속도로 증가하고 있다. 예를 들어 기가 비트 이더넷의 경우에 초당 1G(10억) bit stream을 처리해야 하므로 매우 빠른 속도로 데이터 처리를 해야 함을 알 수 있다.

그런데 우리가 일반적으로 스위치를 평가할 때 이야기하는 wire-speed라는 개념은 Spec에 규정된 최대한의 속도로 입력되는 packet을 100% 원하는 경로로 보낼 수 있어야 한다는 것이다. 이론상으로 가능한 이야기이고 또 실제로 테스트를 통해 검증하기도 하지만 실제 구현에서는 완벽하게 이를 보장할 수 없는 가능성이 존재하게 되는데 그 이유를 명확히 이해하고 적절히 대처할 필요가 있다. 이 문서에서는 이러한 이론과 실제의 차이점에 따른 성능 이슈에 대해서 정리를 하고 그에 따른 대처 방법에 대해서 기술한다.

   2. 고속 통신 기법

일반적으로 통신은 clock에 동기 되어 전송하는 Synchronous 기법과 그렇지 않은 Asynchronous 기법으로 나뉠 수 있다. 고속 통신을 위해서는 미리 전송 속도를 약속하고 Tx/Rx 단에서 미리 약속에 맞추어 스스로 데이터 처리를 담당하는 Synchronous 기법이 사용된다. 또한 전송 속도가 수백 Mbps 이상 되는 경우에는 clock의 길이와 실제 데이터 전송 라인의 길이가 민감하게 영향을 미치기 때문에 Tx 데이터의 clock과 Rx 데이터의 clock을 별도로 사용하는 Source Synchronous Clock 기법을 사용하게 된다. 근래에 사용되는 대부분의 고속 통신 기법은 모두 이러한 Source Synchronous Clock 기법이 사용되고 있다.

이러한 개념은 스위치 장비에서 사용되는 통신 인터페이스에서도 마찬가지로 적용되어서 스위치와 PHY 사이의 인터페이스인 GMII(Gigabit Medial Independent Interface), S3MII(Source Synchronous Serial Media Independent Interface) 등을 비롯해서 많은 인터페이스가 Clock 신호가 Tx 데이터를 전송하는 디바이스에 의해서 만들어지게 된다. 이와 같은 개념을 간략하게 아래의 그림과 같이 정리해 볼 수 있다.

이 때 Device 1 이 스위치라고 가정을 해 보면, 이론적으로 Device1의 Clk 속도와 Device 2에서 제공하는 Rx Clk 속도가 100% 완벽하게 일치해야 하고 그렇지 않을 경우에 어느 한 쪽에서 데이터가 계속해서 쌓이게 되는 결과가 나올 수 있음을 예측해 볼 수 있다. 이러한 문제점이 근본적으로 존재하는 것이다.

3. 이더넷 표준과 Clock Tolerance

     3.1 이더넷 표준

2장에서 설명한 바와 같이 이론적으로 완벽하게 wire speed로 통신이 되기 위해서는 Tx Clk과 Rx Clk의 속도가 언제나 완벽하게 일치해야 한다는 문제점이 있다. 그러나 실제로는 이렇게 구현될 수 없기 때문에 이더넷 표준 자체에서도 이러한 Clk의 차이에 대한 tolerance를 규정하고 있다. Gigabit Ethernet을 그 예로 들어보도록 하자.

GMII 표준을 규정하고 있는 IEEE802.3(:2000) 의 35.4.2.3 절의 Table 35-8 AC Specification을 살펴 보면, GMII에 사용되는 Tx Clk의 tolerance를 -/+100ppm으로 규정하고 있다.

따라서, 이 규정을 준수하는 경우 허용 가능한 Frame Rate을 계산해 보면 다음과 같다.

Frame Rate 이론 치(64 Byte 기준)

 = Transmit_Data_Rate/ {Frame_Length * 8 + Minimum_Gap + Preamble + SFD}

 = 1,000,000,000/ {64 * 8 + 96 + 56 + 8} = 1,000,000,000 / 672

 = 1,488,095.2 fps (frame per second)

즉 이론적인 frame은 위와 같이 계산이 되지만 -/+ 100 ppm을 가정하면 표준에 근거한 허용 가능한 스위칭 performance는 다음과 같다.

1,487,946.4 fps(-100 ppm 기준) < 허용 범위 < 1,488,244 fps(+100 ppm 기준)

즉, 스위치의 성능은 위에서 제시한 기준인 허용 범위에 든다면 원칙적인 문제가 없는 것이고 따라서 Rx 속도는 -100 ppm 기준 정도의 packet을 처리할 수 있으면 되고, Tx 속도는 +100 ppm까지 보낸다 하더라도 문제가 되지는 않는다.

   3.2 Clock Tolerance 와 이에 따른 문제점

위에서 설명한 바와 같이 실제로 사용하는 Clock의 tolerance에 따라서 2개의 device 사이에 전송 속도가 틀릴 수 있고 이로 인해 어느 한 쪽에서 packet loss가 발생할 확률이 생기게 된다. 하지만 실제 네트워크 환경에서는 이와 같이 계속해서 wire speed로 packet을 전송해야 하는 확률은 매우 낮으며 따라서 BMT 등 테스트 시에 장기간 wire speed로 테스트를 하게 될 경우(Smart Application 같은 프로그램으로 테스트 시)에 이와 같은 문제가 발생할 가능성이 있다.

이러한 문제점을 해결하기 위해서 보통 스위치 구현 시 칩의 내부나 외부에 적절한 용량의 packet buffer를 내장하게 되는데 그 용량에 한계가 있기 때문에 테스트 시간에 따라서 packet loss가 발생하는 경우를 접할 수 있게 된다. 또한 장비에 사용되는 clock마다 조금씩 tolerance가 다르기 때문에 이러한 증상도 장비에 따라서 조금씩 다르게 결과가 나오는 것이다.

일반적으로 스위치 구현 시 사용하는 Clock은 단가 등을 고려하여 100 ppm짜리를 주로 사용하는데 Smartbit을 보면 훨씬 정밀한 사양인 30 ppm을 사용하는 것을 확인하게 되었고, 실제 확인되지는 않았지만 IXIA의 packet 전송 속도를 보면 훨씬 더 정밀하게 control 됨을 추정할 수 있다.

따라서 이와 같은 테스트 장비를 써서 시험을 할 경우에 오랜 시간 wire speed로 스위칭 하는 것을 테스트하다 보면 시간에 따라서 packet이 내부 buffer에 머무르다가 drop되는 증상을 관찰할 수 있는데, 이는 이와 같은 원인에서 기인하는 것도 있음을 알고 적절하게 문제의 원인을 판단해야 할 것이다. 이와 같은 원인에서 기인해서 packet이 drop되는 경우에는 내부 buffer의 count가 톱니 파 (Saw-tooth wave) 형태로 증가하고 감소하는 것을 확인할 수 있을 것이다.

이로 인해 생길 수 있는 문제점은 다음과 같이 우리 장비에서 사용하는 Tx Clk의 정밀도보다 높은 정밀도를 사용하는 다른 장비와 연결해서 장시간 wire speed로 테스트를 진행할 경우에 뜻하지 않게 packet 이 drop되거나 flow control이 발생(PAUSE)하는 경우가 생기게 된다. 일반적으로 테스트를 실시하는 환경을 아래의 그림과 같이 도시할 수 있다.