---
title: "CAS 숫자만 비교해서 DRAM 첫 바이트 시간을 판단하면 틀리는 경우"
author: "브레이브브라우저쓰자"
published_at: "2026-10-07T09:27:04.624Z"
updated_at: "2026-10-05T23:23:09.528Z"
tags: ["cas 지연"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/cas-%EC%88%AB%EC%9E%90%EB%A7%8C-%EB%B9%84%EA%B5%90%ED%95%B4%EC%84%9C-dram-%EC%B2%AB-%EB%B0%94%EC%9D%B4%ED%8A%B8-%EC%8B%9C%EA%B0%84%EC%9D%84-%ED%8C%90%EB%8B%A8%ED%95%98%EB%A9%B4-%ED%8B%80%EB%A6%AC%EB%8A%94-%EA%B2%BD%EC%9A%B0"
ai_assisted: true
---

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

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

[원문](https://ariser.io/@writer_a9817d5a8de0/cas-%EC%88%AB%EC%9E%90%EB%A7%8C-%EB%B9%84%EA%B5%90%ED%95%B4%EC%84%9C-dram-%EC%B2%AB-%EB%B0%94%EC%9D%B4%ED%8A%B8-%EC%8B%9C%EA%B0%84%EC%9D%84-%ED%8C%90%EB%8B%A8%ED%95%98%EB%A9%B4-%ED%8B%80%EB%A6%AC%EB%8A%94-%EA%B2%BD%EC%9A%B0)

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

CL, 즉 CAS latency는 내부 READ 명령 뒤 첫 출력 데이터까지의 지연을 clock 수로 표현한다. [Alliance DDR4 데이터시트 MR0의 CAS Latency 설명](https://www.alliancememory.com/wp-content/uploads/AllianceMemory_8Gb_DDR4_AS4C1G8D4A-62BIN-62BCN_Datasheet_ver1.1_-Aug-2025-1.pdf)은 전체 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배다. 이득과 손해가 서로 다른 성능 항목에 놓여 있다.

| 가상 설정 | clock period | CAS 첫 데이터 지연 | pin 전송률 |
|---|---:|---:|---:|
| A: CL16 | 약 0.833ns | 약 13.33ns | 2400MT/s |
| B: CL22 | 0.625ns | 13.75ns | 3200MT/s |

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과 접근 상태를 붙였을 때 비로소 판단할 수 있는 정보가 된다.