SSD-tråden: info om og diskusjon rundt SSD

[Theo343]

Anvil:

Jeg er sterkt fristet til å kjøpe 2 stk Gen2 160GB og stripe dem, istedet for å vente på 320GBen over nyttår.. men 7000,- for 320GB, huff. (madness)

 

 

EDIT:

 

Bestilt 2 stk:

*skjelven*

 

Hmm men da vil jeg få en grei PC. 1x80GB G1 som OS disk og 2x160GB Gen2 i Raid0 som spill og programdisk, samt 3x1,5TB HDD som backup og andre data (og en filserver med 6TB i Raid5). Så får ny sykkel, utgifter på hus og eiendom samt div. bilreparasjoner skrapes sammen fra bunnen huff.

 

Dette var nå min siste data/PC utskeielse for 2009. (med unntak av Nvidia GT300 til jul og en 360 til høsten). Har brukt ekstremt mye penger på nytt PC utstyr i år så jeg får kalle det 40 års jubileum. Men med tanke på at andre har brukt 10.000 for noen små Mtron disker for kort tid siden så skal jeg alltids klare å trøste den sviende lommeboken litt.

 

EDIT2:

Bekreftelse mottat.

 

Hmm nå vil det bli en lidelse å jobbe med konvensjonelle harddisker. Skal bli gøy å teste litt VMs med databaser ol. på 320GB raidet.

Endret 8. august 2009 av Theo343

[KimmiK]

Nå er jeg despo etter hjelp her.

 

Har fått meg Intel X25-M 80gb disker, og skulle oppdatere firmware på dem.

Har fulgt nøye "guidelines" som står hos Intel.com download center, hvordan man skal utføre updaten.

...

Til info:

HK: Asus P5Q Deluxe

 

Du kan jo prøve å laste ned og brenne ISO på nytt.

 

Jeg oppdaterte mine X25 på et P5Q Deluxe så HK er ikke problemet, så lenge man velger rett boot medie så skal det fungere.

Husk at SSD'ene må stå på en ICH10R port, ikke de til høyre venstre.

 

Ja altså - har brent ut 4 eksemplarer av firmware'en bare for å forsikre meg om at det ikke er cd'ene som er gimp'ed, samt en DVD bare for å være på den sikre siden. Alle diskene gir meg samme tilbakemelding - kommer info. om FreeDOS og et alterntiv med "F5 og F8" ingen av dem gir noe oppstart, bare en feilmelding om at det mangle er command elns.

Rimelig sikker på at diskene er riktig brent ut nå.

 

Alvin jeg sjekket HK manualen nå, for å være på sikre siden. De 6 øverste portene, aka 1-6 går vel på ICH10R. Jeg har testet port 1 og 2, men ikke de andre (det skal jeg prøve).

Kan du erindre hvilken SATA slot du brukte når du updata din?

 

takk for svar btw

Endret 8. august 2009 av KimmiK

[Betroz]

La oss si at jeg velger 64K i stripe size for mitt X25-M RAID 0 oppsett. Trenger jeg kjøre Diskpart for å sette Offset med X-25-M? Setter ikke Win7 default 1024K da? Er det for høyt sammen med 64K stripe?

[Nizzen]

La oss si at jeg velger 64K i stripe size for mitt X25-M RAID 0 oppsett. Trenger jeg kjøre Diskpart for å sette Offset med X-25-M? Setter ikke Win7 default 1024K da? Er det for høyt sammen med 64K stripe?

 

Det blir ikkje noe nevneverdig forskjell. Jeg har selv lekt meg med hovedkortkontrolleren og fintet med forskjellige stripe og offset. Nesten like greitt å kjøre default. "oriassi" har jo testet forskjellige stripe og offset med sine Intel disker, og kom frem til samme konklusjon

[Ourasi]

La oss si at jeg velger 64K i stripe size for mitt X25-M RAID 0 oppsett. Trenger jeg kjøre Diskpart for å sette Offset med X-25-M? Setter ikke Win7 default 1024K da? Er det for høyt sammen med 64K stripe?

 

Det blir ikkje noe nevneverdig forskjell. Jeg har selv lekt meg med hovedkortkontrolleren og fintet med forskjellige stripe og offset. Nesten like greitt å kjøre default. "oriassi" har jo testet forskjellige stripe og offset med sine Intel disker, og kom frem til samme konklusjon

 

På ICH9/10R raid0 fungerer kontrollerene på X25-M godt i par/tandem, og mer eller mindre som en dualcore, og jobber effektivt ved utestående QD og nesten dobler IOPS på realistisk QD uansett stripestørrelse eller filstørrelse.. 32-64kb ser ut til å fungere best med "Volume WriteBack Cache", og booster enkelte bencher, men denne settingen kveler viktig IOPS, til tider helt ekstremt, og bør aldri være på. Dermed blir det svært liten forskjell mellom 32-64-128kb stripe i "real life". Synes personlig 32-64kb har vært best, målbart også mot 128kb, men det er altså med "WBC" på, med denne av er det så og si likt der det teller som mest, og i enkelte situasjoner - IOMeter bootupconfig - har 128kb stripe vært marginalt best med ~10% høyere IOPS... Det kan også virke som om IOPS holder seg bedre med 128kb stripe over tid, og kan være et argument for å velge denne størrelsen, men som jeg har nevnt tidligere, og Anvil postet i sitt innlegg, Intel SSD takler fint 32-64kb og er vel så gode valg på ICH, og de opplevdes som raskere i Server 2008, men ikke i Win7...

 

Mine råd er dermed disse for Win7:

128kb stripe

1024 offset (Default Win7 offset)

WBC avslått (Volume WriteBack Cache, Raid5 funksjon)

IATA v8.7 (Storage Manager og driver, denne versjonen booter raskest, og har ingen bugs i slike Raid0 config)

Så ny ROM som mulig, nyere versjon har til tider ekstrem effekt..

 

Raid Bios, Option ROM, siste er v8.9.0.1023 og ferdig modda Asus Maximus Formula & Rampage Extreme Bioser har jeg oppdatert i denne posten: https://www.diskusjon.no/index.php?showtopi...&p=14020778

Om noen andre ønsker modda AMI bioser med denne Option ROM er det bare å sende meg en PM o.l.

Endret 9. august 2009 av Ourasi

[Betroz]

Tusen takk for det Ourasi

 

Nå var det bare å få oppgradert RAID ROM da...

[Anv]

Anvil:

Jeg er sterkt fristet til å kjøpe 2 stk Gen2 160GB og stripe dem, istedet for å vente på 320GBen over nyttår.. men 7000,- for 320GB, huff. (madness)

...

Bestilt 2 stk:

*skjelven*

 

Hehe,

 

Gratulerer!

 

Ja, det er mye penger men jeg angrer ikke et sekund på alle mine SSD'er, selv om prisene nå nesten er halvert siden jul. (takket være Intel)

Jobber mye i VS2008 og det er bare ikke praktisk mulig for meg å gå tilbake til HDD, det er en lidelse.

 

Neste investering for meg blir den nye kontrolleren til LSI (9260-8i), den ser lovende ut og støtter SAS 6Gbit.

(må vel krype til korset og bestille hos Nextron, selv om de har et kraftig påslag)

[Anv]

Test av ny Vertex FW hos pcper. Link

Ser ut som de har fått taket på gc.

[GullLars]

Der ja, fin garbage collection på vertex. Nå mangler det bare at de får det til i idle uten at det trengs noe aktivitet.

Det blir også fint at trim kommer.

 

Kanskje vi kan håpe på RAID-kontrollere som vil støtte TRIM etter hvert?

[Nizzen]

Test av ny Vertex FW hos pcper. Link

Ser ut som de har fått taket på gc.

 

Pros:

Performance restoration after heavy fragmentation events.

Performance-over-time for RAID users (Colossus included).

Performance-over-time for Mac and Linux users.

 

 

 

GullLars //Kanskje vi kan håpe på RAID-kontrollere som vil støtte TRIM etter hvert?

 

Det blir vel ikkje nødvendig når firmwaren fixer dette selv på hver enkel disk med garbage collection hvis jeg har skjønt det riktig?

Endret 9. august 2009 av Nizzen

[dabear]

Kommer det tilsvarende firmware til Intel-diskene da, med automatisk gc altså?

 

edit: og når kommer forresten colossusdiskene? Jeg mener jeg spurte om dette tidligere, men forsvant visst under rensking fra moderator.

Endret 9. august 2009 av dabear

[Anv]

Kommer det tilsvarende firmware til Intel-diskene da, med automatisk gc altså?

 

Ja, Intel har hatt en utmerket GC siden 8820 og den er enda bedre i Gen2.

Hvis dere ser på denne siden viser den hvordan Intel ser ut etter like mye juling som Vertexen. Link

Forskjellen ligger i at Intel gjør dette "on the fly" mens Vertex "rydder" etterpå når SSD'en er idle.

 

Colossus skal være klar i løpet av august ihht diverse kilder.

[Anv]

Nizzen,

 

Mine Intel raid viser ubetydelige tap. (bare få prosenter)

Det er ikke merkbart ved bruk.

 

Jeg tror nok TRIM vil fungere bedre enn GC men GC fungerer greit nok, jeg føler ikke behov for HDDerase men pleier å gjøre det hvis jeg tester nye oppsett.

 

edit:

SuperTalent har tydeligvis kommet til FW 1711, ChangeLog viser bla.

 

1.0 FIRMWARE VERSION 1711

Release Date: 8/7/09

Serial Numbers: xxxxxxx‐xEBX‐xxxxxxx

Change Log:

1. Updater runs out of DOS instead of Windows

1.1 ATA8 ACS2 TRIM Support

1.2 SATA Rx SSC is turn off by default, Now Rx and Tx SSC both off

1.3 IDENTIFY word 49 bit 14 is cleared (Non deterministic trim)

1.4 IDENTIFY word 60‐61 are changed (User addressable logical sectors for LBA28)

1.5 FPDMA error return code was not adequate

1.6 SMART related changes were made (BBM error log was removed)

1.7 SATA error handling code was enhanced

...

 

Litt uklart om det er full TRIM support, vi får se.

Disse Indilinx fw'ene er tilsynelatende identiske og det skulle bety at Vertex får de samme endringene i nær fremtid.

Endret 9. august 2009 av Anvil

[Anders Jensen]

GullLars //Kanskje vi kan håpe på RAID-kontrollere som vil støtte TRIM etter hvert?

 

Det blir vel ikkje nødvendig når firmwaren fixer dette selv på hver enkel disk med garbage collection hvis jeg har skjønt det riktig?

TRIM og "GC" (ville heller kalt det defragmentering) gjør vel strengt tatt forskjellige optimaliseringer. Jeg liker "GC" godt av prinsipp. Alle nivåer i et lagringssystem burde optimalisere seg selv når det ikke er opptatt med å håndtere forespørsler. f.eks kan jeg ikke se hvordan TRIM skal kunne motvirke fragmentering fra write combining og "GC" kan ikke motvirke behovet for read-modify-write når deler av en page skal skrives og den egentlig er tom i følge filsystemet, men disken kan ikke vite det hvis den har vært i bruk tidligere med mindre en har TRIM selvfølgelig.

 

TRIM var vel strengt tatt ikke tiltenkt disker fra begynnelsen, men thin provisioning på kontrollere. Med lagringsmedier som er organisert slik at read-modify-write er nødvendig, dvs. organisert i pages med mindre blokker som må programmeres samtidig så er TRIM en fordel. For andre former av NVRAM enn flash kan TRIM vise seg å være unyttig. F.eks hvis en har en type NVRAM som kun er organisert i individuelt programmerbare blokker og ikke i pages.

[Anv]

GC defragmenterer ikke men i praksis kan man nok forenklet si at det er det som skjer.

Fordelen med GC er at den er håndtert at firmware og ikke OS.

TRIM er avhengig av OS for å fungere men i og med at OS/filsystem er inne i bildet kan den nok gjøre en bedre jobb totalt sett.

 

Det hadde nok være best om begge deler var tilstede, spørsmålet er om TRIM gjør GC overflødig eller ikke.

[Anders Jensen]

GC defragmenterer ikke men i praksis kan man nok forenklet si at det er det som skjer.

Fordelen med GC er at den er håndtert at firmware og ikke OS.

GC defragmenterer i sitt scope. dvs den defragmenterer pages ikke filer siden kontrolleren ikke aner noe som helst om verken filer eller filsystem.

 

TRIM er avhengig av OS for å fungere men i og med at OS/filsystem er inne i bildet kan den nok gjøre en bedre jobb totalt sett.

TRIM kan ikke gjøre noe som helst mot write combining som er helt kritisk for random write ytelsen på NVRAM organisert i pages, dvs flash.

 

Å si at TRIM gjør en bedre jobb enn GC er som å si at ABS bremser gjør en bedre jobb enn antispinn... helt forskjellige problemer som løses, men alt i den hensikt å gjøre kjøring enklere og tryggere.

 

Det hadde nok være best om begge deler var tilstede, spørsmålet er om TRIM gjør GC overflødig eller ikke.

Les min forrige post som du ser ut til å svare på...

Endret 9. august 2009 av Anders Jensen

[lockdog]

Er det noen nettbutikker som har intel 2.gen disker inne?

[GullLars]

Det overrasker meg at folk ikke har fått med seg de fundamentale forskjellene mellom GC og TRIM (og fragmentering for den saks skyld).

-Garbage Collection: Optimalisering av plasseringen ledige og brukte pages så man unngår at det bygges opp blokker med blanding av brukte og ugyldige pages, og i tillegg får samlet tomme pages i blokker.

-TRIM: En kommando der filsystemet forteller lagringsenheten at LBA har blitt slettet i stedet for bare å merke det i registeret for overskriving senere.

-Fragmentering: Spredning av en fil over fler LBA som ikke er sammenhengende. (har praktisk talt ingen betydning for SSD)

 

TRIM er en fordel siden det minsker behovet for overprovisjonering av flash, eller virker som om det var mer overprovisjonering når det er en del ledig kapasitet. Dette hjelper spesielt på sustained random write.

[Nizzen]

Det overrasker meg at folk ikke har fått med seg de fundamentale forskjellene mellom GC og TRIM (og fragmentering for den saks skyld).

-Garbage Collection: Optimalisering av plasseringen ledige og brukte pages så man unngår at det bygges opp blokker med blanding av brukte og ugyldige pages, og i tillegg får samlet tomme pages i blokker.

-TRIM: En kommando der filsystemet forteller lagringsenheten at LBA har blitt slettet i stedet for bare å merke det i registeret for overskriving senere.

-Fragmentering: Spredning av en fil over fler LBA som ikke er sammenhengende. (har praktisk talt ingen betydning for SSD)

 

TRIM er en fordel siden det minsker behovet for overprovisjonering av flash, eller virker som om det var mer overprovisjonering når det er en del ledig kapasitet. Dette hjelper spesielt på sustained random write.

 

Da foreslår jeg at du oppdaterer 1. post med slik viktig info

[Nizzen]

Dere med SSD:

 

Kjør denne testen: fc-test

 

http://www.xbitlabs.com/articles/storage/d...ay/fc-test.html

 

 

Dette er en real life test som det er litt nytte i.

 

Innlegg #4000

Endret 9. august 2009 av Nizzen