2등분의 드라이브 [P4608 6.4TB]

 중고 엔터프라이즈 시장을 보면 생각보다 재밌는 물건들이 많습니다. 이전에 리뷰했던 RMS-200도 그 중 하나인데, 처음 보면 놀랄만한 물건이죠. P3608부터 시작된 이 시리즈도 처음보면 신기한 구조에 당황할 수 있는 물건입니다.

 뭐, NVMe SSD이기에 최신 OS에서 인식은 당연히 가능하지만요.

 아무튼, 오늘의 제목은 정말 정하기 쉬웠습니다. 사실, 이 친구를 위해 아껴두고 있었다해도 과언이 아니니 말이죠.

 오랜만에 작성해서 그런지 서론이 원활하지 않은데, 신경쓰지 말고 바로 시작해봅시다.

Appearance

 HHHL 타입으로, 방열판엔 제품의 이름이 새겨져 있습니다. Optane SSD 이외에 HHHL 타입의 Intel SSD를 만져본 것은 처음인데, 제 취향은 아닙니다.

 후면에는 백플레이트가 없으며, 기판이 노출되어 있습니다.

 방열판의 모습도 한 번 보고 가시죠. 큼직한 것이 3개 보이는데, 아래에서 자세히 살펴보겠습니다.

Internal Components

문외한의 입장에서 일부 IC만 찾아보았으며, 제조시기 등에 따라 변경될 가능성이 있습니다.
맞지 않을 확률이 상당히 높으니 재미로만 읽어주세요. 

 컨트롤러는 Intel SLLWY를 2개 사용합니다. 각 컨트롤러는 Cortex-A 시리즈 2코어가 채용되었으며, 12채널을 지원합니다. 아래에서 다시 다루겠지만, 두 컨트롤러는 역할 분담을 하는 것이 아니라, 각각 하나의 SSD를 관리합니다. 

 DRAM과 NAND는 아래에서 한 번에 다루도록 하겠습니다.

 PMIC는 IDT P78001이 2개 사용되었습니다. 정확히는 P78001-A0라고 해야겠네요. 이전 905P 분해에서 본 적이 있습니다.

 PCIe Switch로 PLX Technology PEX8718가 하나 탑재되었습니다. P3608이나 P4608 시리즈를 존재하게 만들어주는 핵심 부품인데, 역시 아래에서 따로 다루어보겠습니다.

 PLP를 위한 Capacitor는 Nichicon UUD1V330MCL1GS UUD1V331MNL1GS를 사용합니다. 이미지 수정이 귀찮았어요. 35V 330µF의 사양이며, 총 4개가 실장되었습니다.

 DRAM은 두 가지 종류가 있는데, Micron MT40A2G8NRE-083E:B와 Micron MT40A1G4RH-083E:B입니다. 공통적으로 DDR4 2400MT/s CL16의 사양을 가지나, 용량은 전자가 16Gb, 후자가 4Gb입니다.

 이러한 DRAM이 전면에 2개씩, 후면에도 2개씩 실장되어, 총합 80Gb = 10GB의 용량을 가집니다.

 NAND는 총 네 종류의 칩이 실장되었는데, Intel 29F04T2AWCMG4와 Intel 29F02T2AOCMG4, Intel 29F64B2AMCMG4와 Intel 29F32B2ALCMG4입니다.

 공통점은 Intel의 3D1 32L NAND라는 것인데, Intel의 첫 번째 3D NAND 입니다. 다른 회사에서 볼 수 있는 Charge Trap Flash 형태가 아닌 Floating Gate인데, 이 부분은 다른 글로 다루어보고 싶네요. 아무튼, ONFI 4.0기반으로, 핀당 667MT/s의 속도를 지원합니다.

 3D1 NAND는 256Gb MLC와 384Gb TLC 형태로 출고되었는데, 이 둘의 PN이 동일하다는 것도 특징입니다. 물론, 이 SSD에서는 TLC로 사용되었지만요.

 우선, 전면에만 8개 실장된 29F04T2AWCMG4입니다. Die를 16개 패키징하여 칩당 768GB의 용량을 가질 수 있습니다. 2CH 8CE 구성입니다.

 다음은, 전면과 후면에 4개씩 실장된 29F02T2AOCMG4입니다. Die를 8개 패키징하여 칩당 384GB의 용량을 가집니다. 마찬가지로 2CH 8CE 구성입니다.

 후면에만 4개 실장된 29F64B2AMCMG4는 Die를 2개 패키징하여 칩당 96GB의 용량을 가집니다. 2CH 2CE 구성입니다.

 마지막으로 29F32B2ALCMG4도 후면에만 4개가 실장되었는데, Die가 1개만 패키징되어 48GB의 용량을 가집니다. 2CH 1CE 구성이고요.

 그럼, 정리해봅시다. 실장된 칩들의 총 용량은 9792GB입니다. 6.4TB라는 용량과 eSSD라는 특징을 생각해보면 추가적인 Over Provisioning이 가해졌다는 것을 알 수 있는데, 그 수치가 무려 53%입니다. 상당하네요.

 참고로, 실장된 칩이 모두 MLC였다면 6528GB이라는 총 용량을 가집니다. 여기서도 2%의 OP로 6.4TB라는 용량을 구현할 수 있으나, 해당 SSD의 DWPD나 성능 등 여러 요소를 고려하면, MLC라는 추측은 배제됩니다. 뭐, 그전에 TLC라고 명시하고 있지만요.

 그외에는 다양하게 전면과 동일한 MOSFET인 Infineon IRLHS6242, DDR Termination Regulator로 Texas Instruments TPS51206, Clock Buffer는 Silicon Labs Si5330, MCU인 Microchip PIC16F18346 등을 확인할 수 있었습니다.

Datasheet

 이 친구는 제가 이전에 리뷰한 PM1725(F320)처럼 Oracle OEM 제품입니다. Oracle MN은 ICDPC5ED2ORA6.4T, Oracle PN은 7335943 Rev 14로 지정되어 있습니다. 좀 더 쉽게 F640 v1으로 불러도 무방합니다. 

 눈치 빠른 분은 아시겠지만, v2는 P4618, v3는 P5608입니다. 쓸데없는 정보이지만, P5608은 PCIe Bifurcation을 요구한다는 것이 이전 세대들과의 큰 차이점입니다.

 Product Specification을 살펴보면 성능 지표를 확인할 수 있으며, 내구성 또한 약 3DWPD임을 확인할 수 있습니다. 특히, Components 부분에서는 TLC NAND임을 명시함과 동시에 2개의 컨트롤러를 사용하고 있다는 것도 확인시켜주네요.

Notable Points

Power-Loss-Protection Time

 대부분의 eSSD는 PLP를 위한 기술이 적용됩니다. 갑작스러운 전원 차단에 대해 어느 정도의 백업 시간을 가질 수 있는지 알아봅시다.

 앞서 언급되었지만, P4608 6.4TB는 Nichicon UUD1V331MNL1GS를 4개 실장하였으며, 약 0.8085J의 에너지를 저장할 수 있습니다. 해당 값을 토대로, 데이터시트와 Power State에 지정되어 있는 전력 소모를 버틸 수 있는 시간은 아래와 같습니다.

 IDLE 상태에서는 81ms라는 긴 시간을 확보할 수 있으며, 일반적인 상황에서는 30ms 이상을 확보할 수 있을 것으로 기대됩니다.

 PS0 *2 항목이 존재하는 이유는 아래를 보시면 됩니다.

2 in 1

 Internal Components 부분에서 언급했듯, P4608에는 PCIe Switch가 내장되어 있습니다. 기종은 PLX Technology의 PEX8718이며, PCIe 3.0 16-Lane 5-Port를 지원합니다.

 PCIe Switch에 대한 설명은 글이 너무 길어질 것 같아서 생략하겠습니다. 간단하게 말하자면, PCIe x8 슬롯을 2개의 PCIe x4으로 만들 수 있습니다. 위 이미지의 우측에서 빨갛게 강조한 것이 P4608에서 사용한 PEX8718의 설정이죠.

 CPU는 PCIe Switch 뒤에 있는 두 SSD를 완전히 개별 장치로 인식하게 됩니다.

 위 이미지를 보시면 조금 더 이해가 쉬울 것 같네요.

 결국, 2개의 SSD가 하나의 PCB에 존재하는 것과 다를 것 없는 상태입니다.

 노란 부분이 Host와 직접 연결되어 통신을 거치고, 빨간 부분과 파란 부분이 각각 3.2TB SSD가 됩니다. 굳이 따지자면, P4600 3.2TB 2개라고 볼 수 있겠죠?

SW Report

 smartmontools와 NVMe-CLI의 id-ctrl 결과는 GitHub에 첨부하도록 하겠습니다.

 CDI 이미지를 보면 알 수 있지만, TRIM을 지원하지 않습니다. 이 때문에 성능 측정을 진행하며 살짝 난항을 겪었습니다.

 SN(일련번호, Serial Number)도 SSD와 마찬가지로 별도 관리되었습니다. GitHub에 전부 나와있으니 직접적으로 언급하자면, 각 영역의 SN은 "PHLE846500FQ6P4BGN-1"와 "PHLE846500FQ6P4BGN-2"로 명확하게 구분되었습니다.

 여러 영역이 있다는 점에서 Multiple Namespace가 떠오르는데, Multiple Namespace는 SN이 동일하게 노출됩니다. 이렇게 말하니 비슷한 기술 같지만, 영역이 나눠져있는 것 외에는 유사점이 더 적은 기술입니다. Multiple Namespace를 활용한 성능 측정도 생각해보고 있는만큼, 나중에 가볍게 다루어보고 싶네요.

DUT Summary

벤치마크를 진행할 SSD에 관한 요약입니다.

 FW는 QDV1RF30으로, 메뉴얼에 명시된 QDV1RF35는 아니지만, 어느 정도 큰 문제들이 해결된 버전으로 보입니다. 

 Power State는 개별 드라이브에서 각각 13.50W의 PS0을 보고합니다. 

Comparison Device

 비교군은 아래와 같습니다.

 P4608의 두 영역에서 한 영역과 비교하기 위해 7300 MAX를, 원래 두 영역을 사용하는 것을 가정한 제품이기에 이와 비교하기 위해서 7450 MAX의 데이터를 가지고 왔습니다.

 다만, PCIe Switch로 두 영역이 개별로 노출되어 있는 것은 리뷰어에게 좀 혹독하군요. 그래서 적당히 SW RAID로 묶어서 진행했습니다. 

 데이터 수집이 작년 11월이었는데, 여러 일을 동시에 처리하느라 깊게 생각하지 않았습니다.

Test Platform

 테스트 환경은 위와 같습니다. Windows 25H2(26200.6899)에 종속되는 도구들을 제외하고는 모두 FIO 3.41을 통해 Rocky Linux 10(6.12.0-55.12.1.el10_0)에서 실행되며, io_uring과 Polling을 적극적으로 활용합니다. 또한, 양쪽 다 기본 Inbox Driver를 사용합니다.

 HW 사양에 대해서는 상단 우측의 fastfetch를 통해서 확인할 수 있지만, 다시 언급하자면, AMD의 9600X를 사용하고 있습니다. DUT는 5.0 x16 연결이 가능한 PEG 슬롯에 장착됩니다.

 자세한 벤치마크 방법론에 대해서는 이전에 작성한 Refresh Benchmark를 참고해 주시길 바랍니다.

 추가로, TRIM이 불가해 cSSD Benchmarking에서는 Fill Drive의 측정을 완료한 뒤, Purge를 다시 진행하고 128k로 75%를 채웠습니다.

 P4608의 본래 성능을 측정하기 위해서는 두 영역을 RAID 등으로 묶을 필요가 있었습니다. 이에 따라 Windows에서는 내장된 기능을 이용해 Stripe Volume을 생성하였으며, Linux에서는 mdadm을 이용해 RAID 0로 묶었습니다.

 mdadm으로 묶은 볼륨엔 여러 이유로 cSSD Benchmarking을 진행하지 않았습니다. 그렇기에 데이터들은 단일 영역을 위주로 봐주셨으면 합니다. 사실상 P4600 3.2TB의 리뷰가 되어버렸네요.

cSSD Benchmarking

start /wait Rundll32.exe advapi32.dll/ProcessIdleTasks

 Windows에서는 위의 명령어를 실행하고 15분 뒤를 IDLE 상태로 정의해 벤치마크를 진행합니다. 각 벤치마크 사이에는 5분의 휴식 시간이 부여되며, Purge는 Linux에서 nvme format 명령어를 통해 수행했습니다. 

CrystalDiskMark 9.0.1

 RND 4k 쓰기를 제외하고는 비교군에 밀리는 모습입니다. 지금보니 RAID 0에서 RND 4k 읽기의 성능도 낮게 나왔군요.

3DMark Storage Benchmark

 7300 MAX와 DUT 간에는 큰 차이가 없었습니다. RAID 0로 묶었을 땐 점수가 소폭 상승했으나, PCIe 4.0 x4인 7450 MAX엔 밀렸습니다.

SPECworkstation 4.0

 SPECworkstation에서는 가장 뒤떨어지는 모습을 보였습니다.

 각 워크로드를 자세히 보면, ccx나 cfd 워크로드에서 심각하게 뒤쳐지는 모습도 확인할 수 있습니다. 사실 두 워크로드를 제외해도 상당수에서 밀리는 모습도 보입니다.

Fill Drive

 나래온 더티테스트와 비슷한 벤치마크입니다. FOB상태로 시작하여, SEQ 128k QD256으로 드라이브 전체를 2회 채우며, 0.1s 단위로 값을 측정합니다. 1회차와 2회차 사이의 휴식은 충분히 부여됩니다.

 평균 성능은 가장 뒤떨어지며, 분포가 일정하지 않은 모습을 보입니다.

 cSSD의 SLC Caching과 같은 기능이 없는 이상, 일반적으로 1회차와 2회차 Fill Drive에는 큰 차이가 발생하지 않습니다.

 첫 번째와 두 번째의 Fill Drive에 대한 전체 평균값은 1256MB/s로, 가장 뒤쳐졌습니다.

 첫 번째 Fill Drive에 대한 하위 1% 속도는 1071MB/s였습니다. 바로 위의 값과 비교하면, 7300 MAX의 깔끔함이 눈에 띄네요.

Sync Performance

 자체적인 Pre-Conditioning 이후, 해당 영역에 한해서 측정됩니다. 쓰기량은 총 500MiB이며, 최대 소모 시간은 2분으로 제한합니다. sync=1 옵션을 활용했습니다.

 eSSD에서 이 벤치마크는 큰 의미가 없죠. 단순한 4k QD1 쓰기와 다름이 없습니다.

Low QD Performance by RW Ratio 

 이전과 마찬가지로 Pre-Conditioning 이후에 측정하며, Burst 성능을 측정하기 위해서 각 단계에서 가해지는 I/O의 양은 GB 단위가 되지 않습니다. 다시 말해, 매우 가벼운 부하입니다. 전체 용량의 75%는 이미 채워져 있지만요.

Weighted Graph 

 QD1 80%, QD2 15%, QD4 5%로 가중치를 부여해 보기 쉽게 나타냅니다.

 완전한 쓰기작업을 제외하고는 7300 MAX와 굉장히 유사한 값을 보여주고 있습니다.  

 완전한 읽쓰기를 제외하고 산출한 평균값입니다. 7300 MAX와는 0.1MB/s 차이네요.

eSSD Benchmarking

 Purge 직후를 제외한 모든 단계 사이에는 휴식 시간이 부여되지 않습니다. Pre-Conditioning은 User Capacity의 2배를 쓰고나서도 Steady State에 진입할 때까지 이를 계속 진행합니다. 
 Steady State는 SEQ의 경우엔 대역폭의 기울기가 ±10%인 상태를 30초간 유지하는 것을 기준으로 하며, RND의 경우에는 IOPS의 기울기가 ±10%인 상태를 30초간 유지하는 것을 기준으로 합니다. 이를 달성할 수 없을 땐 User Capacity의 23배까지 쓰기를 진행합니다.

 모든 워크로드는 User Capacity의 전체 영역에 대해서 진행하며, 각각 30초의 적응 시간을 가진 후에 5분 동안 성능측정을 진행합니다. 다시 말해, 128k Read 성능을 측정한다면 QD1 ~ QD256까지 총 9개의 작업이 있으며, 모든 작업이 30초의 적응 시간과 5분의 측정시간이 부여됩니다.

 역시 자세한 벤치마크 방법론에 대해서는 이전에 작성한 Refresh Benchmark를 참고해주시길 바랍니다.

4-Corners Performance

SEQ Pre-Conditioning

 SEQ Pre-Conditioning은 1시간 25분 정도 소모되었으며, 1236MB/s로 Steady State에 진입했습니다. RAID 0는 2444MB/s로 진입했고요.

SEQ 128k Performance

 스펙시트에 기재된 값은 읽기가 6.5GB/s, 쓰기가 3.1GB/s였죠? 읽기는 QD64에서 만족하는 것을 확인했으나, 쓰기는 도달하지 못했습니다. 물론, RAID 솔루션에 따라 달라질 수 있는 값이란 점에 유의하시기 바랍니다.

 단일 볼륨의 쓰기는 QD1과 QD2가 12MB/s 차이로 거의 포화에 이른 것을 확인할 수 있었습니다.

RND Pre-Conditioning

 RND Pre-Conditioning은 약 2시간이 소모되었습니다. Steady State에는 단일 볼륨과 RAID 0가 각각 193k와 379k로 진입했습니다. 비교군인 7300 MAX나 7450 MAX에 비해 변동이 심하지만, 평균값은 더 높은 것도 확인할 수 있네요.

RND 4k Performance

 4k RND 성능은 읽기와 쓰기가 1397k IOPS, 428k IOPS로 명시되었죠. 양쪽 다 기입된 속도에 도달하지 못했습니다. 특히, 읽기는 RAID 0의 유무와 상관없이 약 720k IOPS의 속도를 보였습니다. 역시 RAID 솔루션 등에 따라 달라질 수 있는 값입니다.

4-Corners Consistency

 QD에 따른 4-Corners Performance의 안정적인 정도를 제시합니다. 상위 99.9%값과 평균을 이용하는데, SEQ 128k에서는 Bandwidth를 기준으로, RND 4k에서는 IOPS를 기준으로 계산합니다. 참고로, RND 4k에서 QD1에 대한 값은 이후 Tail Latency에서 자세히 살펴보기에 제외됩니다.

 단일 3.2TB SSD에 접근할 때는 읽기가 대체로 90% 이상인 모습을 보여줍니다. 쓰기는 대개 80% 언저리를 유지하네요.

 사실, RAID 0로 묶었을 때는 성능 측정 자체가 순탄치 않았는데, Low QD에서 0%에 가까운 Consistency를 보였습니다. 위 4-Corners 성능의 그래프를 유심히 보셨다면 알 수 있는데, 일부 그래프에서 RAID 0 볼륨의 시작점이 굉장히 좌측 하단에 밀집되어 있습니다. 

 이 문제의 심각성은 Tail Latency에서 돋보였는데, 아래쪽에서 다시 다루겠습니다. 왜 P4600 리뷰로 봐달라고 했는지 아시겠죠?

Specific Workload Performance

 4-Corners Performance가 아닌 워크로드를 분리했습니다. 단, 워크로드 이름은 편의상 붙인 것뿐이며, 실제 환경에서는 다양한 Block Size와 RW 비율이 나타난다는 것을 명심해야 합니다. Block Size들의 정확한 비율과 RW 비율을 결정하기 힘들어 대략 분류한, 가상의 워크로드입니다.

Boot Workload (OCP BootBench)

 Hyperscale에서의 Boot Drive로 사용될 때의 성능을 측정하는 벤치마크입니다. SEQ Write로 User Capacity가 2번 채워지면, 동기 쓰기, TRIM, 읽기가 동시에 가해지며, 결과의 지표는 읽기 IOPS입니다. 60k IOPS를 통과하면 합격입니다.

 테스트를 진행할 수 없었습니다. 이유는 역시 TRIM 미지원이죠.

Read Intensive Workload (SEQ 128k R95:W05)

Mainstream Workload (RND 4k R70:W30)

 RND RW를 각각 확인하면 7450 MAX보다 P4608 단일 볼륨이 뒤쳐지지만, 혼합된 상황에서는 오락가락하는 모습을 보여주었습니다.

Write Intensive Workload (RND 4k R50:W50)

AI Workload (RND 512B Read)

 둘 다 64bit Tausworthe Generator가 사용되었습니다.

Random 4k QD1 Tail Latency

 Latency에서 가장 느린 구간을 의미합니다. 그렇기 때문에 QoS(Quality of Service)에 큰 영향을 미치고, 실제로 eSSD의 데이터시트에서는 QoS를 명시하고 있습니다. 

 여기에선 100ms나 10ms 단위가 아닌, 모든 개별 I/O에 대한 지연시간을 카운트하여 그래프를 그립니다. 그렇기 때문에 데이터가 상당히 방대해, 이 항목은 RND 4k QD1에 대해서만 진행합니다.

 앞서 말씀드린대로, RAID 0로 묶었을 때에는 Tail Latency가 심각하게 늘어졌습니다. 위 그래프는 10ms에서 잘리느라 그 심각성이 돋보이지 않을 수도 있는데, 아래 그래프를 보시면 느낌이 오실겁니다.

 RND 4k Read의 그래프입니다. QD1과 QD2에서 99%가 넘어가는 지연시간은 제대로 측정되지 않은 것이 보입니다. 범례에서 괜히 0.1k IOPS, 0.0k IOPS로 표시되는게 아니죠.

 그럼에도 불구하고, 지연시간에 대한 값은 스펙시트에 기입된 값보다 우수하게 측정되었습니다. 제 리뷰에서 Typical Value는 여러 제조사의 표기에 따라 평균값이 아니라 50% 값으로 잡고 있으니까요. 

 참고로, 평균값은 RND 4k Read가 878ms, RND 4k Write가 6ms였습니다. 

 스펙시트에 기입된 순차 지연시간은 RW가 79µs/14µs였죠. Block Size 128k에서는 46µs/60µs가 측정되었는데, 스펙시트는 아마 4k를 가정하고 있는 것 같습니다.

Closing

 이 친구는 어떻게 리뷰를 써야할지 고민했습니다. mdadm으로 묶고 성능 측정을 했으나, 조금의 후회도 남고, TRIM이 지원되지 않는 것도 좀 예상 외의 상황이었거든요. 그래서 반쯤 포기한 데이터들입니다. 

 제 리뷰를 진중하게 보시는 분은 적겠지만, 이번 리뷰는 가볍게 넘어가듯이 보셔도 됩니다. 작성에도 공을 덜 들였고요. 이걸 마지막에 적으면 어쩌냐는 생각도 지금에 와서 드네요. 조금 쉬다가 오타 점검을 한 뒤, 퇴고하도록 하겠습니다.

 다음주는 예비군이 예정되어 있어 훈련장까지 가는 길에 힘을 써야할 것 같습니다. 해운대 너무 멀어요. FMS 이야기는 작년과 다르게 글 하나로 끝낼 예정입니다. 기다리진 말아주세요.

 그럼, 다음 리뷰로 뵙겠습니다.

그래도 소자 분석에는 꽤 공을 들였습니다...