SSD snelheid > SATA3

[IKON]

Wat ik me toch wel afvraag is waarom overal gezegd wordt dat de SSD's al tegen de max. snelheid van de SATA 3 standaard aanlopen.

Kan iemand mij dat uitleggen? SATA 3 kan 6 GB/s aan, SSD's lezen en schrijven maar met +-500 MB/s....

[ Voor 178% gewijzigd door Verwijderd op 26-05-2014 08:25 . Reden: origineel bericht hersteld ]

[ShitHappens]

Laat het dan even staan, dan weten wij het ook

[christoforius]

SATA 3 = 6Gb/s (niet 6GB/s), 1 byte = 8bits dus SATA 3 kan theoretisch 750MB/s aan.
Sommige nieuwe SSD's halen dit met gemak.

De verbinding tussen chipset en CPU begint in sommige toepassingen al een bottleneck te worden. Daarom zie je op nieuwe X97 bordjes de M.2. en SATA Express aansluitingen opduiken, die hangen aan de PCI-E bus en zitten dus rechtstreeks aan de CPU aangesloten ==> hogere snelheid.

[Verwijderd]

christoforius schreef op maandag 26 mei 2014 @ 07:33:
SATA 3 = 6Gb/s (niet 6GB/s), 1 byte = 8bits dus SATA 3 kan theoretisch 750MB/s aan.

SATA - net als PCI-express 1.0 en 2.0 - gebruikt het 8/10-bit encodingschema. Dit betekent dat je niet door 8 deelt, maar door 10. Dus je kunt de 6 gigabit gewoon delen door 10, zodat je uitkomt op 600MB/s max.

Van deze 600MB/s gaat nog command overhead vanaf en het feit dat je nooit de verbinding 100% optimaal benut. Netto betekent dit iets van 520MB/s maximale bruikbare snelheid in de praktijk.

[ Voor 3% gewijzigd door Verwijderd op 26-05-2014 08:29 ]

[SMSfreakie]

op naar SATA IV dus

[P.K.]

Nee, op naar NVM Express.

[Verwijderd]

Allemaal leuk; maar behoorlijk zinloos. Storage in je computer kent een gradatie. Je begint bij de CPU waarin cachegeheugen zit in meerdere 'lagen' oftewel levels. Level1 cache is bijvoorbeeld 64 kilobyte, maar wel tegen de 100GB/s. De L3 cache is groter maar ook weer een stuk langzamer. Dan komt je RAM geheugen wat vooral qua latency trager is en ook wel qua doorvoer. Pas daarna komt de storage.

Dus:

L1 cache in processor: 64 kilobyte - ultra snel
L3 cache in processor: 4 megabyte - super snel
RAM geheugen: 8 gigabyte - snel
Opslag: 1000+ gigabyte - traag

De opslag is waar we nu over praten; maar juist daar hoef je geen ultra hoge snelheden te hebben. Of je SSD nu 500MB/s doet of 20GB/s maakt eigenlijk niets meer uit. Die snelheden zul je ook nooit halen omdat de processor bottlenecked is en dat heb je al met één SSD.

Dus 'jullie' kunnen wel geilen op 1GB/s+ snelheden voor SSDs, maar ik heb liever 5% meer opslag dan 100% meer performance. Enige leuke van de hogere performance zijn de benchmarks waar je mee kunt pimpen. Wil je extra snelheid; ga dan je CPU en RAM snelheid maar verhogen. Maar inderdaad; dat lukt nauwelijks en ligt al vele jaren op zijn gat. CPUs worden zuiniger maar niet sneller, en bij RAM is het vooral de prijs die fluctueert maar voor de rest eigenlijk niets. DDR4 begint ook al waar DDR3 nu al overheen komt. Kortom, geen innovatie. Daarom kijkt iedereen naar de plek waar er wel innovaties zijn, SSDs, maar juist daar maakt het geen drol uit.

Maar dat geeft niet voor de fabrikanten; zij zien hun consumenten wel happen naar al dat gigabyte geweld.
medium: 8GB/s

[analogworm]

Verwijderd schreef op dinsdag 27 mei 2014 @ 20:59:
...
De opslag is waar we nu over praten; maar juist daar hoef je geen ultra hoge snelheden te hebben. Of je SSD nu 500MB/s doet of 20GB/s maakt eigenlijk niets meer uit. Die snelheden zul je ook nooit halen omdat de processor bottlenecked is en dat heb je al met één SSD.
...

Ach, wat je er mee bereikt is dat de boel sneller in het ram geheugen geladen wordt. Dat kan in sommige scenario's best handig zijn, zoals het laden van project bestanden. Dus om deze vooruitgang tot niets te redeneren klinkt een beetje als vroeger dat we niet meer dan 16MB ram nodig hadden

[Verwijderd]

Het punt is dat zodra je een bottleneck van 40% gaat verkleinen door een factor 1000 sneller te zijn; er ongeveer 0,02% over blijft. Met een oneindig snelle SSD zou je dan enkel die 0,02% sneller kunnen in de praktijk. Dat komt voor bij starten van applicaties, inladen van databestanden, etc. Want: de processor moet ook wat met de data doen. Vaak ook nog single threaded. Een hardeschijf met lage seekperformance zal inderdaad ervoor zorgen dat de processor grotendeels idle is, maar met een SSD is dat niet meer zo. Zolang de processor vol belast wordt; zal een snellere SSD niets uitmaken.

Je kunt het zelf heel gemakkelijk testen:

1) start je computer opnieuw op; dit is nodig om de filecache te resetten
2) start een applicatie, zoals een spel en gebruik en stopwatch hoe lang het laden duurt.
3) sluit het programma af, wacht even en start het daarna opnieuw.

De 2e keer zal het programma zijn data uit RAM-cache lezen en niet meer van SSD (hooguit wat writes). Wat je nu test is het verschil tussen je huidige SSD en de allersnelst mogelijke SSD die met de snelheid van het licht gaat. Want sneller dan je RAM wordt het nooit. Vaak is het verschil tussen van SSD lezen of uit RAMcache lezen maar heel beperkt; veels te klein om merkbaar te zijn hooguit meetbaar. Zoals 8,6 seconden voor SSD en 8,3 seconden uit RAM-cache. In dat geval loopt je processor al op zijn tenen.

Een snellere SSD heeft dus geen zin; richt je energie op goedkoper en betrouwbaarder worden van SSDs of het verbeteren van andere aspecten zoals processor en geheugen. Dat laatste gaat echter in stapjes van een paar procent per jaar; terwijl nu met SSDs een parallellisatie-orgasme wordt uitgevoerd. Een NAND SSD met interleaving kun je zo snel maken als je wilt. Sterker nog; een simpele SSD kan al iets van 3GB/s lezen, maar door de SATA bottleneck wordt dit beperkt tot 500MB/s.

[Verwijderd]

Verwijderd schreef op dinsdag 27 mei 2014 @ 20:59:
De opslag is waar we nu over praten; maar juist daar hoef je geen ultra hoge snelheden te hebben. Of je SSD nu 500MB/s doet of 20GB/s maakt eigenlijk niets meer uit. Die snelheden zul je ook nooit halen omdat de processor bottlenecked is en dat heb je al met één SSD.

Totale onzin.
Ik trek op mijn workstation met gemak 2 GB/s uit mijn SSD array. En dat wordt niet door de cpu begrensd.

Dus 'jullie' kunnen wel geilen op 1GB/s+ snelheden voor SSDs, maar ik heb liever 5% meer opslag dan 100% meer performance. Enige leuke van de hogere performance zijn de benchmarks waar je mee kunt pimpen.

Even je oogkleppen afzetten. Niet iedereen heeft dezelfde eisen. Er zijn best situaties waarbij je in je werk begrensd bent door de bandbreedte van je opslag systeem. En dan is het prettig dat sneller kan, en liefst zonder al te exotische hardware.
Dat er ook tal van situaties zijn waar je door andere dingen begrensd bent, doet daar niets aan af.

Tuurlijk, voor de gemiddelde consument die niet meer doet dan wat internet surfen is sata3 snel zat. Maar dit soort standaarden worden niet alleen voor de gemiddelde consument gemaakt, maar ook voor professionele gebruikers die andere eisen hebben.

[ Voor 10% gewijzigd door Verwijderd op 28-05-2014 11:49 ]

[Verwijderd]

Verwijderd schreef op woensdag 28 mei 2014 @ 11:48:
Totale onzin.
Ik trek op mijn workstation met gemak 2 GB/s uit mijn SSD array. En dat wordt niet door de cpu begrensd.

En wat doe je dan zoal op je workstation?

Heb je het over het draaien van benchmarks, of ook echt nuttige zaken waar je 2GB/s mee haalt?

Want ik ben benieuwd wat dat zou kunnen zijn. Bijna alle taken moet je CPU ook wat voor doen en 2GB/s kan je CPU niet aan. 100MB/s aan dataverwerking komt dichter in de buurt, en ligt vaak nog flink daaronder.

Even je oogkleppen afzetten.

Je kunt ook gewoon normaal je mening geven op dit forum hoor. Is veel gezelliger.

Er zijn best situaties waarbij je in je werk begrensd bent door de bandbreedte van je opslag systeem. En dan is het prettig dat sneller kan, en liefst zonder al te exotische hardware.

Tuurlijk, voor de gemiddelde consument die niet meer doet dan wat internet surfen is sata3 snel zat. Maar dit soort standaarden worden niet alleen voor de gemiddelde consument gemaakt, maar ook voor professionele gebruikers die andere eisen hebben.

Mijn punt is dus dat dergelijke situaties zo extreem zijn dat je er nooit mee te maken zal hebben.

En wat doen 'professionele gebruikers' dan dat zij tijdens hun werk niet tegen CPU-bottlenecks aanlopen en wel tegen 2GB/s datarate van hun SSD gebruik kunnen maken? Lijkt mij gewoon een broodje aap. Als je CPU 10GHz is, dan misschien. Zonder dat zie ik niet in hoe je in de praktijk tot zulke waardes komt. Ook in een professionele omgeving (videobewerking, photoshop, etc).

[analogworm]

Verwijderd schreef op woensdag 28 mei 2014 @ 12:00:
[...]

En wat doe je dan zoal op je workstation?

Heb je het over het draaien van benchmarks, of ook echt nuttige zaken waar je 2GB/s mee haalt?

Want ik ben benieuwd wat dat zou kunnen zijn. Bijna alle taken moet je CPU ook wat voor doen en 2GB/s kan je CPU niet aan. 100MB/s aan dataverwerking komt dichter in de buurt, en ligt vaak nog flink daaronder.

....

Als dat zo is dan zou het hele L1, L2, L3 cache en ram gebeuren nergens goed voor zijn. Immers als je CPU maar 100MB/s kan verwerken, waarom dan zo'n snel cache? Ookal is dat maar enkele MB's.

[tomcool]

Volgens mij hebben jullie beide wel gelijk. Ik kan mij namelijk voorstellen dat je voor het maken/renderen van weermodellen of atoommodellen het best handig kan zijn om snellere SSD's te hebben. Maar daar staat dan wel weer tegenover dat er veel processors moeten zijn die zo'n hoeveelheid data kunnen genereren.
Een voorbeeld:

Je wil een complex atoom renderen en je hebt een cluster tot je beschikking met:
50 processors en 50 GPU's allemaal high end. Dit genereert zoveel data tegelijk dat je een array van 20 SSD's moet hebben.
Dan kan het wel handig zijn om snellere SSD's te hebben zodat je er maar 10 nodig bent.

Maar wat CiPHER bedoelt is dat nu 1 enkele processor niet de benodigde data kan genereren/gebruiken om nu al een SSD helemaal leeg te trekken met 500MB/s.

analogworm schreef op woensdag 28 mei 2014 @ 12:54:
[...]
Als dat zo is dan zou het hele L1, L2, L3 cache en ram gebeuren nergens goed voor zijn. Immers als je CPU maar 100MB/s kan verwerken, waarom dan zo'n snel cache? Ookal is dat maar enkele MB's.

Omdat je sommige essentiële variabelen heel snel wilt kunnen inzien. Zo als bijvoorbeeld de systimer van windows die bepaald welk proces de processor tot zijn beschikking krijgt.
En daarom is het ook niet zo groot. Want je zou het wel heel groot kunnen maken zodat de processor meteen bij alle data kan. Maar dan nog moeten er dezelfde berekeningen mee gedaan worden. En dat versnelt niet

edit: Ik zie het net als met ethernet verkeer. Je kan wel een 100GB/s verbinding hebben tussen de computers. Maar ga maar is alleen maar kleine bestanden sturen. Dan kom je ook nooit aan de 100GB/s. Doordat de ontvangende kant het niet kan bijbenen.

[ Voor 37% gewijzigd door tomcool op 28-05-2014 13:04 ]

[Verwijderd]

Verwijderd schreef op woensdag 28 mei 2014 @ 12:00:
En wat doen 'professionele gebruikers' dan dat zij tijdens hun werk niet tegen CPU-bottlenecks aanlopen en wel tegen 2GB/s datarate van hun SSD gebruik kunnen maken? Lijkt mij gewoon een broodje aap.

De workstation stuurt een nieuw type confocaal microscoop aan. Met twee Hamamatsu Flash 4.0 camera's. Dat zijn 4MP 16bit camera's die 100 fps kunnen doen. Dat levert dus een bandbreedte van 1,6 GB/s op.

Typisch gebruik zal per image stack zo'n 50 tot 100 lagen (=beelden) opnemen om een goede 3D reconstructie te doen, in meerdere kleuren. Om de ontwikkelingen in de cellen in de tijd te kunnen volgen moet je dit dan zovaak herhalen als nodig is. Dat kan een tijd serie van tientallen, maar ook honderden stacks zijn, afhankelijk van de applicatie. Een enkele meting kan derhalve best honderden GB beslaan. Dat vergt dus niet alleen hoge snelheden, maar ook grote opslag.

De cpu belasting van de camera's is minimaal. We doen ook nog wat on-line beeldbewerking, zodat we de meting beter kunnen volgen, waar we dan stevige cpu/gpu last produceren, maar dat is niet strikt noodzakelijk. Mag ook off-line gebeuren.

De kosten van 8x SSD's vallen in het niet t.o.v. van de camera's, microscoop en overige apperatuur.

[Paul]

Verwijderd schreef op woensdag 04 juni 2014 @ 15:22:
De kosten van 8x SSD's vallen in het niet t.o.v. van de camera's, microscoop en overige apperatuur.

Dan noem je ook wel een hele specifieke use case

Bij de typische use cases van de overige 99,99% van de wereld is het een samenspel tussen de componenten. De gemiddelde gebruiker zit helemaal niet de hele dag gigabytes per seconde op te slaan, die zit bewerkingen te doen op de data

Natuurlijk zijn er altijd mensen die de limieten opzoeken, for fun, omdat het kan, omdat ze het nodig hebben, whatever. Zoals het er nu voor staat is SATA3 echter voldoende. Jij trekt je 1.6 GByte ook niet op één SSD, ook niet als die op SAS 3.0 aangesloten was geweest, de SSD is niet snel genoeg.

Er was niemand in de tijd van PATA/33 die een bus ging ontwerpen op 12 GBit, dat had gewoon geen zin want de rest van de keten kon dat niet aan. Datzelfde gebeurd nu, uiteraard is men constant bezig met 'the next best thing' maar pas sinds de SSD in opkomst is worden de limieten van SATA 2 bereikt en overschreden, SATA 2 is al 2x zo snel dan de meeste harde schijven, zelfs bij SATA 1 loop je maar bij een beperkt aantal HDD's tegen limieten aan...

En nu SSD's volwassen(er?) worden zijn er snellere interfaces nodig, helemaal waar, maar dat is vooral omdat men op het gebied van harde schijven zo ontzettend ver achter liep. Tegenwoordig ligt het (voor veruit de meeste use cases) veel beter in balans met de rest van de componenten

[jayvol09]

Sorry voor de resurrect, maar dit is een leuk onderwerp. Ik vond wat Cipher zei heel interessant. Ik ging er altijd vanuit dat CPUs van vandaag veel meer dan 6Gbps data konden doorpompen. Dat blijkt ook uit de post van AHBdV (tenminste 2 GB/s). Ik neem aan dat een ssd benchmark programma nooit last krijgt van een te trage CPU omdat het 'simpele' dingen doet.

Dus wanneer is SATA III (en up) overbodig? Boot een computer met een i5 net zo snel op met een 500MB/s SSD als met een 20GB/s SSD? Welke operaties zijn dusdanig simpel dat een CPU niet een begrensing is? Booten? Bestanden kopieren/installeren? Een word document opslaan? Game opstarten?

Ja in veel (maar niet alle) gevallen is de snelheidwinst zelfs zonder CPU begrensing maar in de orde van tienden van seconden, maar soms is zelfs dat belangrijk. Kennelijk is er een punt waar CPU eerder bottleneckt dan de drive read/write speed. Maar hoe zouden we zo een optimale balans meten/benchmarken?

[johnkeates]

CPU's kunnen prima heel hard data verwerken, tenminste 100Gbit/s over bijv. 100Gb Ethernet verbindingen.
Stel dat je het heel precies wil weten kan je de specs er bij pakken. Bijvoorbeeld:

http://ark.intel.com/prod...r-6M-Cache-up-to-4_00-GHz

Die kan 25.6GB/s doen (Bytes dus, niet bits). Dat is dan wel vannuit DRAM chips en niet via PCIe of een andere bus. Je kan dat met 8 vermenigvuldigen als je bits wil hebben, dan kom je op ruwweg 205Gbits/sec. Behalve als het een 8b/10b encoded bus is, dan is het anders, maar dat kon ik zo snel niet vinden.

Dus, kan je heel hard gaan met de huidige CPU's? Ja.

Volgende item: hoe hard zou je met storage kunnen gaan? Nou, daar kunnen we ook wel e.e.a. over speculeren. Stel wat de de snelste desktop uitbreidingsbus pakken, PCIe 3.0 x16. Die kan maximaal 985MByte per lane doen, waar er dus 16 van zijn: 15760MByte/sec. Dat is ~15.4 Gigabyte per seconde als je het ruwweg berekent, incl. overhead.

Dus, hoe hard zou je met storage kunnen? Ongeveer 15Gbyte/sec. Maar dan moet je wel een x16 3.0 slot gebruiken, en uiteraard controllers en flash chips hebben die dat ook trekken, maar die zijn er ongetwijfeld.

Wat heeft dit met SATA te maken? Weinig. Dat komt om dat SATA overbodig begint te worden. Je hebt het nu op veel apparaten zitten en PCH's etc. zijn er standaard mee voorzien. Maar dat betekent niet dat zo'n bus een briljant plan is met de mogelijkheden van nu. PCI, ISA, AGP enz. waren nou niet bepaald geschikt om voor iets anders dan uitbreidingskaarten te gebruiken. Maar PCIe daarentegen is erg geschikt voor meer dan wat slots op je moederbord. Je kan het al in een draadje krijgen (Thunderbolt) en het zit ook in nieuwe standaarden als M.2 die SATA Express gebruiken waar PCIe dus ook in zit.

Ook op driver en HBA niveau is dit een logische stap: er zijn steeds minder translatie laagjes die de boel ophouden, door rechtstreeks aan de PCIe bus te hangen hoef je niet eerst van PCIe naar controller naar SATA naar SATA client naar client controller naar storage te gaan, maar kan je gewoon PCIe rechtstreeks op de controller gebruiken. Dat is sowieso al 2 stappen minder in de meest ideale situatie, maar vaak genoeg zitten er nog wel meer laagjes in die dus nu ook geëlimineerd kunnen worden.

Een volgende stap die ik me kan voorstellen is dat flash wat directer aanspreekbaar wordt en dat je een wat minder harde FTL tussen je flash en je OS krijgt. De reden dat het er tussen zit is logisch als je het puur als drop-in replacement voor harde schijven ziet, het moet doen alsof het een normaal block device is en ook nog eens real-time van alles regelen om die emulatie te verzorgen naast de vereiste protocol laagjes. Dat is niet iets wat je van een CPU of firmware buiten de SSD om kon verwachten. Op embedded platformen was dat natuurlijk al veel langer gewoon, direct je flash aanspreken, want de software kan het (nouja, zolang je geen Windows draait) en het is goedkoper. Als tussenstap had je nog DOM (disk on module) plakjes die dan weer wat disk-achtiger waren. Maar ook daar zijn laagjes die misschien op den duur kunnen verdwijnen of tenminste dunner kunnen worden.

Wat betreft je vraag om snelheid: er zijn erg veel factoren die meespelen. Puur en alleen transfer speeds doen vrij weinig. IOPS op zich zijn ook niet direct de baas voor een compleet snel systeem. Vroeger kochten mensen harde schijven die sneller draaiden zodat je sneller kon vinden wat je zocht, en met betere interfaces (SCSI anyone?) zodat er meer over de bus kon als je schijf dat ook deed. Het was sneller, dus ging alles sneller. En het idee was dan ook: zo lang je de snelheid omhoog doet gaat alles sneller! En toen kwamen de SSD's. Constante zoektijden van <1ms, een wereld van verschil! Bij het opstarten maakt het namelijk weinig uit hoe snel data heen en weer gepompt wordt, als elke transfer 100ms kost, ongeacht hoe groot, kosten 100000 transfers van 1Kb nog steeds belachelijk veel tijd. Als je bus ATA speeds doet van bijv 133Mb/s, dan gaat die 1Kb met een zoektijd van 100ms niet opeens omlaag. Dat is ook de reden dat bijv. een SSD met ATA/IDE aansluiting (ja, die bestaan) een oude computer zo extreem veel sneller maken: data gaat niet sneller heen en weer, maar de tijd die het kost om de data te vinden en te sturen gaat een stuk korter zijn! Het is een beetje te vergelijken met bandbreedte vs. ping.

Ik hoop dat dat alvast illustreert dat snelheid op zich in de meeste gevallen niet zo extreem veel uitmaakt als je denkt.

Ik zag bijvoorbeeld ook iets langskomen over atoommodellen of weermodellen, en dat snellere SSD's daar vast bij gaan helpen. Dat is ook een typisch ding waar niks van klopt. Grote berekeningen hebben niks aan snelle opslag, die zijn juist afhankelijk van parallellisatie en veel nodes. Het kan zo zijn dat 10 nodes met 1GB RAM en een processor op 1Ghz sneller een grote berekening oplossen dan een machine die 10GB RAM heeft en een CPU op 10Ghz. Dat is ook de reden dat er zo veel geclusterd wordt: je hebt niks aan snelheid als je taken er niet eerder klaar door zijn. Je kan veel beter meer taken tegelijk uitvoeren!

Stel dat je gigantische snelheid zou willen hebben ben je beter af met een Boing 747 vol met blu-rays die 4000 Kilometer vliegt om zo 245,829 Gbit/s te halen.

Uiteindelijk is de snelheid waarmee je dingen doet op de computer afhankelijk van veel meer factoren dan de snelheid van je opslag, RAM, CPU, caches enz. Als software niet 100% optimaal geprogrammeerd is bijvoorbeeld, dan gooi je zo bakken performance weg. Een besturingssysteem draaien is bijvoorbeeld ook helemaal niet efficient als je maar 1 taak wil doen. Of wat dacht je van de snelheid waarmee mensen kunnen typen? Of kunnen opmaken wat er op het scherm gebeurt? Of hoe accuraat ze met de muis zijn?

Eigenlijk zou je eerst veel strikter moeten afbakenen wat de 'snelheid' is die je zoekt. Straks gaat het nog over je werkproces om dat daar de meeste tijd te halen is... en dan hebben we het opeens niet meer over computers Als je wil weten waar een bepaalde taak z'n tijd in steekt zou je eigenlijk eens moeten kijken naar profiling. Dan weet je precies hoe lang alles duurde en waar alles op moest wachten. En meestal is dat niet de opslag

en toen stond er een lap tekst.. zo gaat dat soms als je midden in de nacht het toetsenbord er bij pakt...

[Verwijderd]

jayvol09 schreef op donderdag 23 oktober 2014 @ 03:36:
Sorry voor de resurrect, maar dit is een leuk onderwerp. Ik vond wat Cipher zei heel interessant. Ik ging er altijd vanuit dat CPUs van vandaag veel meer dan 6Gbps data konden doorpompen. Dat blijkt ook uit de post van AHBdV (tenminste 2 GB/s).

Welke post bedoel je precies? Want sequential I/O gaat natuurlijk veel sneller dan random I/O omdat de CPU hierbij veel minder werk heeft. 300MB/s aan sequential I/O is peanuts voor een CPU, maar 300MB/s aan random I/O is dat zeker niet.

Ik neem aan dat een ssd benchmark programma nooit last krijgt van een te trage CPU omdat het 'simpele' dingen doet.

Bij oudere laptop CPUs met energiebesparing kun je al een CPU bottleneck krijgen enkel van de random reads; ook omdat bij Windows de storage backend single threaded is. Maar normaliter is de CPU geen bottleneck bij synthetische storage benchmarks. In de praktijk is dat natuurlijk anders omdat de data die wordt ingelezen, ook moet worden verwerkt door de applicatie. Een compressieprogramma zou bij 1MB/s datarate al de CPU kunnen verzadigen, terwijl andere applicaties minder verwerking nodig hebben en dus ook meer data kunnen verwerken.

Dus wanneer is SATA III (en up) overbodig? Boot een computer met een i5 net zo snel op met een 500MB/s SSD als met een 20GB/s SSD?

Er zal zeker wat verschil zijn, maar omdat bij booten een groot gedeelte non-contiguous I/O is, zal het niet bijster veel verschil uitmaken. Vooral bij een gebruikte installatie en dus niet een superverse installatie waar er relatief meer sequential I/O is. De zogenaamde 'trace' benchmarks die veelal gebruikt worden - ook door Tweakers.net - verhullen dit omdat ze bij een verse installatie de I/O opdrachten capturen en deze vervolgens in maximale snelheid naar de SSD sturen tijdens de benchmark. Dat is zeker synthetisch te noemen, en zal leiden tot grotere performanceverschillen tussen SSDs dan een echte praktijktest zou opleveren.

Maar booten bijvoorbeeld is zeker niet enkel beperkt door de SSD. Er kunnen drivers zijn die simpelweg 'wachten' of de boel blokkeren. Daarom dat men zegt dat bij een nieuwe SSD het booten zoveel sneller gaat. Dat is vooral omdat men vers heeft geïnstalleerd en dan is ook de bootprocedure minder rommelig qua drivers en meuk.

Welke operaties zijn dusdanig simpel dat een CPU niet een begrensing is? Booten? Bestanden kopieren/installeren? Een word document opslaan? Game opstarten?

Game starten denk ik dat je bij SATA/600 wel voordeel hebt. En kopiëren. De rest is vrijwel altijd 99%+ een CPU-bottleneck met een moderne SSD.

johnkeates schreef op donderdag 23 oktober 2014 @ 04:29:
CPU's kunnen prima heel hard data verwerken, tenminste 100Gbit/s over bijv. 100Gb Ethernet verbindingen.

Dat is natuurlijk een héél slecht voorbeeld. Om de volgende redenen:

• Ethernet is super-geoptimaliseerd.
• Ethernet gebruikt offloading-technieken om de CPU te ontlasten, dat is cruciaal voor 10Gbps+ ethernet
• 1Gbps Ethernet kan al een dualcore tot de 100% krijgen; daar is in dit forum ook praktijkervaring mee in de vorm van de 1GHz Dualcore Zacate CPU (AMD Brazos) als ZFS server. Op een geheugenshare (tmpfs) via het netwerk streamen kost je daar beide cores en verzadigd de 1Gbps ethernet niet. En dat is mét offloading (TSO, RXSUM, TXSUM) .
• Je hebt het nu enkel over een datastroom; niet verwerking van die datastroom. Bijvoorbeeld als je files wilt streamen over 100Gbps tegen 100Gbps dan heb je ook overhead van het filesystem en Samba/NFS.

Stel dat je het heel precies wil weten kan je de specs er bij pakken. Bijvoorbeeld:

http://ark.intel.com/prod...r-6M-Cache-up-to-4_00-GHz

Die kan 25.6GB/s doen (Bytes dus, niet bits). Dat is dan wel vannuit DRAM chips en niet via PCIe of een andere bus. Je kan dat met 8 vermenigvuldigen als je bits wil hebben, dan kom je op ruwweg 205Gbits/sec.

Dat kan enkel bereikt worden als de geheugenbus voortdurend belast wordt en geen enkel programma iets met de data doet. Kortom, dit is het theoretische maximum. Je kunt ook naar de L1-cache snelheden kijken in de CPU die liggen nog veel hoger. Maar dit soort informatie is vrij nutteloos als je de performance van een praktijksituatie wilt weten. Allereerst komt het vaak voor dat je dan memory copies moet doen, en knip- en plakwerk. Anderzijds moet er ook wat met de data gedaan worden, en dat is veel intensiever dan enkel data naar de RAM pompen of andersom.

Volgende item: hoe hard zou je met storage kunnen gaan? Nou, daar kunnen we ook wel e.e.a. over speculeren. Stel wat de de snelste desktop uitbreidingsbus pakken, PCIe 3.0 x16. Die kan maximaal 985MByte per lane doen, waar er dus 16 van zijn: 15760MByte/sec. Dat is ~15.4 Gigabyte per seconde als je het ruwweg berekent, incl. overhead.

Dat is enkel overhead van de PCI-express bus zelf, niet van de payload. Zie hier een schema voor efficiencies bij verschillende applicaties:

Een volgende stap die ik me kan voorstellen is dat flash wat directer aanspreekbaar wordt en dat je een wat minder harde FTL tussen je flash en je OS krijgt.

Softwaredrivers voor 'ruw' flash zitten al in BSD en volgens mij Linux. Dan doet de host dus bijna alles, zoals write remapping en dus ook de management van de mapping tables. Het is ook volgens de UNIX filosofie om een opslagapparaat niet te ingewikkeld maken maar de extra intelligentie juist in softwaremodules onder te brengen waarbij elke module een simpele taak verricht. Doordat SSDs kleine computers zijn geworden, zijn er ook zoveel problemen mee geweest in het verleden qua firmwarebugs. En nog steeds; zoals recent de Samsung EVO bug.

De rest maar niet op gereageerd maar kan me in het grootste gedeelte van je verhaal aardig vinden.

[Verwijderd]

In die grafiek zie ik bij storage traffic een efficientie van > 95% staan. Waar zit het probleem nou?

Hoe sneller je storage, hoe sneller je data in en uit je ram kan schrijven. Dat is gewoon nuttig.

In het HDD tijdperk was storage dusdanig langzaam, dat we in tijd kritische applicaties zorgden dat alles vooraf in het ram staat, omdat we anders problemen kregen. Met SSD's heb je de storage access een factor 100 verbeterd, zodat je dat meer dynamisch kan doen. En dat betekent dat je uiteindelijk grotere taken aankan.

Omdat RAM op dit moment ook heel goedkoop is, en iedereen dus ruim voldoende heft om alles vooraf in te laden, zien we dat aspect van SSD's bij de consument nog niet zo naar voren komen... Maar als ze nog in het tijdperk zouden zitten van 10 jaar geleden, waar de swapfile veel gebruikt werd, dan zou je een enorm verschil in prestaties zijn, omdat die swapfile zoveel sneller aangesproken kan worden.

[johnkeates]

Verwijderd schreef op donderdag 23 oktober 2014 @ 10:22:
Maar als ze nog in het tijdperk zouden zitten van 10 jaar geleden, waar de swapfile veel gebruikt werd, dan zou je een enorm verschil in prestaties zijn, omdat die swapfile zoveel sneller aangesproken kan worden.

Ja, maar dat is niet om dat je meer MB per seconde kan trekken, maar om dat de toegangstijd en de zoektijd lager zijn. Een ouderwetse HDD kon prima 80MB/s trekken, maar het duurde gewoon lang voor dat data begon te stromen en als er een gefragmenteerd bestandssyteem tussen zat zorgde dat weer voor extra zoektijd. RAM is ook niet perse zo veel sneller om dat er meer data per keer in en uit kan, maar om dat er extreem lage toegangstijden en zoektijden zijn. Het is niet alsof een programma dat 1 seconde nodig heeft om op te starten dat sneller doet vanaf een RAM module dan een SSD (als we het laden van code in RAM voor dat het uitgevoerd kan worden even buiten beschouwing laten). Als er bijv. 30MB aan code geladen wordt is dat altijd 30MB en alles wat dat in bijv. 100ms kan zal alleen onderling nog verschillen in zoektijd of toegangstijd.

Veel mensen denken dat bandbreedte alles sneller maakt, maar het is in heel veel gevallen de daadwerkelijke snelheid die bepaalt hoe snel iets is. Als je 100MB wil downloaden via internet en je een 1Gbps internetverbinding hebt, dan zou je verwachten dat je dat in 1 sec binnen krijgt. Maar als je dan een latency van 500ms hebt moet je voor alle kleine stukjes overhead die eerst een voor een heen en weer moeten 500ms wachten. Doe dat 10x en je zit 5 seconden te niksen voordat je download überhaupt start.

Hetzelfde geldt voor data transfers enz. Ongeacht hoe dik je bandbreedte wel niet is zal je toch moeten wachten voor de alle commando's om een transfer in gang te zetten over en weer zijn gegaan en de data is gevonden.

[jayvol09]

Ik snap dat bandbreedte niet alles sneller maakt, maar ik vraag mij vooral af wat wél (merkbaar) sneller gaat met meer bandbreedte--zodat ik beter kan afwegen of een SATA-achtige upgrade de moeite waard is t.o.v. CPU/RAM/GPU. Cipher gaf al wat inzichten maar ik probeer een vollediger beeld te krijgen.

Dus alleen meer bandbreedte geeft:
- sneller data -> RAM (bv game laden). Enkel merkbaar bij veel data per keer, want dan word de zoektijd verwaarloosbaar.
- sneller data verplaatsen op de SSD. Copy/paste/delete & mogelijk installeren.

en geeft niet of nauwlijks:
- snellere boot. Want bestaat uit veel kleine transfers, gedomineerd door search/access time.
- snellere opstart van chrome of windows explorer.
- snellere compressie van bestanden. begrenst door CPU (aanname huidige CPU technologie)
- snellere RAM -> storage (bv photoshop, videobewerking). CPU begrenst opslag snelheid omdat het vaak dingen moet doen. Maar waarom hebben videobewerking computers dan zo een behoefte aan snelle harde schijven/raid0?

[Verwijderd]

Videobewerking is nogal een ruim begrip maar gaat meestal gepaard met grote bestanden die baat hebben van een zo groot mogelijke bandbreedte. Je moet ook strorage en Windows apart zien die allebei aparte eisen stellen aan de manier hoe ze data leest of schrijft . Met Windows is het op atomic level waarin ram buffert en een hd in que gaat waardoor vertraging ontstaat, dat is de ssd die de vertraging wegneemt en het ssd gevoel geeft . De bandbreedte is totaal ondergeschikt voor Windows en belangrijk is hoe snel een 4K Read of write word afgehandeld om aan de volgende te beginnen.

Wikipedia: Linearizability

[maratropa]

jayvol09 schreef op dinsdag 28 oktober 2014 @ 16:50:
Maar waarom hebben videobewerking computers dan zo een behoefte aan snelle harde schijven/raid0?

Dat ligt erg aan wat je precies doet. Als je source en target bestanden bestaan uit sterk gecomprimeerde bestanden kan het heel meevallen met hoeveel doorvoor je nodig hebt.

Als je
RAW video (of een niet compressed formaat etc) exporteert kun je af en toe best wat hebben aan 1500+ mb per seconde, want dat kan zo maar voorkomen. Daarmee heeft de cpu het niet zo zwaar.

Vooral als je een beetje complexe timeline hebt met veel sourcemateriaal dan kan er tijdens het renderen behoorlijk wat druk op de opslag staan.

[ Voor 16% gewijzigd door maratropa op 28-10-2014 19:17 ]

[Verwijderd]

johnkeates schreef op zaterdag 25 oktober 2014 @ 05:39:
[...]
Ongeacht hoe dik je bandbreedte wel niet is zal je toch moeten wachten voor de alle commando's om een transfer in gang te zetten over en weer zijn gegaan en de data is gevonden.

Natuurlijk is de effectieve snelheid een combinatie van bandbreedte én accesstime. Maar omdat een SSD zo'n verschrikkelijk kleine accesstime heeft, speelt die vrijwel geen rol meer, en is de effectieve snelheid vrijwel gelijk aan de bandbreedte.

Een simpel getallen voorbeeld laat dat heel duidelijk zien. Neem een typisch SSD accesstime van 0,1ms. Vergelijk dan de effectieve snelheid bij een bandbreedte van 500 en 1000MB/s.

Bij een bestand van 1 MB grootte, zit je dan op respectievelijk 476 en 909 MB/s. De dubbele bandbreedte levert daar dus gewoon een vrijwel dubbele snelheid. Daarbij kun je echt niet beweren dat extra bandbreedte geen nut heeft!

Ga ik terug naar bestanden van 100 KB, dan krijg je 333 en 500 MB/s. De winst is lager, maar de hogere bandbreedte levert me nog steeds 50% meer effectieve snelheid. Er vanuitgaande dat de hoeveelheid data groot genoeg is voor een significante laadtijd, zal 50% verschil wel degelijk merkbaar zijn. (typisch wordt ongeveer 20% genomen als 'merkbaar' voor laadtijden, framerate verschillen, e.d.)

Pas wanneer je in bestandsgrootte terug ga naar 10KB, krijg 83 en 90 MB/s, waarbij de winst door de hogere bandbreedte slechts 9% is. Daarbij is het verschil is de praktijk niet merkbaar.


Dus ja, er zijn grenzen aan het nut van bandbreedte. Maar juist omdat SSD's zo'n enorme kleine overhead hebben qua accesstime, is de bandbreedte véél belangrijker dan bij HDD's.

[jayvol09]

Een 100% verdubbeling hoeft niet merkbaar te zijn als de absolute tijdsverschillen gewoon klein zijn.

In jou 1MB voorbeeld, gaat het om totale tijden van 1.1 en 2.1 milliseconden. Volgens mij kan ik een 'delay' tussen twee visuele stimuli niet onderscheiden als deze onderling 1ms vertraging hebben...Dus een kanttekening is dat pas bij een process dat uit duizenden van die 1MB IO operaties bestaat is het in de praktijk merkbaar.

[Verwijderd]

En 1MB bestand word meestal niet gelezen als een blok van 1MB maar in blokken van 64K wat sequentieel speed is . De techniek achter de acces time is verschillend te noemen bij ssd , mijn XM-25 40GB os ssd leest max 190 en toch is die sneller met windows als een 320 die max 270MB read geeft met asssd

[Verwijderd]

jayvol09 schreef op woensdag 29 oktober 2014 @ 16:02:
Een 100% verdubbeling hoeft niet merkbaar te zijn als de absolute tijdsverschillen gewoon klein zijn.

*zucht*

Als je nou gewoon even leest: "Er vanuitgaande dat de hoeveelheid data groot genoeg is voor een significante laadtijd, zal 50% verschil wel degelijk merkbaar zijn"

Is het nou echt noodzakelijk dat ik dat óók nog apart vermeld bij de overige twee getoonde situaties, of kunnen we gewoon begrijpend lezen?

[jayvol09]

Nee je was prima duidelijk hoor, maar vind dat er meer nadruk op die aanname moest--gezien er niet was vermeld dat een computer ook vaak die ~10KB dingen doet. En het ging mij vooral om die pseudowetenschappelijke getallen van 20% en 50% voor de 'merkbaarheid'. Ik denk dat het praktischer is om in termen van milliseconden of seconden (absolute waarden) te praten als we het daarover hebben.

Gezien ik je niet eens tegensprak ofzo vind ik je neerkijkende toon een beetje onnodig.

[ Voor 10% gewijzigd door jayvol09 op 30-10-2014 18:27 . Reden: Opmerking mbt etiquette ]