CAS 숫자만 비교해서 DRAM 첫 바이트 시간을 판단하면 틀리는 경우

메모리 A는 CL16, B는 CL22다. 숫자만 보면 A가 훨씬 빨리 첫 데이터를 내보낼 것 같다. 하지만 CL은 시간 단위가 아니라 clock cycle 수다. 두 메모리의 clock이 다르면 숫자의 크기만으로 실제 CAS 지연을 비교할 수 없다. 높은 전송률과 작은 첫 접근 지연을 구별하는 가장 쉬운 출발점이다.

CL, 즉 CAS latency는 내부 READ 명령 뒤 첫 출력 데이터까지의 지연을 clock 수로 표현한다. Alliance DDR4 데이터시트 MR0의 CAS Latency 설명은 전체 read latency에 Additive Latency가 더해질 수 있다는 점도 구분한다. 따라서 CL 비교는 같은 mode와 같은 접근 상태에서 해야 한다.

전송률을 clock 시간으로 바꾸기

DDR은 clock 한 주기의 두 edge에서 데이터를 전송한다. 2400MT/s는 초당 2400 million transfers이며 clock frequency는 기본적으로 1200MHz다. clock period는 약 0.833ns다. 3200MT/s의 clock은 1600MHz, period는 0.625ns다. MT/s를 곧바로 clock MHz로 읽으면 지연 계산이 두 배 어긋난다.

설명용 두 설정을 놓자. A는 2400MT/s·CL16, B는 3200MT/s·CL22다. 특정 제품의 성능 측정을 대신하는 조합은 아니다. AL과 추가 latency가 0이고 원하는 행이 이미 열려 있다면 CAS 지연은 다음과 같다.

• A: 16×0.833…ns ≈ 13.33ns
• B: 22×0.625ns = 13.75ns

CL 숫자는 B가 37.5% 크지만 실제 지연 차이는 약 0.42ns다. B의 더 빠른 clock이 cycle 수 증가의 대부분을 상쇄한다. 반면 B의 데이터 전송률은 3200/2400, 약 1.33배다. 이득과 손해가 서로 다른 성능 항목에 놓여 있다.

64bit-wide channel의 이상적 data peak를 계산하면 각각 19.2GB/s와 25.6GB/s다. 한 transfer의 8byte를 전송률에 곱한 값이고 GB는 10의 9승 byte다. refresh나 명령 공백이 없는 가정의 상한이며 실제 sustained 값은 아니다. 첫 데이터가 비슷해도 긴 전송에는 다른 이득이 생길 수 있다.

행을 새로 열어야 하면 CL 앞의 시간이 붙는다

같은 가상 조건에서 A의 tRCD를 14ns, B를 15ns로 놓으면 idle bank에서 새 행을 여는 첫 데이터 시간은 약 27.33ns와 28.75ns다. 다른 행이 열려 있다면 PRE 가능 시점과 tRP까지 추가된다. CL만 보고 전체 요청 지연을 판단하면 행 준비 비용을 빼먹는다.

실제 CPU가 관찰하는 메모리 지연에는 controller queue, rank와 방향 전환, refresh, 데이터가 돌아오는 연결 경로도 들어간다. 따라서 위 0.42ns 차이를 곧바로 프로그램의 load latency 차이라고 주장할 수 없다. 독립적인 큰 burst 요청과 종속된 작은 random read는 같은 전송률 변경을 다르게 체감한다.

동작 설정의 합법성도 별도다. 짧은 CL을 register에 넣을 수 있다는 사실이 해당 주파수와 온도에서 제품 minimum을 만족한다는 뜻은 아니다. supported CL 조합과 absolute timing minimum을 확인해야 한다. 낯선 두 설정을 비교할 때는 숫자를 ns로 옮기는 일과 vendor가 보증한 조합인지 확인하는 일을 함께 수행한다.

비교표에 남겨야 할 세 줄

첫째, 데이터율에서 tCK를 계산하고 CL×tCK로 CAS 시간 항목을 만든다. 둘째, AL 등 추가 latency와 row 상태를 명시해 비교 시작점을 맞춘다. 셋째, 첫 데이터 시간과 긴 전송의 상한을 다른 열에 적는다. 이 세 줄이면 “CL이 크니 무조건 느리다”와 “MT/s가 높으니 모든 요청이 빨라진다”는 두 오해를 동시에 피할 수 있다.

CAS 지연은 제품 숫자를 순위로 바꾸기보다 cycle 표현을 실제 시간으로 번역하는 문제다. 어떤 작업이 첫 데이터 지연에 민감하고 어떤 작업이 연속 전송에 민감한지 확인한 뒤 비교해야 한다. CL16과 CL22의 차이는 clock과 접근 상태를 붙였을 때 비로소 판단할 수 있는 정보가 된다.