Proverite Write Amplification Factor na vasem SSD-u

[hedgehog]

Za one koji ne znaju, vise o tome sta je Write Amplification Factor (WAF) mozete procitati ovde.
Ukratko, neke od stvari koje su bitne za ostvarivanje sto manjeg WAF-a:
-pravilno funkcionisanje TRIM komande i garbage collection
-ispravan Drive alignment
-velicina fajlova koja se upisuje na SSD
-veci prostor izdvojen za over-provisioning

Takodje treba pomenuti i SSD-ove sa Sandforce kontrolerom koji su radili kompresiju fajlova "on fly", tj. prilikom upisa, sto je rezultovalo sa WAF cak i ispod 0.5, ali pritom je imalo kao posledicu spor upis nekompresibilih fajlova i donekle ugrozavalo sigurnost podataka. Takodje kod velikog broja Sandforce SSD-ova TRIM/garbage collection nije bas najbolje funkcionisao.
Odredjena istrazivanja korisnika pokazala su da je kod Samsung 840 EVO SSD-ova moguc WAF manji od 1, sto je najverovatnije rezultat SLC kesiranja, jer se isto spominje prilikom testa SanDisk Ultra II.

he improved performance is not the only benefit of nCache 2.0. Because everything gets written to the SLC portion first, the data can then be written sequentially to TLC. That minimizes write amplification on the TLC part, which in turn increases endurance because there will be less redundant NAND writes. With sequential writes it is typically possible to achieve write amplification of very close to 1x (i.e. the minimum without compression) and in fact SanDisk claims write amplification of about 0.8x for typical client workloads (for the TLC portion, that is). That is because not all data makes it to the TLC in the first place – some data will be deleted while it is still in the SLC cache and thus will not cause any wear on the TLC. Remember, TLC is generally only good for about 500-1,000 P/E cycles, whereas SLC can easily surpass 30,000 cycles even at 19nm, so utilizing the SLC cache as much as possible is crucial for endurance with TLC at such small lithographies.

Evo kako se racuna WAF kod Crucial SSD-ova

Najjednostavniji nacin je sledeca formula WAF= 1+ID248/ID247 (parametri 247 i 248) sto u ovom slucaju daje 6.72
Takodje vazi i WAF=ID173*256(kapacitet SSD-a)/ID246*512/1024^3

Kod Samsunga to izgleda ovako

Ali za sto tacniji rezultat treba uzeti u obzir deo koji se koristi za SLC kesiranje, a to je kod 120GB modela 128(dostupa prostor+ prostor za over-provisioning)-9 (prostor za kesiranje u SLC modu)=119GB
Tako da imamo
Host Writes = 9099343104 (Total LBA Written) × 512 ÷ (1024^3) = 4338.9 GiB
NAND Writes = 119 GiB × 35 P/E Cycles = 4165 GiB
WAF = 4165 GiB ÷ 4338.9 GiB = 0.959

Slicno vazi i za Kingston, SanDisk i ostale SSD proizvodjace, samo treba naci odgovarajuce SMART parametre.
Uglavnom da vidimo sta kaze praksa kod nas.

 

[hedgehog]

Zaboravio sam da pomenem da se obavezno proveri i napise da li je ok Drive alignment (moze u AS SSD), slobodan prostor na SSD-u i eventalno da li funkcionise TRIM.

1. Open a command prompt window. Run as administrator.
2. Enter this command: fsutil behavior query DisableDeleteNotify
3. If you get DisableDeleteNotify=1, TRIM is not working. If you get DisableDeleteNotify=0, TRIM is running.

Pozeljno je napisati i verziju FW.

 

[gagi75]

aaaa cemu sluzi to ak smem pitati mislim da imam taj samsung


Sent from my iPhone using Tapatalk

 

[hedgehog]

Ukratko se moze reci da je to u principu odnos upisa na NAND flash i stvarne velicine fajlova koji su upisani. Od proizvodjaca tj. SMART vrednosti zavisi kako se WAF racuna (ja sam naveo primer za Crucial i Samsung). Dakle nista specijalno, jedan od indikatora koriscenja SSD-a, koji moze ukazati na neke nedostatke SSD-a, kao npr. los FW ili sam kontroler ili sama izvedba SSD-a ili podesavanja korisnika(los drive alignment, ne funkcionisanje TRIM komande, prepun SSD ...)

Uglavnom Kod EVO SSD-ova je SLC Cache 9GB (tj 3GB u SLC modu) za 120GB i 250 GB modele. Kod 500GB modela je duplo veci.