[SSD] Wat is er beschikbaar en werkt het ? Deel 1

Euh, wil niet vervelend zijn maar zie de nodige mensen die de B's en b's verwisseld hebben

Die Super talent MX 15GB is nog best betaalbaar, hmm.

quote:

GreenSky schreef op woensdag 21 mei 2008 @ 19:26:
Die Super talent MX 15GB is nog best betaalbaar, hmm.

12 eur/per GB
Nog steeds netter dan de Mobi en OCZ

quote:

Dethroned schreef op woensdag 21 mei 2008 @ 22:04:
12 eur/per GB
Nog steeds netter dan de Mobi en OCZ

Nu moeten we nog zien wat voor effect die read/write verhouding en snelheden gaan hebben op real life benchmarks.
Maar ik verwacht dat die wel aardig gaan zijn

Anandtech - SSD Update - Memoright 32GB on the Desktop

quote:

The largest issue with any SSD is the fact that most desktop class OS's are not tuned for them.
XP in particular is hard coded to expect a ~10-12ms access time.
I don't claim to be a guru on the IO habits of MS OS's but most modern OS's have implemented many kernel code level 'gymnastics' to avoid hard disk latency that is simply not an issue with SSD.
When these algorithms are presented with low latency drives, such as a SSD, they don't compensate for the added performance.

Example:
The Linux elevator CFQ IO algorithm will sweep the disk, perform all requests when the head passes the required location. IO's are investigated and re-ordered based upon several factors, the largest being the head location. With SSD, the head is simulated and instantaneous.
Switching the IO algorithm under Linux to No-op (first-come first-serve with no re-ordering) should allow the SSD to shine.

I found that with large SAN arrays and RAID array's with battery backed-up write cache, disableing IO scheduling optimizers increased performance significantly on database TPC tests and conversely killed performance on JBOD arrays with no cache. It stands to reason that the same effect would hold true on SSD.

I can't find any way to disable these types of IO optimization in Windows like in the example above.

Ik vind dit wel een uitermate belangrijk punt. Kan iemand hier op in gaan?

Heb je misschien een bron? Het is verbazend te lezen dat een OS een bepaalde vaste afhandel snelheid verwacht. Wat als je dan een tragere schijf hebt? Loop je dan CPU-cycles (of andere instructies) gewoon mis?

quote:

Dethroned schreef op donderdag 22 mei 2008 @ 18:53:
[...]


Ik vind dit wel een uitermate belangrijk punt. Kan iemand hier op in gaan?

Dat is al bekend, zie ook: Enlightenment in "[SSD] Wat is er beschikbaar en werkt het ?"

En ja alle I/O reordering algoritmes in filesystem en RAID controllers zoals Areca zullen met SSDs overbodig worden. Ook zal er een veel agressievere pre-fetch gebruikt kunnen worden. Ik ben verder onbekend hoe XP omgaat met disk I/O, in FreeBSD heb ik wel een aardig idee; geom is heel transparant. Die 'verwachte latency' behoeft nog verdere uitleg, maar is zeker niet ondenkbaar dat XP getuned is voor mechanische schijven en dat bij SSDs juist tegenwerkt.

Om SSDs echt snel te laten werken, zijn aanpassingen nodig aan beide operating systems. Maar ook vooral aan applicaties zelf, blocking I/O moet uitgeroeid worden. Misschien tijd om het depricated te maken en een melding geven in de console, maarja of dat de oplossing is.. eerder wanhoop.

Maar even die resultaten van Crysis erbij halend: ik zie niet in waarom het een halve minuut moet duren met de drie snelste schijven op dit moment: Velociraptor, Mtron en Memoright. Dat betekent dat er in elk geval niet sequentiëel wordt ingelezen of er veel processing bij gepaard gaat. Allemaal zaken die in de software zelf moeten worden opgelost.

Enlightenment wijzigde dit bericht 22-05-2008 19:14 (5%)

quote:

Roamor schreef op donderdag 22 mei 2008 @ 19:08:
Heb je misschien een bron? Het is verbazend te lezen dat een OS een bepaalde vaste afhandel snelheid verwacht. Wat als je dan een tragere schijf hebt? Loop je dan CPU-cycles (of andere instructies) gewoon mis?

quote:

Help!!!! schreef op donderdag 22 mei 2008 @ 18:15:
Anandtech - SSD Update - Memoright 32GB on the Desktop

En dan einde artikel, 2e of 3e reactie ofzo

quote:

Enlightenment schreef op donderdag 22 mei 2008 @ 19:13:
[...]

Dat is al bekend, zie ook: Enlightenment in "[SSD] Wat is er beschikbaar en werkt het ?"

En ja alle I/O reordering algoritmes in filesystem en RAID controllers zoals Areca zullen met SSDs overbodig worden. Ook zal er een veel agressievere pre-fetch gebruikt kunnen worden. Ik ben verder onbekend hoe XP omgaat met disk I/O, in FreeBSD heb ik wel een aardig idee; geom is heel transparant. Die 'verwachte latency' behoeft nog verdere uitleg, maar is zeker niet ondenkbaar dat XP getuned is voor mechanische schijven en dat bij SSDs juist tegenwerkt.

Om SSDs echt snel te laten werken, zijn aanpassingen nodig aan beide operating systems. Maar ook vooral aan applicaties zelf, blocking I/O moet uitgeroeid worden. Misschien tijd om het depricated te maken en een melding geven in de console, maarja of dat de oplossing is.. eerder wanhoop.

Maar even die resultaten van Crysis erbij halend: ik zie niet in waarom het een halve minuut moet duren met de drie snelste schijven op dit moment: Velociraptor, Mtron en Memoright. Dat betekent dat er in elk geval niet sequentiëel wordt ingelezen of er veel processing bij gepaard gaat. Allemaal zaken die in de software zelf moeten worden opgelost.

Wat ik me afvraag is of er verschil is tussen winXP en Vista en of je het anders beide of alleen Vista wel kan regelen dat het anders gaat, of een workaround doen werken.

quote:

Enlightenment schreef op donderdag 22 mei 2008 @ 19:13:
Maar ook vooral aan applicaties zelf, blocking I/O moet uitgeroeid worden.

Als je puur op basis van de eigenschappen van 1 medium een bepaalde techniek wil uitroeien, maak je feitelijk dezelfde fout als de personen die dachten dat elevator algoritmes altijd nut hebben.

Bepaalde eigenschappen van het storage medium moeten ook gewoon transparant/onbekend kunnen zijn voor de grootste delen van het OS (en zeker voor applicaties!), maar het zou in dit geval idd wel leuk zijn als je een hint kon geven dat elevator algoritmes ed niet nodig zijn.

quote:

Dethroned schreef op vrijdag 23 mei 2008 @ 12:15:
[...]


Wat ik me afvraag is of er verschil is tussen winXP en Vista en of je het anders beide of alleen Vista wel kan regelen dat het anders gaat, of een workaround doen werken.

Vista is niet zo heel erg anders as XP, dus ik zou geen verbetering verwachten, zeker niet als je ziet dat de gewone HD performance bij veel kleine files onder vista nog steeds niet zo goed als bij XP is...

quote:

StarLite schreef op vrijdag 23 mei 2008 @ 14:13:
[...]

Vista is niet zo heel erg anders as XP, dus ik zou geen verbetering verwachten, zeker niet als je ziet dat de gewone HD performance bij veel kleine files onder vista nog steeds niet zo goed als bij XP is...

En dit bewijst nu net dat het onder Vista allemaal net even anders werkt.
Vista gaat niet uit van een fixed accesstime, maar moet daardoor wel meer controles toepassen. Het is over het algemeen bekend dat de performance van Vista veel meer baat heeft bij een SSD dan XP. Alleen al kijkend naar hoe lang het duurt om het OS te installeren. Onder XP duurt dit met een SSD vaak juist ellenlang.

Dan hoop ik wel dat daar nog aan gewerkt zal worden door Microsoft, want veel UMPC's gebruiken tegenwoordig zowel SSD als XP. Het zal erg ingrijpend zijn in het OS, maar hopelijk komt er nog een 'fix' voor.

quote:

--MeAngry-- schreef op vrijdag 23 mei 2008 @ 14:23:
[...]

En dit bewijst nu net dat het onder Vista allemaal net even anders werkt.
Vista gaat niet uit van een fixed accesstime, maar moet daardoor wel meer controles toepassen. Het is over het algemeen bekend dat de performance van Vista veel meer baat heeft bij een SSD dan XP. Alleen al kijkend naar hoe lang het duurt om het OS te installeren. Onder XP duurt dit met een SSD vaak juist ellenlang.

Dat bewijst natuurlijk niet direct dat alles toaal anders werkt. Het zou heel goed kunnen dat er gewoon extra checks en meuk inzitten tbv indexing en andere nieuwe vista dingen waardoor het daardoor erg traag wordt.

Ik zou zelf wel erg benieuwd zijn naar benchmarks waarin XP en vista worden vergeleken. Als SSD's wat betaalbaarder worden ga ik er namelijk zeker 1 of 2 halen.

Super talent MX 120 gb
read 120 mb/sec
write 40 mb/sec
price € 445
Dat is € 3,71 per GB.

De meeste SSD's zijn stukken duurder.


Wat betreft het verschil tussen xp en vista. Ik wil ok wel een verschil zien met een uitgeklede xp (Lite of Fundamentels) en een "lite" versie van vista.

quote:

Roamor schreef op vrijdag 23 mei 2008 @ 14:26:
Het zal erg ingrijpend zijn in het OS, maar hopelijk komt er nog een 'fix' voor.

Dat het ingrijpend is, is probleem #1 voor onderhoud aan en vooruitgang van Windows. Bij een minder monolitisch stuk software waar gewoon een heldere, zelfstandige fs component in zit is het bijna triviaal te fixen.

Ik ben op zoek naar SSD's in 1,8" form factor met IDE interfaces.
Tot nu toe alleen 2 merken gevonden
MTRON
Mtron MSD 1000
Mtron MSD 3000

Super Talent
Super Talent 32GB 1.8" DuraDrive ET PATA

Samsung
32/64 gb

De beschikbaarheid is gering en de prijzen een sag hoger dan de 2,5"

Edit - overbodig.

Deephouse wijzigde dit bericht 24-05-2008 18:15 (85%)

quote:

Voutloos schreef op vrijdag 23 mei 2008 @ 12:26:
Als je puur op basis van de eigenschappen van 1 medium een bepaalde techniek wil uitroeien, maak je feitelijk dezelfde fout als de personen die dachten dat elevator algoritmes altijd nut hebben.

Om even een analogie te gebruiken:

Blocking I/O werkt zo: je gaat naar de keuken, pakt een mes uit de lade en loopt naar de etenstafel toe. Je beseft dat je ook nog een vork nodig hebt en gaat weer terug naar de keuken, dan later nog een lepel. En oh voor je gezin ook nog; ongeveer 20 tripjes naar de keuken en elke keer één ding pakken. Niet erg efficient.

Non-blocking I/O ook wel a-synchrone I/O genoemd, werkt zo: je gaat naar de keuken, pakt alles wat je nodig hebt tot een bepaald maximum wat je in één keer kunt dragen, en loopt terug naar de etenstafel. Klaar. Het 'pakken' bij de lade duurt langer omdat je dan alles in één keer moet pakken, maar omdat je niet tig onnodige tripjes hoeft te maken scheelt dit enorm veel tijd en is dus vele malen sneller!

Maar hier wringt het schoentje: om dit laatste mogelijk te maken, moet jij wel weten welk bestek je precies nodig hebt, of je moet maar wat gokken. Als een software-programma met blocking I/O werkt, kan het bestandssysteem maar heel beperkt 'pre-fetchen': alleen als een groot bestand sequentiëel wordt ingelezen kan het filesystem vermoeden dat na de 28e sector misschien wel de 29e sector ook opgevraagd wordt, en dus alvast binnenhaalt. Dit laatste heet read-ahead. Nu is het probleem dat bij het inladen van een level in een game de gegevens misschien wel in één groot bestand staan, maar dat in dat bestand maar hier en daar gegevens van nodig zijn. Zonder kennis te hebben wélke gegevens precies nodig zijn, kan het bestandssysteem dus geen optimalisaties toepassen. De slecht geprogrammeerde game zal pas zeggen wat hij erna nodig heeft, als de huidige opdracht is voltooid. Dit is dus erg langzaam!

Een goed geprogrammeerde applicatie zal non-blocking I/O gebruiken en zo direct 20 of wel 500 I/O opdrachten de deur uit gooien, en dan is het aan het bestandssysteem deze op een efficiente manier af te handelen; en dat lukt dus ook veel beter dan één voor één. Deze vorm van I/O is sneller voor zowel SSD's als mechanische hardeschijven, dus er wordt niet specifiek geoptimaliseerd voor een bepaald medium! Probleem is dat a-synchrone operatie ingewikkeld is en een goed softwaredesign vereist; niet bepaald iets waar een commerciëel softwareproject wat vaak onder hoge tijdsdruk staat veel aandacht aan kan besteden. Nu met SSDs de potentie tot hoge performance wordt bereikt, is het echter aan de softwareindustrie om eens werk te maken van parallellisatie: op zowel het gebied van I/O als op het gebied van threading, zodat je quadcore ook echt tot zijn recht komt.

Salland verkoopt nu de Imation/Mtron drives die een tijdje geleden aangekondigd werden. Ik nam aan dat de prijzen lager zouden liggen dan die van Mtron, maar dit blijkt dus niet zo te zijn. 509 euro voor 16GB, en 936 euro voor 32GB. Zo'n 40% boven Mtron prijzen. Erg vreemd.

quote:

Dethroned schreef op zaterdag 24 mei 2008 @ 17:05:
Ik ben op zoek naar SSD's in 1,8" form factor met IDE interfaces.
Tot nu toe alleen 2 merken gevonden
MTRON
Mtron MSD 1000
Mtron MSD 3000

Super Talent
Super Talent 32GB 1.8" DuraDrive ET PATA

Samsung
32/64 gb

De beschikbaarheid is gering en de prijzen een sag hoger dan de 2,5"

Als je ZIF IDE meerekent kun je de sandisk uata 5000 ook proberen.

quote:

Enlightenment schreef op zaterdag 24 mei 2008 @ 22:45:
[...]
-Blocking/Non-blocking I/O verhaal-

Ik moet zeggen dat ik de vergelijking een beetje raar vind. Ik zou het eerder zo zien.
Blocking I/O: Je zit aan tafel en vraagt iemand anders een lepel te halen. Je wacht tot die gene terug is met de lepel voor je aan de soep begint. Ondertussen doe je dus helemaal niets anders.
Non-blocking I/O: Je vraagt iemand anders een lepel te halen en begint ondertussen aan de stokbroodjes kruidenboter. Zodra de lepel er is begin je aan de soep.

Oftewel het is niets meer dan een efficientere oplossing op het moeten wachten op data. En dan maakt het dus niet uit of dit nu een groot sequentieel blok is of een paar kleine random blokjes. De applicatie zal gewoon wat anders doen in de tussentijd waardoor de vertraging van een I/O actie minder impact heeft op de perfomance van de applicatie. Het verschil tussen reguliere en solid state schijven is daardoor ook kleiner.

drZymo wijzigde dit bericht 25-05-2008 09:32 (9%)

Inderdaad, de termen asynchroon en synchroon staan daar voor. Een asynchroon 'iets' (of het nou een message of een i/o-request is) laat het proces verder gaan. Een synchroon request houdt het proces op (dus gaat naar 'waiting' state) totdat het request vervuld is.

is er iemand die al met linux getest heeft?

quote:

"Example:
The Linux elevator CFQ IO algorithm will sweep the disk, perform all requests when the head passes the required location. IO's are investigated and re-ordered based upon several factors, the largest being the head location. With SSD, the head is simulated and instantaneous.
Switching the IO algorithm under Linux to No-op (first-come first-serve with no re-ordering) should allow the SSD to shine.

I found that with large SAN arrays and RAID array's with battery backed-up write cache, disableing IO scheduling optimizers increased performance significantly on database TPC tests and conversely killed performance on JBOD arrays with no cache. It stands to reason that the same effect would hold true on SSD.

I can't find any way to disable these types of IO optimization in Windows like in the example above."
Anand