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.
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.
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.
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.
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.
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.
Dat is enkel overhead van de PCI-express bus zelf, niet van de payload. Zie hier een schema voor efficiencies bij verschillende applicaties:
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.
