SSD Evo 850 vs UV400
-
- Pokročilý používateľ
- Príspevky: 12262
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: SSD Evo 850 vs UV400
garbage collection, trim, leveling.
SSD pracuje tak ze v zaujme dosiahnutia co najvacsej zivotnosti nezapisuje data vzdy na rovnake miesto, ale snazi sa KAZDU bunku zatazit rovnomerne. Cize ked zapises dvadsatkrat 10GB, nebude SSD pouzivat fyzicky len prvych 10GB buniek, ale pri prvom zapise pouzije 0-10GB bunky, pri druhom zapise pouzije 10-20GB, pri tretom pouzije 20-30GB atd, atd, cize po zapisani a vymazani 20x10GB dat ty budes mat na filesysteme furt pouzitych len 10GB (zapises, vymazes, zapises "na to iste miesto" ktore vidi operacny system ale pritom NIE JE naozaj tym istym fyzickym miestom...), ale SSD uz bude mat zapisanych 200GB v bunkach. A v kazdej bunke len raz, pretoze ked mas kapacitu 250GB, tak si pouzil len 200/250tín teda štyri pätiny vsetkych buniek a kazdu y nich len jeden jediny raz. Keby si zapisoval dalej, samozrejme pouzije bunky 200-250GB.
Tie bunky a ich "rozmiestnenie v kapacite" pisem zlahka zjednodusene, ale uz vidis aky obraz ti malujem.
Pri tomto systeme teda SSDcko pouzije vela buniek, ale kazdu len raz. Obrovsky rozdiel na zivotnost v porovnani s pripadom kedy by pouzilo prvych 10GB buniek dvadsatkrat - vsetky ostatne sa flakaju, prve su namahane jak svina. Prosim ta ani si neskusaj predstavit co by sa s tymi bunkami stalo ked si zoberies ze filesystemy maju svoje alokacne tabulky, indexy a metadata umiestnene na rovnakom mieste (system : NTFS z Windowsu si alokuje nejaku kapacitu pre svoje struktury a furt do nich zapisuje) - takato vec zabije tie konkretne bunky kde by tieto data boli ulozene v priebehu jednej jedinej HODINY. Nezabudnut ze SSD nerozumie filesystemu, nepozna NTFS, ReFS, exxt3, ext4, btrfs, zfs, proste vobec nic, pre neho su to jednicky a nuly a hotovo. Rovnako ako diskove polia, tie nezaujima ziadny filesystem, maju na salame, robia si len svoju robotu a tou je poskytnut spolahlivy storage priestor.
Keby si mal 500GB SSD, tak pri takomto zapise 200GB dat pouzijes len 200/500tín teda ani nie polovicku buniek (40%), zase kazdu jeden jedinykrat. A este ti zostane dalsich 300/500tín teda 60% buniek ktore vobec nic nespravili a neznizili si zivotnost.
Preco takato komplikacia ? No preto lebo 16nm TLC bunky maju asi tak 300 az 500 zapisov zivotnost !!!!!! Plus este plati ze SSDcka nedokazu kvoli adresovaniu "vylucit" jednu pokazenu bunku z pouzivania, ale oni musia zabit bud cely stlpec alebo riadok co vedia adresovat plus tam dochadza este k nejakym internym sialenym rutinam ohladne error correction kodov atd, cize to cele ani nahodou nie je jednoduche.
Si zober ze vyrobcovia garantuju okolo 35-50TB zivotnost pri 256GB kapacite, to mas 50.000GB deleno 256GB = 195 prepisov v kazdej bunke. Jasne, oni vydrzia trosku viac, ale fajront zaverecna.
No a teraz naspak k tomu ze co pomaha nevyuzite miesto vykonu radic ma na SSDcku zapisanu allocation mapu, cize vie ktore bunky su pouzite a ktore su volne. Preto aj operacne systemy robia TRIM pretoze tym oznamuju SSDcku "hele wole tieto data su mrtve, nepotrebujeme ich pretoze uzivatel vymazal subor alebo cokolvek". Na zaklade tohoto SSD vie, ze dane bunky moze oznacit ako nepouzite (fyzicky samozrejme nevymazava ich obsah - preco ? No pretoze zivotnost samozrejme) ale proste v mape ma zapisane ze tie data su nepotrebne. No a teraz ked uz vieme ze SSDcko zapisuje FURT DORADU NA VSETKY BUNKY, uz je jasne ze cim viac z nich nechame volnych, tym lepsie sa da robit interne upratovanie.
SSD sice nevie ze mas particiu mensiu ako je celkova kapacita, ale uplne perfektne mu vychadza jeho interne upratovanie. Ked mas sestprudovu dialnicu a nejaky pocet aut, jazdi sa ti na nej ukrutne lepsie ako ked budes mat uplne presne ten isty pocet aut na trojprudovej dialnici. Vobec nemusis vediet ake su to auta, to nie je dolezite. A to je tajomstvo uspechu preco sa PRUDKO zvysi vykon a preco sa zaroven aj prudko USTABILIZUJE ked nevyuzijes nejaku cast celkovej kapacity SSD. Co sa tyka tej stabilizacie, 850Pro je krasne vyrovnane ale kukni si na tom istom grafe konkurencne modely a uvidis ze skackaju ako postrelena srnka. Nasadenie takych SSDciek do akehokolvek diskoveho pola je prakticky nemozne a to uz zase odbieham do drahsich sfer.
SSD pracuje tak ze v zaujme dosiahnutia co najvacsej zivotnosti nezapisuje data vzdy na rovnake miesto, ale snazi sa KAZDU bunku zatazit rovnomerne. Cize ked zapises dvadsatkrat 10GB, nebude SSD pouzivat fyzicky len prvych 10GB buniek, ale pri prvom zapise pouzije 0-10GB bunky, pri druhom zapise pouzije 10-20GB, pri tretom pouzije 20-30GB atd, atd, cize po zapisani a vymazani 20x10GB dat ty budes mat na filesysteme furt pouzitych len 10GB (zapises, vymazes, zapises "na to iste miesto" ktore vidi operacny system ale pritom NIE JE naozaj tym istym fyzickym miestom...), ale SSD uz bude mat zapisanych 200GB v bunkach. A v kazdej bunke len raz, pretoze ked mas kapacitu 250GB, tak si pouzil len 200/250tín teda štyri pätiny vsetkych buniek a kazdu y nich len jeden jediny raz. Keby si zapisoval dalej, samozrejme pouzije bunky 200-250GB.
Tie bunky a ich "rozmiestnenie v kapacite" pisem zlahka zjednodusene, ale uz vidis aky obraz ti malujem.
Pri tomto systeme teda SSDcko pouzije vela buniek, ale kazdu len raz. Obrovsky rozdiel na zivotnost v porovnani s pripadom kedy by pouzilo prvych 10GB buniek dvadsatkrat - vsetky ostatne sa flakaju, prve su namahane jak svina. Prosim ta ani si neskusaj predstavit co by sa s tymi bunkami stalo ked si zoberies ze filesystemy maju svoje alokacne tabulky, indexy a metadata umiestnene na rovnakom mieste (system : NTFS z Windowsu si alokuje nejaku kapacitu pre svoje struktury a furt do nich zapisuje) - takato vec zabije tie konkretne bunky kde by tieto data boli ulozene v priebehu jednej jedinej HODINY. Nezabudnut ze SSD nerozumie filesystemu, nepozna NTFS, ReFS, exxt3, ext4, btrfs, zfs, proste vobec nic, pre neho su to jednicky a nuly a hotovo. Rovnako ako diskove polia, tie nezaujima ziadny filesystem, maju na salame, robia si len svoju robotu a tou je poskytnut spolahlivy storage priestor.
Keby si mal 500GB SSD, tak pri takomto zapise 200GB dat pouzijes len 200/500tín teda ani nie polovicku buniek (40%), zase kazdu jeden jedinykrat. A este ti zostane dalsich 300/500tín teda 60% buniek ktore vobec nic nespravili a neznizili si zivotnost.
Preco takato komplikacia ? No preto lebo 16nm TLC bunky maju asi tak 300 az 500 zapisov zivotnost !!!!!! Plus este plati ze SSDcka nedokazu kvoli adresovaniu "vylucit" jednu pokazenu bunku z pouzivania, ale oni musia zabit bud cely stlpec alebo riadok co vedia adresovat plus tam dochadza este k nejakym internym sialenym rutinam ohladne error correction kodov atd, cize to cele ani nahodou nie je jednoduche.
Si zober ze vyrobcovia garantuju okolo 35-50TB zivotnost pri 256GB kapacite, to mas 50.000GB deleno 256GB = 195 prepisov v kazdej bunke. Jasne, oni vydrzia trosku viac, ale fajront zaverecna.
No a teraz naspak k tomu ze co pomaha nevyuzite miesto vykonu radic ma na SSDcku zapisanu allocation mapu, cize vie ktore bunky su pouzite a ktore su volne. Preto aj operacne systemy robia TRIM pretoze tym oznamuju SSDcku "hele wole tieto data su mrtve, nepotrebujeme ich pretoze uzivatel vymazal subor alebo cokolvek". Na zaklade tohoto SSD vie, ze dane bunky moze oznacit ako nepouzite (fyzicky samozrejme nevymazava ich obsah - preco ? No pretoze zivotnost samozrejme) ale proste v mape ma zapisane ze tie data su nepotrebne. No a teraz ked uz vieme ze SSDcko zapisuje FURT DORADU NA VSETKY BUNKY, uz je jasne ze cim viac z nich nechame volnych, tym lepsie sa da robit interne upratovanie.
SSD sice nevie ze mas particiu mensiu ako je celkova kapacita, ale uplne perfektne mu vychadza jeho interne upratovanie. Ked mas sestprudovu dialnicu a nejaky pocet aut, jazdi sa ti na nej ukrutne lepsie ako ked budes mat uplne presne ten isty pocet aut na trojprudovej dialnici. Vobec nemusis vediet ake su to auta, to nie je dolezite. A to je tajomstvo uspechu preco sa PRUDKO zvysi vykon a preco sa zaroven aj prudko USTABILIZUJE ked nevyuzijes nejaku cast celkovej kapacity SSD. Co sa tyka tej stabilizacie, 850Pro je krasne vyrovnane ale kukni si na tom istom grafe konkurencne modely a uvidis ze skackaju ako postrelena srnka. Nasadenie takych SSDciek do akehokolvek diskoveho pola je prakticky nemozne a to uz zase odbieham do drahsich sfer.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
-
- Pokročilý používateľ
- Príspevky: 12262
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: SSD Evo 850 vs UV400
poznamka : radic vzdy zapisuje na vsetky cipy teda NAND cipy ktore ma k dispozicii.
Tam je vzdy obmedzena priepustnost, nedavno bola 800Mbit/s na jedno puzdro co je sialene malo. Rozdiel vo vykone je sposobeny internymi garbage collection mechanizmami, rozhodne nie tym ze radic moze zapisovat na viacere cipy.
Tam je vzdy obmedzena priepustnost, nedavno bola 800Mbit/s na jedno puzdro co je sialene malo. Rozdiel vo vykone je sposobeny internymi garbage collection mechanizmami, rozhodne nie tym ze radic moze zapisovat na viacere cipy.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
- pipo137
- Pokročilý používateľ
- Príspevky: 6417
- Dátum registrácie: Ut 08. Feb, 2011, 17:28
- Bydlisko: Bratislava - Petržalka
Re: SSD Evo 850 vs UV400
mp3turbo: priblizne asi chapem to tvoje dlhsie vysvetlenie, tak len aby som si to zhrnul... SSD naformatovat na mensiu kapacitu ako ma (kolko percent tak odporucas, nech to neni velka strata na kapacite, ale zas nech to ma aj nejaky efekt??). A overprovisioning v systeme potom mozem uplne vypnut, alebo aj tam nejake % nechat (chapem to tak, ze toto uz potom neni potrebne) ??
DESKTOP MB: MSI B450 Gaming Pro Carbon AC CPU: AMD Ryzen 5 5600 + Nocua NH-D14 Black RAM: Patriot Viper Steel 2x8GB @ 3600MHz 14-16-16-16-36 1T GPU: Sapphire NITRO+ Radeon RX580 8GB @ 1500/8900MHz SSD: Samsung 970 EVO 500GB + Crucial M4 256GB PSU: EVGA SuperNOVA G2 750W Sound card: Asus Xonar Essence STX Case: Projekt "R4R" - Fractal Design Define R4 Monitor: Dell U2415 OS: Windows 10 Pro 64bit SK Mouse: Cyborg R.A.T. 7 Mouse Pad: A4tech Bloody B-081 Keyboard: Microsoft SideWinder X4
DESKTOP 2 MB: MSI Z77 MPOWER CPU: Intel Core i7 3770K @ 4,0GHz + IHS mod + Noctua NH-D15 RAM: Crucial Ballistix Tactical LP 2x8GB @ 2000MHz 9-9-9-27 1T GPU: Intel HD4000 SSD: Samsung 850 EVO 500GB HDD: 5x WD Red (20TB)
Smartphone: Redmi Note 13 Pro 5G, Xiaomi Mi Mix 2, Xiaomi MiNote Pro
DESKTOP 2 MB: MSI Z77 MPOWER CPU: Intel Core i7 3770K @ 4,0GHz + IHS mod + Noctua NH-D15 RAM: Crucial Ballistix Tactical LP 2x8GB @ 2000MHz 9-9-9-27 1T GPU: Intel HD4000 SSD: Samsung 850 EVO 500GB HDD: 5x WD Red (20TB)
Smartphone: Redmi Note 13 Pro 5G, Xiaomi Mi Mix 2, Xiaomi MiNote Pro
-
- Pokročilý používateľ
- Príspevky: 12262
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: SSD Evo 850 vs UV400
ked uz to niekto chce robit, vidim to takto :
120/128GB SSDcka tlacit na 110GB, pre tych odvaznejsich na 100GB
250/256GB SSDcka tlacit na 230GB, pre tych odvaznejsich na 215GB (v grafoch Ananda je 206GB)
500/512GB SSDcka tlacit na 470GB, pre tych odvaznejsich na 450GB (v grafoch Ananda je 412GB ale to mi pride uz fakt citelny ubytok miesta)
V linkovanych grafoch u Ananda je 12.5% a 25% overprovisioning. Aj ked vykon je fenomenalny a zivotnost urcite tiez, uz by som urcite skripal zubami keby mi z 512GB SSDcka bolo pouzitelnych len 412GB, to je psychologicky prilis vela. Uz 12.5% zahodeneho fleku prinesie viac ako zdvojnasobenie [!!!] dlhodobo udrzatelneho vykonu pre zapis, cim sa samozrejme ukazuje ze SSD lahsie dycha. Poznamka : v tychto veciach neplati ze sa meni len vykon na zapis, samozrejme ked SSD maka na plne pecky ze nevie zapisovat tak rychlo ako by mohlo, tak nema ani internu architekturu na udrzanie plneho vykonu citania resp. kombinovaneho read/write mixu. To je proste nalozit dvojtonovy naves za Fabiu 1.2, ano pojde to ale...
Nema vyznam robit overprovisioning aj v utilite od vyrobcu aj s mensou particiou, je to prakticky to iste. Cize bud alebo. Ked sa overprovisioning spravi v nastrojoch od vyrobcu, v operacnom systeme aj BIOSe uz priamo uvidis mensiu kapacitu cize namiesto 500GB SSD tam budes mat cojaviem 460GB. Ked to spravis v operacnom systeme, uvidis celu kapacitu cize 512GB, ale vytvoris rucne partition o velkosti 460GB a uvidis tam dalsich 51GB volnych uplne nepouzitych.
Da sa to spravit samozrejme obidvomi sposobmi naraz, ale to uz je zlahka pitomost a urcite na vseobecne domace pouzitie. Samozrejme tie cisla ktore pisem nie su vytesane do kamena, vzdy je lepsie spravit nieco (aj ked nechas len 10GB alebo 15GB ladom) ako nespravit nic a ta strata zase nie je az taka hrozna.
120/128GB SSDcka tlacit na 110GB, pre tych odvaznejsich na 100GB
250/256GB SSDcka tlacit na 230GB, pre tych odvaznejsich na 215GB (v grafoch Ananda je 206GB)
500/512GB SSDcka tlacit na 470GB, pre tych odvaznejsich na 450GB (v grafoch Ananda je 412GB ale to mi pride uz fakt citelny ubytok miesta)
V linkovanych grafoch u Ananda je 12.5% a 25% overprovisioning. Aj ked vykon je fenomenalny a zivotnost urcite tiez, uz by som urcite skripal zubami keby mi z 512GB SSDcka bolo pouzitelnych len 412GB, to je psychologicky prilis vela. Uz 12.5% zahodeneho fleku prinesie viac ako zdvojnasobenie [!!!] dlhodobo udrzatelneho vykonu pre zapis, cim sa samozrejme ukazuje ze SSD lahsie dycha. Poznamka : v tychto veciach neplati ze sa meni len vykon na zapis, samozrejme ked SSD maka na plne pecky ze nevie zapisovat tak rychlo ako by mohlo, tak nema ani internu architekturu na udrzanie plneho vykonu citania resp. kombinovaneho read/write mixu. To je proste nalozit dvojtonovy naves za Fabiu 1.2, ano pojde to ale...
Nema vyznam robit overprovisioning aj v utilite od vyrobcu aj s mensou particiou, je to prakticky to iste. Cize bud alebo. Ked sa overprovisioning spravi v nastrojoch od vyrobcu, v operacnom systeme aj BIOSe uz priamo uvidis mensiu kapacitu cize namiesto 500GB SSD tam budes mat cojaviem 460GB. Ked to spravis v operacnom systeme, uvidis celu kapacitu cize 512GB, ale vytvoris rucne partition o velkosti 460GB a uvidis tam dalsich 51GB volnych uplne nepouzitych.
Da sa to spravit samozrejme obidvomi sposobmi naraz, ale to uz je zlahka pitomost a urcite na vseobecne domace pouzitie. Samozrejme tie cisla ktore pisem nie su vytesane do kamena, vzdy je lepsie spravit nieco (aj ked nechas len 10GB alebo 15GB ladom) ako nespravit nic a ta strata zase nie je az taka hrozna.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
- MaxPayne
- Používateľ
- Príspevky: 1807
- Dátum registrácie: Št 09. Júl, 2009, 23:14
- Bydlisko: Zlaté Moravce
Re: SSD Evo 850 vs UV400
Ja som to spravil v tom programe od samsungu,automaticky je tam 10% z 250gb ukazuje 206gb a z 500gb ukazuje 412gb tusim,niesom teraz doma ale cca take hodnoty su tam,pre mna je to v pohode ,mam to malo zaplnene aj tak
Spoiler: ukázať
- lepermessiah
- Sponzor fóra gold
- Príspevky: 2796
- Dátum registrácie: Št 30. Dec, 2010, 02:41
- Bydlisko: ZV
Re: SSD Evo 850 vs UV400
Ja mam 30% (ale tak z toho 1TB to vela nevyuzivam, len ked som ho kupoval, este nestihol prist domov ked som kupil 1.5TB HDD, takze namiesto povodnej myslienky nahradit len 160GB HDD som sa ulakomil na 1.5TB HDD a SSD zaujalo miesto 3G/GPS modulu, ktory mi netreba ..)
..ale 30% som spravil omylom, chcel som 15% a nejako som sa preklikol a vsimol som si to az po naformatovani a zapnuti bitlockera
..ale 30% som spravil omylom, chcel som 15% a nejako som sa preklikol a vsimol som si to az po naformatovani a zapnuti bitlockera
Spoiler: ukázať
-
- Pokročilý používateľ
- Príspevky: 12262
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: SSD Evo 850 vs UV400
>> Ja som to spravil v tom programe od samsungu,automaticky je tam 10% z 250gb ukazuje 206gb a z 500gb ukazuje 412gb tusim
to uz je aka matematika
to uz je aka matematika
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
- shiro
- Pokročilý používateľ
- Príspevky: 8736
- Dátum registrácie: Št 21. Dec, 2006, 02:00
- Bydlisko: Banska Bystrica
Re: SSD Evo 850 vs UV400
mp3turbo -> heh, stale nechapem. vazne.
to co si popisal je mechanizmus TRIMu a GC.
Nikde nevidim dovod ze preco sa po odkrojeni urciteho miesta na overprovisioning zvysi IOPS. Ved IOPS su I/O operacie za sekundu, kazde zariadenie ich ma nejaky pocet co dokaze zvladnut. Cize hocijaky zapis, citanie, kopirovanie a co ja viem co, coho su tie cipy vnutri schopne....
Zivotnost SSD to zvysi, lebo SSD dostane nahradne bunky navyse, ktore moze realokovat v ramci TRIMU ci GC. No stale ich ma fixny pocet na cele SSD, stale je tam rovnaky radic a rovnake cipy v tom SSD...akurat zmenim velkost miesta na overprovisioning.
Logicky mi z toho vychadza, ze IOPS by mali byt rovnake ci z SSD neurezem nic, alebo 15GB miesta na overprovisioning. Tie IOPS budu bezat len na zmensenej particii, nevidim nic co by malo sposobit ich narast. Ze ma SSD viac miesta na overprovisioning by som pokladal praveze za dovod k znizeniu IOPS, pretoze ma SSD viac miesta na premapovavanie buniek. Potom jednak mam menej GB na uzivanie za cenu vacsej zivotnosti, ale zaroven mi tam SSD upratuje viac buniek lebo ma viac vyhrad. miesta na to. Cize pouziva viac IOPS, ktore by som mohol vyuzit pre pracu s normalnymi datami pri pouzivani.
Co teda sposobi narast IOPS? Co sposobi, ze som zrazu schopny nacitat alebo ulozit napr. 20000 stvorkilobajtovych kuskov dat namiesto doterajsich 8500?
Kedze, ako tu bolo povedane, sa zapisuje do vsetkych cipov v SSD naraz, tak logicky len pretaktovanim radica SSD, aby to tam hadzal rychlejsie
to co si popisal je mechanizmus TRIMu a GC.
Nikde nevidim dovod ze preco sa po odkrojeni urciteho miesta na overprovisioning zvysi IOPS. Ved IOPS su I/O operacie za sekundu, kazde zariadenie ich ma nejaky pocet co dokaze zvladnut. Cize hocijaky zapis, citanie, kopirovanie a co ja viem co, coho su tie cipy vnutri schopne....
Zivotnost SSD to zvysi, lebo SSD dostane nahradne bunky navyse, ktore moze realokovat v ramci TRIMU ci GC. No stale ich ma fixny pocet na cele SSD, stale je tam rovnaky radic a rovnake cipy v tom SSD...akurat zmenim velkost miesta na overprovisioning.
Logicky mi z toho vychadza, ze IOPS by mali byt rovnake ci z SSD neurezem nic, alebo 15GB miesta na overprovisioning. Tie IOPS budu bezat len na zmensenej particii, nevidim nic co by malo sposobit ich narast. Ze ma SSD viac miesta na overprovisioning by som pokladal praveze za dovod k znizeniu IOPS, pretoze ma SSD viac miesta na premapovavanie buniek. Potom jednak mam menej GB na uzivanie za cenu vacsej zivotnosti, ale zaroven mi tam SSD upratuje viac buniek lebo ma viac vyhrad. miesta na to. Cize pouziva viac IOPS, ktore by som mohol vyuzit pre pracu s normalnymi datami pri pouzivani.
Co teda sposobi narast IOPS? Co sposobi, ze som zrazu schopny nacitat alebo ulozit napr. 20000 stvorkilobajtovych kuskov dat namiesto doterajsich 8500?
Kedze, ako tu bolo povedane, sa zapisuje do vsetkych cipov v SSD naraz, tak logicky len pretaktovanim radica SSD, aby to tam hadzal rychlejsie
Ryzen 7 3700X | SilentiumPC Fera 3 | Asrock X570M Pro4 | Patriot Viper 4 Blackout 16GB DDR4-3600 CL17 | Gainward RTX4060 Ti Pegasus 8GB | Samsung 970evo Plus 250GB NVMe | Corsair MP510 1TB NVMe | Samsung 980 Pro 2TB NVMe | Corsair RM550x | 32" Samsung ViewFinity S60UA | 3x Noctua NF-S12B redux 1200 PWM
Xiaomi Mi 9 Lite 64GB
Xiaomi Mi 9 Lite 64GB
-
- Pokročilý používateľ
- Príspevky: 12262
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: SSD Evo 850 vs UV400
tvoja logika je uplne spravna, az na to ze je kompletne zla. TRIM/GC funguju tak ako funguju a jednoznacne vidis ze im overprovisioning - ci uz priamo firemnymi nastrojmi alebo rucnym vytvorenim mensej particie - sialene prospieva.
IOPS sa zvysi preto lebo GC proste funguje ucinnejsie. SSD ma VNUTORNE k dispozicii vzdy nejaky rovnaky vykon, to mas pravdu, avsak kolko z toho vykonu polozis von cez SATA interface je uz uplne ina problematika. Spravaju sa tak uplne vsetky SSDcka, nie je to specifikum nejakeho vyrobcu alebo radica alebo niecoho ineho.
IOPS sa zvysi preto lebo GC proste funguje ucinnejsie. SSD ma VNUTORNE k dispozicii vzdy nejaky rovnaky vykon, to mas pravdu, avsak kolko z toho vykonu polozis von cez SATA interface je uz uplne ina problematika. Spravaju sa tak uplne vsetky SSDcka, nie je to specifikum nejakeho vyrobcu alebo radica alebo niecoho ineho.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
- shiro
- Pokročilý používateľ
- Príspevky: 8736
- Dátum registrácie: Št 21. Dec, 2006, 02:00
- Bydlisko: Banska Bystrica
Re: SSD Evo 850 vs UV400
Neviem skade sa tam tie IOPS navyse zrazu zoberu. Ak tam dakde su, tak musia byt na nieco spotrebovane, kedze niesu dostupne uzivatelovi, ziaden test ich nezmera. Aby ich uzivatel mohol vyuzit, tak je treba to "nieco, co ich spotrebuva" vypnut ci obist.
Ako pises, IOPS sa zvysi, lebo GC funguje ucinnejsie. Mam to chapat tak, ze SSD sa na nejaky cas vykasle oznacovat ci premazavat bunky kde nejake data uz boli (ako sa to deje pri GC) a rovno zapisuje do buniek vyhradenych pre overprovisioning? A ked je neskor na to cas, SSD sa k tymto bunkam vrati a porobi potrebne veci neskor. Cize by odpadlo nejake oznacovanie buniek na vymazanie a ich nasledne vymazavanie pred zapisom. Ale rovno sa zapisuje do buniek kde este nic nebolo, netreba nic oznacovat a mazat = ziskaju sa nejake IOPS. To je ono?
Toto je asi jedna vec kde ma napada ze by sa nejake IOPS dali usetrit.
Ako pises, IOPS sa zvysi, lebo GC funguje ucinnejsie. Mam to chapat tak, ze SSD sa na nejaky cas vykasle oznacovat ci premazavat bunky kde nejake data uz boli (ako sa to deje pri GC) a rovno zapisuje do buniek vyhradenych pre overprovisioning? A ked je neskor na to cas, SSD sa k tymto bunkam vrati a porobi potrebne veci neskor. Cize by odpadlo nejake oznacovanie buniek na vymazanie a ich nasledne vymazavanie pred zapisom. Ale rovno sa zapisuje do buniek kde este nic nebolo, netreba nic oznacovat a mazat = ziskaju sa nejake IOPS. To je ono?
Toto je asi jedna vec kde ma napada ze by sa nejake IOPS dali usetrit.
Ryzen 7 3700X | SilentiumPC Fera 3 | Asrock X570M Pro4 | Patriot Viper 4 Blackout 16GB DDR4-3600 CL17 | Gainward RTX4060 Ti Pegasus 8GB | Samsung 970evo Plus 250GB NVMe | Corsair MP510 1TB NVMe | Samsung 980 Pro 2TB NVMe | Corsair RM550x | 32" Samsung ViewFinity S60UA | 3x Noctua NF-S12B redux 1200 PWM
Xiaomi Mi 9 Lite 64GB
Xiaomi Mi 9 Lite 64GB
-
- Pokročilý používateľ
- Príspevky: 12262
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: SSD Evo 850 vs UV400
tak nejak. Ak vies ako pracuje suborovy system ZFS alebo nejake diskove polia (napriklad od HPcka 3Par) s copy-on-write mechanizmom, tak si predstav ze by existovala nejaka interna defragmentacia pre ZFS. Je to samozrejme ine ako vnutorne pracovanie SSDciek, ale proste z nadhladu. Ked sa urobi overprovisioning fabrickym softom tak SSD absolutne jednoznacne vie, ze z celkovej kapacity XYZ dostava uzivatel len ABC a ostatne moze vyuzivat pre svoju optimalizaciu. Preto je tato metoda silno preferovana.
Teraz si isiel na to spravne. Vnutorne upratovanie musi prebiehat a ked je viac efektivne - a je nepodstatne z akeho dovodu - uzivatel dostava viac vykonu az do nejakeho skutocneho maxima co SSD je schopne dosiahnut. Ako som pisal, velmi drahe enterprise SSDcka sa od Alzovych lisia predovsetkym aj v tom kolko je overprovisioning uz direkt z fabriky a pod tuto hranicu sa neda ist (cize nemozes si nastavit ze z 2TB Intelu na ktorom vidis 1600GB chces spravit 1800GB, to proste nejde, nad 1600GB ta nepusti). Je to jeden z asi styroch alebo piatich klucovych faktorov ktore urcuju DLHODOBE spravanie : stabilitu a vyrovnanost vykonu v priebehu casu, zivotnost atd ako sme sa bavili.
Pre domace pouzitie a'la http://www.najlepsie.porno.com, spustenie Call of Duty alebo pisanie tridsatstranovej maturitnej prace vo Worde je to uplne nepodstatne. Pre Photoshop kde pracujes s mnohostoMB fajlikmi je to uz dost dolezite a ten rozdiel je cititelny bez akehokolvek merania, no a pre narocnejsie nasadenia a'la databazove servery, OLTP, OLAP, vyvojari, caste kompilovanie jadra linuxu a aplikacii a podobne to je uz podla mojho nazoru absolutne kriticke. Dovodom je to ze "vyhodene peniaze" v podobe nevyuziteho miesta su radovo desiatky eur, maximalne nejake stovky - ked si kupis zopar 1TB Samsung 850Pro diskov a zahodis 25% priestoru, sice to nie je najefektivnejsia vec o ktorej som v zivote pocul, avsak mas ukrutne vyssi vykon ako si videl co v takomto nasadeni znamena produktivitu co znamena... usetreny cas a tympadom prachy. To co vyhodis von z okna "nepouzitim" za prvy a druhy mesiac najneskorsie ziskas na produktivite a potom uz priamo zarabas kedze ti veci bezia rychlejsie a mozes spravit viac. O predlzenej zivotnosti a dalsich bocnych efektoch nehovoriac.
Teraz si isiel na to spravne. Vnutorne upratovanie musi prebiehat a ked je viac efektivne - a je nepodstatne z akeho dovodu - uzivatel dostava viac vykonu az do nejakeho skutocneho maxima co SSD je schopne dosiahnut. Ako som pisal, velmi drahe enterprise SSDcka sa od Alzovych lisia predovsetkym aj v tom kolko je overprovisioning uz direkt z fabriky a pod tuto hranicu sa neda ist (cize nemozes si nastavit ze z 2TB Intelu na ktorom vidis 1600GB chces spravit 1800GB, to proste nejde, nad 1600GB ta nepusti). Je to jeden z asi styroch alebo piatich klucovych faktorov ktore urcuju DLHODOBE spravanie : stabilitu a vyrovnanost vykonu v priebehu casu, zivotnost atd ako sme sa bavili.
Pre domace pouzitie a'la http://www.najlepsie.porno.com, spustenie Call of Duty alebo pisanie tridsatstranovej maturitnej prace vo Worde je to uplne nepodstatne. Pre Photoshop kde pracujes s mnohostoMB fajlikmi je to uz dost dolezite a ten rozdiel je cititelny bez akehokolvek merania, no a pre narocnejsie nasadenia a'la databazove servery, OLTP, OLAP, vyvojari, caste kompilovanie jadra linuxu a aplikacii a podobne to je uz podla mojho nazoru absolutne kriticke. Dovodom je to ze "vyhodene peniaze" v podobe nevyuziteho miesta su radovo desiatky eur, maximalne nejake stovky - ked si kupis zopar 1TB Samsung 850Pro diskov a zahodis 25% priestoru, sice to nie je najefektivnejsia vec o ktorej som v zivote pocul, avsak mas ukrutne vyssi vykon ako si videl co v takomto nasadeni znamena produktivitu co znamena... usetreny cas a tympadom prachy. To co vyhodis von z okna "nepouzitim" za prvy a druhy mesiac najneskorsie ziskas na produktivite a potom uz priamo zarabas kedze ti veci bezia rychlejsie a mozes spravit viac. O predlzenej zivotnosti a dalsich bocnych efektoch nehovoriac.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
- shiro
- Pokročilý používateľ
- Príspevky: 8736
- Dátum registrácie: Št 21. Dec, 2006, 02:00
- Bydlisko: Banska Bystrica
Re: SSD Evo 850 vs UV400
aha, no uz mi to dava zmysel teraz
Ryzen 7 3700X | SilentiumPC Fera 3 | Asrock X570M Pro4 | Patriot Viper 4 Blackout 16GB DDR4-3600 CL17 | Gainward RTX4060 Ti Pegasus 8GB | Samsung 970evo Plus 250GB NVMe | Corsair MP510 1TB NVMe | Samsung 980 Pro 2TB NVMe | Corsair RM550x | 32" Samsung ViewFinity S60UA | 3x Noctua NF-S12B redux 1200 PWM
Xiaomi Mi 9 Lite 64GB
Xiaomi Mi 9 Lite 64GB