길은 넓은데,
왜 데이터가 안 올까요?

1. 누가 누구에게 요청할까요?

DMA는 CPU 대신 데이터를 옮기는 장치입니다. 여기서는 DMA가 메모리에 “데이터 주세요”라고 요청합니다.

선을 단순화했습니다. 실제로는 인터커넥트와 메모리 컨트롤러 등이 더 있습니다.

화살표가 오른쪽이면 읽기 요청, 왼쪽이면 읽은 데이터의 반환입니다. 실제 신호 파형이 아닌 동작 설명입니다.

2. 한 번에 하나만 주문한다면?

카페에서 첫 음료를 받을 때까지 다음 주문을 못 한다고 생각해 보세요. 음료를 건네는 속도가 빨라도 만드는 동안은 기다립니다.

하드웨어에서는: 요청 후 첫 데이터까지의 지연과, 데이터를 실제로 전달하는 시간이 따로 있습니다.

빗금 = 기다림 / 초록 = 데이터 전송

240ns 동안 데이터는 40ns만 이동합니다.
이 사례에서는 반환 데이터 버스가 약 83%의 시간 동안 비어 있습니다.

비유의 한계: 실제 장치는 병렬 처리와 순서 제약이 있고, 카페처럼 동작한다는 뜻은 아닙니다.

3. 다음 주문을 미리 넣으면?

Outstanding은 “요청은 보냈지만 아직 끝나지 않은 일”의 수입니다. 독립된 요청을 겹치면 대기 시간을 일부 숨길 수 있습니다.

개념 비교입니다. 오른쪽은 초기 대기 이후 이상적인 연속 응답 구간이며, 같은 시간 길이를 비교한 그림이 아닙니다. 여러 데이터가 한 버스를 동시에 쓰는 것도 아닙니다.

DMA만 바꿔서는 안 됩니다. 브리지·메모리 쪽도 여러 요청을 받아줄 수 있어야 합니다. 데이터 간 의존성이나 순서 제약도 확인해야 합니다.

4. 숫자는 딱 세 단계만

가정: 버스 64bit, 클록 200MHz, 매 사이클 1번 전송. 요청당 64byte, 첫 응답까지 200ns입니다.

1. 길의 최대 수송량: 64bit는 8byte. 초당 2억 번 × 8byte = 1,600MB/s.
2. 한 번의 배송 시간: 기다림 200ns + 64byte 전송 40ns = 240ns.
3. 실제 모델 처리량: 240ns마다 64byte → 약 267MB/s.

모두 가상 모델 계산값입니다. 실측 결과나 제품 성능 보장이 아닙니다.

5. 설계 회의에서는 이렇게 봅니다

효과 검증: 전송 크기는 고정하고 동시 요청 수만 바꿉니다. 총 처리량, 실제 대기 중인 요청 수, 응답 지연, 데이터 채널 빈 시간을 측정합니다.

개선되지 않으면 요청 제한이 그대로거나, 메모리·데이터 공급 쪽이 진짜 병목일 수 있습니다. 요청을 늘리면 버퍼·전력·다른 작업의 지연이 증가할 수도 있습니다.

6. 한 문제만 풀어볼까요?

200ns 기다리는 구조에서 버스 폭만 2배로 늘리면, 전체 처리량도 2배가 될까요?