낮은 점수는 싫으니까 SLC캐시에 올인하려고 합니다. [SN8100 2TB]

 PCIe 5.0 SSD를 리뷰한 지도 참 오래된 것 같습니다. PM9E1을 만진 지 벌써 1년이 지났고, P51은 반년이 지났습니다. 그렇게 보니 1년밖에 지나지 않았는데, 참 많은 것을 새로 배우기도 했네요. SSD 리뷰로 따지면, 방법론에도 많은 변화가 있었고, 앞으로 진화를 한 번 더 염두에 두고 있습니다. SSD 단품에 대한 리뷰를 차츰 줄일 생각이라, 아마도 최종 방법론이 될 것 같네요. 제가 가지고 있던 제품들의 데이터는 어느 정도 수집을 해, 리뷰를 시작한 목적 중 하나를 달성하기도 했고요.

 아무튼, 넘어가서 오늘의 리뷰는 또 기념할 만한 최신 제품, PCIe 5.0 cSSD 중에서도 플래그십에 해당하는 SN8100입니다. 테스트 시스템이 달랐음에도 불구하고 SN850X 리뷰를 먼저 올린 것도 이 리뷰를 위해서였죠. 직접적인 비교는 하지 않겠지만, WD=SanDisk SSD의 특징을 이번 리뷰로 보여드릴 수 있을 것 같습니다.

 이번 세대에서는 내부 구성도 기존 WD_BLACK과 다르게 외부 컨트롤러를 채용했습니다. 당연히 NAND도 새로 바뀌었고요. 비슷한 성능을 자랑하는 PCIe 5.0 플래그십 SSD들이 많은데, 과연 내부 동작까지 비슷할지, nCache 4.0은 여전할지 의문이 들죠? 

 그럼, 바로 시작해 봅시다.

Appearance

 구수한 WD_BLACK의 디자인입니다. 솔직히 이 디자인이 이쁘다고 생각하진 않았는데, 지금와서 다시보니 이쁜 것 같습니다.

 후면에는 SanDisk 로고가 기입되어 있습니다.

아! 그리웠던 WD_BLACK의 추억이여!

 하지만, 이제는 보내줄 때죠. SanDisk Optimus GX Pro 8100의 시간이다.

Internal Components

문외한의 입장에서 일부 IC만 찾아보았으며, 제조시기 등에 따라 변경될 가능성이 있습니다.

 컨트롤러는 Silicon Motion SM2508을 사용했으며, SanDisk A101-250800-AC의 마킹이 되어있습니다. 8채널의 컨트롤러로, 3600MT/s로 통신이 가능하며, TSMC 6nm FinFET 공정으로 제조됩니다.
 SM2508은 1.25GHz로 동작하는 Cortex-R8 4코어와 Cortex-M0 1코어로 구성되는데, R8 4코어는 SMP로 묶여 메인 작업을 분산처리 하며, M0는 I3C나 SMBus와 같은 Sideband Management를 진행합니다.
 이 때문에 SM2508의 4+1 구조를 일반적인 ARM big.LITTLE 구조로 보긴 어렵습니다. 성능에 따라 작업을 분배하는 것이 아닌, 다른 역할을 기능적으로 분리했기 때문이죠.

 DRAM은 DDR4 2GB입니다. 제조사는 Micron, Nanya, Samsung 등을 크게 가리지 않으며, 3200MT/s와 2666MT/s가 혼용되고 있습니다. 참고로, 전작인 SN850X와 다르게 1:1000 법칙을 잘 준수해, 4TB 모델에는 4GB, 8TB 모델에는 8GB의 DRAM이 채용됩니다. 다만, SM2508이 반드시 이러한 비율을 요구하는 것은 아니기에, 이 결정은 WD=SanDisk의 선택이라고 할 수 있습니다. 이유는 몇 가지 떠오르지만, 실제로는 제조사만이 알겠죠.
 제가 가진 모델은 Micron MT40A1G16TB-062E:F가 실장되어 있었습니다. 사양은 DDR4 3200MT/s CL22 2GB입니다.

 NAND는 SanDisk 025255 1T00이며 실장된 칩은 2개입니다. 데이터시트에서 TLC 3D CBA NAND임을 명시하는데, 여기서 BiCS8인 것이 드러나죠. CBA(CMOS directly Bonded to Array)에 관한 내용은 또 언젠가.
 아무튼, BiCS8 X3 1Tb Die를 사용하는데, 하나의 칩에 8개의 Die가 Packaging되어, 개당 1TB의 용량을 가집니다. 218L(109*2) 구성에 4 Planes이며, Toggle 5.0 3600MT/s의 I/O 인터페이스를 가집니다.
 참고로, BiCS8 TLC는 개발 단계에서 3200MT/s의 인터페이스를 가지고 있었습니다.

 PMIC는 22B070로 마킹되어 있습니다. 주변 소자 배치가 전작과 상당히 유사해, 이전과 마찬가지로 STmicroelectronics에서 WD=SanDisk용으로 제조한 HORUS 계열로 추측됩니다.

 혹시라도 Flash ID의 출력이 궁금하신 분들은 아래를 참고하시면 됩니다.

3: (WD_BLACK SN8100 2000GB
Please select drive number:3
Drive       : 3(NVME)
Scsi        : 4
IOCtl: NVME_OF failed 0x1!

Driver      : W10
Model       : WD_BLACK SN8100 2000GB
FW          : 830ZR80A
Size        : 1907729 MB [2000.4 GB]
LBA Size    : 512
Controller  : SM2508 [SM2508AC]
FW revision : G2R0Y91A
ROM version : 2508ACROM:X0613A

--- FW params ---
FlashID : 0x45,0x49,0xa9,0x3,0x7e,0xe6,0x0,0x0 - Sandisk 218L BiCS8 TLC 16k 2048Gb/CE 1024Gb/die 4Plane/die
Channel                 : 8
Ch map                  : 0xFF
CE map                  : 0x01
Pages/Block             : 3270
First Fblock            : 2
Total Fblock            : 687
Bad Block From Pretest  : 35
Start TLC/MLC Fblock    : 21
DRAM Info               : [0x03 0x66]

Datasheet

 데이터시트에서는 최대 성능과 소비 전력에 대한 언급이 있습니다. 또한, 전작인 SN850X와 다르게 4TB 제품도 단면임을 암시하고 있고요.

 잠깐 짚고 넘어가자면, 전력 효율이 많이 증가한 모습이 보입니다.

 SN8100이 PCIe 4.0이 아니라 PCIe 5.0으로 동작할 때의 전력 소모라고 생각하면 더 인상적이죠? 다만, 평균값이라는 점에 유의할 필요도 있습니다.

SW Report

 이번 제품은 제가 직접 구매한 제품입니다. 제가 가혹하게 쓰기에 중고품을 선호했으나, 정작 구할 때는 중고품이 없고 미개봉 제품만 있더라고요. 

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

DUT Summary

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

 테스트할 당시의 최신 Firmware를 적용했습니다. 

 특이하게도 Active Power의 값이 Maximum Power와 다르게 명시되어 있습니다. 보통은 동일하게 통일하기에 저도 이런 상황을 고려하지 않았는데 말이죠. 다만, 데이터시트에 등록된 값과는 약간 차이를 보였습니다. 

 Dashboard에서 조정이 가능한 Game Mode를 활성화하면, PS1 이하의 상태가 제거됩니다.

Comparison Device

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

 이전에 리뷰한 SN850X 4TB는 테스트 시스템이 달라서 제외했습니다. 아쉽지만, PCIe 5.0 cSSD의 비교에 초점을 맞춰봅시다.

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를 참고해 주시길 바랍니다.

cSSD Benchmarking

start /wait Rundll32.exe advapi32.dll/ProcessIdleTasks

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

CrystalDiskMark 9.0.1

 CDM에서는 데이터시트의 14900 MB/s와 14000 MB/s를 만족하는 모습을 보였으나, Random 속도는 그렇지 않았습니다. 

 일반적으로 Block Size를 4k라고 잡으니, 2.3M IOPS와 2.4M IOPS는 각각 9421 MB/s, 9830 MB/s 로 환산할 수 있거든요. 아래 표를 보시죠.

 Native NVMe를 활성화했을 때, 일부 성능은 만족하는 모습을 보였습니다. 다만, Random Write는 Linux로 진행하여도 만족하지 못했습니다. (PM9E1 1TB는 예외적으로 IRQ로 진행했을 때 RND Write가 2600k IOPS를 초과하는 것을 확인할 수 있었습니다.)

 재미로 4k QD1 속도도 측정해봤습니다.

3DMark Storage Benchmark

 3DMark에선 SN8100 2TB가 6331점을 기록하며 PM9E1 1TB와 P51 2TB를 앞섰습니다. 75% 상태에서도 성능 저하는 없었으며, Game Mode에서는 약 6%의 추가 상승이 있었습니다.

SPECworkstation 4.0

 SPECworkstation에서는 SN8100 2TB가 2.13점을 기록하며 P51 2TB을 앞섰지만, PM9E1 1TB에는 크게 밀리는 모습을 보여주었습니다. 여러 리뷰에서 말씀드렸는데, PM9E1은 여기서 굉장히 높은 점수를 보여줍니다.

 세부 워크로드를 직접 비교하자면, maya와 mcad 워크로드에서는 PM9E1 1TB에 크게 밀리는 모습입니다. 7zip, MandE, cfd 등의 워크로드는 큰 차이가 없는 모습을 보여주네요. 반면, Game Mode나 75%의 유무는 점수에 큰 영향을 미치지 않았습니다.

Fill Drive

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

 비교군을 다 집어넣은 그래프입니다.

 그럼, 조금씩 뜯어보죠. SLC Cache 영역에서는 14.1 GB/s의 성능을 보이며, 677 GB의 대용량 SLC Cache를 확인할 수 있습니다. 이후에는 3.9 GB/s의 성능 단계를 거쳐 후반부에 진입합니다.

 후반부의 평균값은 1945 MB/s이며, 중앙값은 2004 MB/s, 하위 10% 값은 683 MB/s 입니다. 그런데, 강하게 확인되는 4가지 포인트가 있죠? 이들은 3980, 2120, 1330, 684 MB/s에 해당합니다. 이러한 패턴을 통해서 유추할 수 있는 정보들을 언젠가 리뷰에 녹여보면 재밌을 것 같아서 고민 중입니다.

 두 번째 Fill Drive도 그래프를 다 집어넣은 결과입니다. 다만, Game Mode의 활성화 여부에 따라 살짝 다른 모습이 보였습니다. 이후, 추가로 결과 재현을 시도해 볼 예정입니다. 

 공통적으로 11 GB의 SLC Cache가 관찰되었습니다. 그럼, 각각의 재밌는 점을 말씀드리죠.

 우선, Game Mode가 비활성화된 상태에서는 3.75 GB/s를 진행하다가 3.89 GB/s로 성능이 전환되는 순간이 있습니다. 그런데, 흥미롭게도 이 전환되는 시점이 677 GB를 썼을 때입니다. 첫 번째 Fill Drive에서 관찰된 SLC Cache의 크기와 동일하죠.

 다음은 Game Mode입니다. 대개 3.90 GB/s의 속도를 보여주는데, 중간에 성능이 극심하게 하락하는 부분이 있죠? 이 구간의 평균 속도는 1.83 GB/s이며, 빈번하게 등장하는 값 중 낮은 값은 약 685 MB/s였으나, 순간적으로 약 300 MB/s로 하락하는 경우도 관찰되었습니다.

 최소 점만을 비교해 보면, 첫 번째 Fill Drive에선 625 MB/s 였으며, 두 번째 Fill Drive에서는 Game Mode에서 274 MB/s 였습니다. 

 Fill Drive의 전체 평균값에선 P51 2TB가 가장 빨랐으며, SN8100 2TB는 3291 MB/s를 기록해, 5%의 차이를 보였습니다.

 첫 번째 Fill Drive에 대한 하위 1% 속도는 평균값과 다르게 650 MB/s를 기록하며, 꽤 뒤쳐지는 모습을 보였습니다.

Sync Performance

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

 43 MB/s의 속도를 보여주었습니다. 

Low QD Performance by RW Ratio 

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

 개편되는 벤치마크에선 이 항목이 빠질 예정입니다.

Weighted Graph 

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

 전체적으로 PM9E1 1TB보단 우수하며, 쓰기 비중이 높을수록 Game Mode의 효과가 크게 나타났습니다. 반대로, 읽기 비중이 커질수록 P51 2TB와의 격차는 줄어드는 모습도 보입니다.

 완전한 읽쓰기를 제외하고 산출한 평균값은 310 MB/s로, P51 2TB에 약간 밀리는 모습이었습니다.

SLC Cache Reclaim

 SLC 캐시의 회복에 대해서 알아보기 위해 설계되었습니다. Purge를 수행하고, User Capacity의 50%를 SEQ 128k QD256로 채운 뒤, 잠깐의 휴식을 취합니다. 이후, SEQ 128k QD256 쓰기를 1분간 진행합니다. 
 이 휴식 시간을 늘리며 테스트를 7회 진행합니다. 그래프들은 휴식 이후 1분간의 I/O에 대한 결과입니다.

 50%의 Fill Drive 이후에 10분의 유휴시간이 부여되면, 사실상 SLC Cache가 회복되는 것으로 확인되었습니다.

 1분, 2분, 5분의 그래프에서 회복 속도를 대략 1.46 GB/s로 추정할 수 있습니다. 또한, 10분 이후는 시작 구간의 330 GB를 고속으로 채우는 모습인데, 이는 남아 있는 용량인 1TB를 대부분 SLC로 사용하고 있는 것으로도 말할 수 있습니다.

 다시 말해서, 측정 포인트는 존재하지 않지만, 약 7분이면 SLC Cache의 회복이 이루어질 것으로 예상됩니다.

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

 21분의 시간이 흐른 뒤, 3797 MB/s의 속도로 Steady State에 진입했습니다. 

SEQ 128k Performance

 SEQ Read는 QD32에서 14980 MB/s까지 상승하며, 비교군 중 최고의 성능을 보였습니다. 다만, SEQ Write에선 P51이 약 4.9 GB/s의 속도를 보여줘 1 GB/s정도 밀리는 모습입니다.

 그리고, 이젠 어느 정도 확신을 가지고 말씀드릴 수 있습니다. PM9E1 1TB의 Steady State SEQ Read 성능이 12 GB/s인 것은 TLC의 속도이기 때문입니다. 2TB 용량에서도 비슷할 것 같고, 4TB에선 비교군들처럼 14 GB/s의 성능을 보여주지 않을까 예상합니다.

RND Pre-Conditioning

 RND Pre-Conditioning에서는 약 6시간 25분이 소모되었으며, 38.3k IOPS로 Steady State에 진입... 음... 이걸 정말 Steady State라고 불러야 할까요? 지연시간 그래프는 축의 척도가 파괴되었네요.

 예전 느낌이 나도록 X축을 2500초로 제한해 보겠습니다. 지연시간 그래프에서 초기에 200 ms로 다다르는 값이 일부 보이네요.

 이에 따라, 저 값들을 무시하기 위해 50 ms로 Y축을 제한해 봤습니다. 실제로, 극초기의 값을 제외하고는 모두 50 ms 이하가 측정되었고요.

 이번엔 IOPS 그래프에 뿌려진 파란 물 자국을 없애보았습니다. 

 대부분의 시간은 15k ~ 25k IOPS의 값을 보였는데, 이따금 900k ~ 1M IOPS로 Burst들이 확인되었습니다. Burst의 지속시간은 0.4 ~ 0.6초이며, 약 20초 주기로 나타났습니다. 정확히는 시간이 지날수록 19초에서 22초로 수렴했는데, 이에 의해 평균 IOPS는 0.2 Drive Written 시점에서 46k IOPS를 기록하다가 1.0 Drive Written 시점에선 41k IOPS, 1.5 Drive Written 시점에서는 39k IOPS까지 하락했습니다. 

 흥미로운 것은 Burst마다 처리되는 데이터의 양인데, 계속해서 1.5 GB로 일정한 값을 보였습니다. 이는 역시 SLC Cache의 영향으로 추측됩니다. 여기서 WD=SanDisk의 nCache 4.0을 간단하게 다뤄봅시다. 나중에 별도의 주제를 다루며 등장시키려고 했는데, 여기서 간단하게 한 번은 등장시킬 필요가 있어 보이네요.

 초기 nCache에서는 작은 Block Size, 특히 4kB 쓰기를 SLC에 모아서 MLC에 내리는 형태였다면, nCache 2.0에서는 Block Size를 가리지 않고 모든 쓰기를 SLC로 통과시켰습니다. 그리고 nCache 3.0에서는 직접 MLC영역에 쓰기가 가능해졌죠. (시기상 TLC이지만, 여기선 Mutli Level Cell이란 의미를 적극적으로 채용하겠습니다.)
 그리고 최신의 nCache 4.0은 Hybrid 형태로, 현대적인 Static + Dynamic SLC Cache 형태를 취하고 있습니다.

 그럼 돌아가서 RND Pre-Conditioning 중인 이 상황을 검토해 봅시다. 지속되는 쓰기가 들어오는 이 상황에서는 Dynamic SLC Cache의 사용이 제한됩니다. 따라서, GC나 Folding을 통해 일부 SLC Cache가 확보되면, 해당 영역에 4k 쓰기를 흡수하는 형태로 보입니다.

그렇다면 SEQ Pre-Conditioning에선 왜 이런 모습을 보이지 않았을까요?

 적당한 크기의 Block Size와 지속적인 SEQ Write, 이건 많은 사람들의 생각과 다르게 생각보다 가벼운 워크로드입니다. WAF도 낮고, GC의 난이도나 FTL의 부담. 그 모든 것이 RND Pre-Conditioning에 비해선 준비운동이나 마찬가지죠.

 궁금증이 풀리셨으면, 이번엔 SN850X 4TB와 비교를 해봅시다. 여기서는 SLC Cache의 Burst는 전혀 보이지 않았죠. 오히려 I/O가 멈추는 증상이 보였습니다. 후자는 DRAM 비율의 문제라고 하더라도, 전자를 설명하기엔 이 근거가 부족하죠.

 결국, SN8100과 SN850X는 둘 다 nCache 4.0을 표방하고 있지만, 내부 동작은 상당히 다르게 구현되었을 가능성이 높다고 봅니다. 개인적으로 이를 SM2508의 특징으로 삼고 싶진 않네요.

RND 4k Performance

 RND Read는 P51 2TB가 약 1700k IOPS까지 확장되며 가장 높은 성능을 보였으며, 다음으로는 SN8100 2TB가 1205k IOPS, PM9E1 1TB는 가장 뒤처지는 957k IOPS를 보였습니다.

 다만, QD2까지는 P51 2TB보다 SN8100 2TB가 살짝 더 우세한 모습입니다.

 RND Write는 P51 2TB가 cSSD치고 실제 eSSD와도 성능 비교가 가능할 정도로 우수합니다. 나머지 둘은 약 40k IOPS에 걸려있는 모습이네요. 정확히는 PM9E1 1TB가 42k IOPS, SN8100 2TB는 40k IOPS 이하의 속도였습니다.

 참고로, SN8100의 쓰기 성능은 Burst가 몇 번 포함되었는지에 따라서 달라집니다. Burst가 우연히 몇 번 더 포함된 QD8의 성능은 40k IOPS로 최고점을 보였고, 나머지는 38 ~ 39k IOPS가 측정되었습니다.

4-Corners Consistency

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

 Read들은 96% 이상으로 안정적이며, SEQ Write도 85% 전후의 Consistency를 보였습니다. 그리고, 예상대로 RND Write가 아주 처참한 32%를 보였습니다.

Specific Workload Performance

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

OCP BootBench

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

 SN8100 2TB가 389k IOPS를 찍으며 PM9E1 1TB 대비 두 배 높은 처리량을 보였습니다. 다만, P51 2TB의 429k IOPS에는 다다르지 못하네요.

SEQ 128k R95:W05

 QD8의 3379 MB/s에서 QD16의 8726 MB/s로의 변화가 가장 컸습니다.

RND 4k R70:W30

 P51 2TB는 QD 증가에 따라 385k IOPS까지 확장되었으나, SN8100 2TB는 116k IOPS에서 포화되어 PM9E1 1TB의 130k IOPS보다 낮았습니다.

 하지만, 50% 지연시간 측면에선 PM9E1 1TB보다 더욱 안정적인 모습도 보였습니다. 

RND 4k R50:W50

 P51 2TB가 246k IOPS까지 확장되며 비교군 모두를 크게 앞섰습니다. SN8100 2TB는 73k IOPS, PM9E1 1TB는 82k IOPS에서 포화되며 지연시간이 급격히 상승했습니다.

RND 512B Read

 SN8100 2TB는 512B 읽기 성능이 4k 읽기 성능보다 소폭 하락하는 모습을 보였습니다. 

Random 4k QD1 Tail Latency

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

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

 RND Read를 IOPS와 50% 지연시간 등으로 확인했을 때는 PM9E1 1TB가 소폭 밀리는 모습이었으나, 99.999%에 가까워질수록 다른 모습을 보였습니다. PM9E1 1TB가 가장 우수했으며, P51 2TB가 가장 밀렸죠.

 그와 다르게, Write 작업이 포함되면 SN8100의 Tail Latency가 굉장히 망가지는 모습도 확인되었습니다. 이는 RND Pre-conditioning을 다룬 내용을 기억해 주시면 좋을 것 같습니다.

Closing

 SN8100은 대표적인 최신 플래그십 cSSD입니다. 대용량의 SLC Cache, 15 GB/s에 가까운 빠른 속도를 가지고 있으며, 이는 경쟁사의 9100 PRO, P51과 크게 다른 점이 없습니다. 특히, SM2508을 적용한 제품은 SN8100 이외에도 상당히 많죠.

 아직 SM2508 솔루션끼리 비교하진 못했지만, PM9E1, P51과 SN8100은 비슷한 수준의 성능을 자랑함과 동시에 세부적으로는 상당히 다른 모습을 보여주었습니다. (PM9E1은 1TB 제품이었지만요 ㅎㅎ;;)
 특히, cSSD가 전혀 고려하고 있지 않던 RND Pre-Conditioning에서는 SN8100이 눈에 상당히 띄었죠. Burst가 반복되는 현상은 전작인 SN850X에 적용된 nCache 4.0과도 살짝 다른 모습이었습니다.

 WD=SanDisk는 여전히 SLC Cache를 너무나도 사랑하는 모습입니다.

 물론, 대용량의 SLC Cache는 일반 소비자 워크로드에서 상당한 성능 향상을 확인할 수 있기에 현대 플래그십 cSSD라면 대부분이 채용하고 있습니다. 하지만, 모든 것은 Trade-off인 법이죠. 대용량 SLC Cache의 대가는 보통 Write Intensive한 작업이나 Tail Latency에서 드러나게 됩니다.

 이런 측면에서 cSSD와 eSSD가 바라는 '고성능'의 초점은 상당히 다르다는 것을 알 수 있죠. 단순하게 모두가 고성능을 지향하는 것은 맞지만, 그를 위한 여러 요소의 최적화는 우선순위가 다릅니다.

 그런 의미로, 저는 SN8100의 몇몇 리뷰를 보고 어이가 없던 것이 P5800X와 비교하는 것이었습니다. 애초에 다른 지향점을 가진 제품인데 말이죠. SN8100은 좋은 SSD입니다. 하지만, SN8100이 실제로 최적화를 노린 부분만 들고 와서 P5800X와 비교하는 것은 잘못되었습니다. 뭐, 실제로도 그런 리뷰 중 벤치마크 데이터를 직접 가져와서 비교하는 것은 없었던 것 같습니다. 

 추후, 제 P5800X 리뷰에서는 이를 포함해 볼까 합니다. 광고와 리뷰는 엄연히 다르니까요.

 다만, 소신껏 발언하자면, 일반적인 소비자 워크로드에서는 P5800X보다는 최신 플래그십 cSSD가 좋은 선택임을 강조하고 싶습니다. 단순히 하드웨어만 파고드는 유저들이 Firmware에 녹아있는 여러 노력을 무시하지 않았으면 하네요. SSD는 하드웨어만으로 완성되는 제품이 아닙니다. 동일한 하드웨어를 가지고도 소프트웨어의 동작에 따라 전혀 다른 SSD가 될 수 있다는 점을 알아주셨으면 합니다.

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

저도 제조사의 샘플을 받아보고 싶긴하네요. 하하