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

[Tannpirkeren]

128GB titan koster 2600

Rart at den jeg leverte inn ikke har kommet som demovare enda. Men multicom er jo så sabla treige at det kan nok ta noen måneder.

 

... eller kanskje de selger den som ny? De jævlene....

 

Det forundrer meg ikke. Man fokuserer jo som oftest kun på salg.

Endret 14. mars 2009 av Sveinl

[moab]

Jeg regner nok med å gjøre en clean av disken før neste lanserte versjon av Win7 kommer (det var et program som skulle nullstille alle interne tabeller i diskene..), og droppe bench-marking av den deretter Men jeg kommer til å kjøre en uviklings-database på maskinen så QD>4 regner jeg med at det blir noe i praksis (men ikke over så lang tid om gangen..).

 

Kilder?

Hadde jeg bare husket hvor jeg leste det.. OCZ forum vil jeg tro.. Uansett så ser det jo ut som en flashing av diskene "nullstiller" diskene, så det blir vel siste alternativet..

[moab]

@moab:

IOmeter står standard til "allign to sector", men ikke som standard 4KB allign (alså cluster). Partisjon-allignment på SSD går ut på å starte partisjonen på starten av en erase-block. Erase-blocks er normalt 128kb-512kb, og 1024 vil da være et multiplum av det, òg av 4kb cluster size, så man får ingen form for kollisjon. Tilfeldigvis er normal cluster-size på SSD (den minste størrelsen man kan skrive) er 4kb, den minste størrelsen man kan slette er en erase-block. Når en erase-block har blitt slettet kan SSDen skrive til den 4kb av gangen. Dersom man lager et raid med SSDer er det en fordel om [stripe-size]/[antall enheter] er et multiplum eller en (1/x)-brøk av [erase-block].

Det blei kanskje utenfor hva du spurte om

 

Du har ikke forstått poenget mitt, nei. Poenget ditt med å bruke IOMeter var jo å få en "reell" ytelsestest av diskene. Dersom en bruker mye tid på å få riktig alignment på diskene, så vil en test uten "align to cluster" (Align på 4KB) være bortkastet. En tester ikke reell ytelse. Uten align kommer ikke cluster innenfor "erase-blocks" grenser. Resultatet blir også at den interne fragmenteringen i SSDen vil øke mye fortere.. (Uten at jeg vet nok om de interne datastrukturene brukt i SSDen til å ha skikkelig hold i påstanden)

 

Du mangler den siste forutsetningen. Alle cluster må innen en stripe.. Dvs. at ingen cluster blir delt på midten. Det er jo det som skjer dersom en ikke har alignet partisjonene rett.. Dersom det er unalignment så vil jeg også tro at det sliter mer på SSDen enn at den ikke er; Hver skriv av 4KB blokk medfører oppdatering av 2 slike blokker. (Dette forutsetter at OCZ egentlig har en "virtuell" 4KB sektor-størrelse internt). Jeg kunne godt tenkt meg å vite mer om interne datastrukturer i SSDer...

[Beef Supreme]

Du vet at XP 64bit er så og si nøyaktig det samme Win 2003? Du har fått med deg at de kjører nøyaktig samme SP level? Som i dette tilfellet antyder meget nært slektskap.

Er ikke helt med på denne egentlig. Du vet at både PC og mac begge bruker et hk, et skjermkort, ram osv, så da er det i essensen samme ting?

 

Jeg brukte XP64 en periode for jeg hadde 4GB RAM tilgjengelig på den pcen, men det var jo helt umulig å finne drivere til noe som helst, og det var jo ikke stabilt en plass. Kanskje jeg bare var uheldig med sammensetning av HW eller noe, men da jeg gikk tilbake til XP32, så var det en fryd hvertfall.

 

Men omg, det er farlig å la denne tråden gå uten å følge med. 4 fulle sider siden jeg logga av igår kveld^^

[Nizzen]

Noen som har testet ssd med windows 95 eller windows 3.11?

 

Jeg liker å bruke gamle OS.... Not

[Beef Supreme]

Haha, det var en idè! Instant boot^^

[moab]

Noen som har testet ssd med windows 95 eller windows 3.11?

 

Jeg liker å bruke gamle OS.... Not

Nei, men jeg har prøvde å kjøre win 3.11 på ramdisk Det var den samme morroa som å kjøre win7 på SSD i dag..

[moab]

2 x 30GB Vertex i RAID0 på Perc 6/i med 4 outstanding på Win7 64 bit build 7000.

 

4KB; 100% Read; 100% random Access: 11608 iops

Klikk for å se/fjerne spoilerteksten nedenfor

 

4KB; 0% Read; 100% random Access: 4483 iops

Klikk for å se/fjerne spoilerteksten nedenfor

 

4KB; 90% Read; 90% random Access: 8448 iops

Klikk for å se/fjerne spoilerteksten nedenfor

 

Og til sist korreksjonene mine på "Edit Access Specification"

Klikk for å se/fjerne spoilerteksten nedenfor

Klikk for å se/fjerne spoilerteksten nedenfor

Endret 14. mars 2009 av moab

[Theo343]

Du vet at XP 64bit er så og si nøyaktig det samme Win 2003? Du har fått med deg at de kjører nøyaktig samme SP level? Som i dette tilfellet antyder meget nært slektskap.

Er ikke helt med på denne egentlig. Du vet at både PC og mac begge bruker et hk, et skjermkort, ram osv, så da er det i essensen samme ting?

Jeg skjønner at du ikke er helt med, men det er veldig enkelt. XP 64bit har en vesentlig nyere kjerne enn XP 32bit, og er det samme som Windows 2003 64bit. Derfor følger også disse hverandre i SP nivå.

 

Hadde du problemer med å finne drivere til XP 64bit hadde du samme problemet med å finne drivere til 2003 64bit. Det er desverre veldig mange hardware leverandører som ikke lagde drivere for XP 64bit, men XP 64 var likevel det beste OSet MS har laget til dags dato. Så får vi se hva Win7 blir til.

Endret 14. mars 2009 av Theo343

[Beef Supreme]

Jeg skjønner at du ikke er helt med, men det er veldig enkelt. XP 64bit har en vesentlig nyere kjerne enn XP 32bit, og er det samme som Windows 2003 64bit. Derfor følger også disse hverandre i SP nivå.

 

Ah, var ikke helt sånn jeg mente det. Skulle vel heller skrevet at jeg ikke var helt enig. Greit nok at de er veldig like, men opplevelsen var ekstremt forskjellig for meg hvertfall. Tror ikke jeg skreiv at jeg brukte 2003x64? Da skreiv jeg feil isåfall. Bruker bare 32bit. Har bare 512MB RAM i serveren min, så x64 er ikke noe poeng. Men samma det. Poenget var at XP64 og server2003 var natt og dag for meg hvertfall.

 

Men skal hjem om en time, så da blir det ny benchmark av SSDene mine

Endret 14. mars 2009 av Beef Supreme

[Theo343]

Jupp back to SSD, bli gøy å se flere resultater

 

 

PS

XP 64bit bruker den samme kjerne som 2003 32/64bit. Forskjellen hos deg var nok driveropplevelsen.

Endret 14. mars 2009 av Theo343

[Beef Supreme]

Hvis det er greit for folk her vil jeg gjerne samle en del av hva som er skrevet og legge det inn her: https://www.diskusjon.no/index.php?session=...&p=13313858

 

Trenger litt mer info, men kan hvertfall få samlet opp en god del hvis jeg bare leser gjennom de siste 30-40 sidene.

[oba]

For å komme litt på "villspor": Jeg har ikke helt forstått hva en styrer med når det gjelder alignment av partisjoner.. Filsystemet er jo laget som 4KB tildelingsenheter som blir lest i sin helhet (for det meste..). Ville det da ikke heller være lurt å prøve aligment fra 0..4KB, helst i sektor-steg. Det kommer jo selvfølgelig litt ann på hvordan filsystemene er bygd opp.. Jeg kjenner bare litt til den fysiske oppbygningen av FAT; boot-sektor + 2 x FAT + data. Jeg tror ikke det er noe fill for å gjøre slik at data blir relokert ift. 4KB. Tenkt eksempel. Hver FAT bruker 11 sektorer: 1 + 11* 2 gir 23 sektorer før data.. Dvs. at data er 1 sektor for lite ift. 4KB tildelingsenheter. NTFS er jo nyere, og finnes i flere revisjoner, så det ville overaske meg om ikke alle tildelingsenheter er alignet ift. starten av partisjonen. Jeg har lyst å lese meg litt opp på de interne data-strukturene til NTFS for å se hvordan det er der. Det lille jeg har lest så ser strukturene nesten enklere ut en FAT.. den tilsvarende FAT (File Allocation Table) i NTFS er f.eks. lagret i en skjult fil på disken og ikke som er reservert område som på (v)FAT. All metadata er faktisk "filer".

Windows XP aligner partisjonen med 63 sectorer offset og det går ut over ytelsen (det har jeg selv testet). Da er det en fordel å benytte f.eks. diskpart for å aligne partisjonen først. Jeg fant ikke noe videre ytelsesforskjell med 64, 128, 256 osv sectorer offset, men 63 fungerer dårlig. Dette er hovedsaklig et problem i Windows XP og ikke i Vista eller W7.

[moab]

Windows XP aligner partisjonen med 63 sectorer offset og det går ut over ytelsen (det har jeg selv testet). Da er det en fordel å benytte f.eks. diskpart for å aligne partisjonen først. Jeg fant ikke noe videre ytelsesforskjell med 64, 128, 256 osv sectorer offset, men 63 fungerer dårlig. Dette er hovedsaklig et problem i Windows XP og ikke i Vista eller W7.

Det er vel det som er litt av poenget mitt.. Det kan hende alignment på 65 eller 65,5 er bedre enn de "hele" tall for FAT.. Poenget er å få cluster alignet ift. erase-enheter (evt. intern-allocation enhet på SSD'en..). NTFS er helt sikkert bedre på dette området, siden den var fra starten av var tenkt for servere med RAID (og derfor er alignet ift. stripe-size).

[oba]

Det er vel det som er litt av poenget mitt.. Det kan hende alignment på 65 eller 65,5 er bedre enn de "hele" tall for FAT.. Poenget er å få cluster alignet ift. erase-enheter (evt. intern-allocation enhet på SSD'en..). NTFS er helt sikkert bedre på dette området, siden den var fra starten av var tenkt for servere med RAID (og derfor er alignet ift. stripe-size).

Jeg har ikke testet med FAT. Windows XP partisjonerer disken med 63 sectorer offset og det går ut over ytelsen dersom jeg formaterer med NTFS. Mulig det hadde fungert bedre med FAT, men det vet jeg ikke.

[oba]

Da er min 30GB vertex i posten gitt!! Men jeg er litt skeptisk fordi OCZ har fått rapporter om mulige problemer med Vertex på Gigabyte-hovedkort.. Enkelte har problemer med å få installert OS hvis man endrer på alignment osv.. Er det noen her som har sett noen plasser der dette har blitt funnet en løsning på?

Jeg har et Gigabyte GA-MA790XT-UD4P hvor jeg nå benytter en OCZ vertex 60GB som OS disk. I følge guiden

http://www.ocztechnologyforum.com/forum/sh...ead.php?t=48309

anbefales det å benytte 128 sectorer alignment.

Jeg fikk ikke bootet med Windows XP hvis jeg partisjonerte disken med 128 sectorer offset.

Jeg benyttet i stedet 256 sectorer offset og da kan jeg boote fra disken.

En liten oppdatering:

Etter at jeg oppgraderte til siste firmware (1199) så gikk det ikke lenger å benytte 256 sectorer offset på boot disk. Nå fungerer derimot 128 sectorer offset fint

Endret 14. mars 2009 av oba

[JKJK]

Beef: Din beef er egentlig med 64 bit os generelt, ikke XP64. Det er sikkert en god stund siden du prøvde XP 64, og xp64 hadde store driverproblemer i børjan, men i dag er saken en helt annen. Det at du skriver at Windows server 2003 var så mye bedre er jo bare PISS. Du gikk helt sikkert over til _32bit_ versjonen av server 2003, og da faller uttalelsen din i fisk!

 

Det er mer eller mindre samme OS, forskjellen DU gjorde var 64/32bit. Så at DU ikke fikk det til betyr ikke at XP64 er et dritt-OS. Etter min mening så er det det mest _stabile_ windows klientOS'et pr. dags dato.

 

Her skulle jeg egentli hatt et skikkelig Carlos Mencia utbrudd, men jeg velger å la være. De som har sett han, vet hva jeg snakker om :!:

Endret 14. mars 2009 av JKJK

[JKJK]

damn... skal prøve å ta en ny iometer test med den endringen til moab.

[Beef Supreme]

Okey, rolig nå

Jada, sant det er en stund siden nå, men for meg så var faktisk hele greia bare ustabil. (snakker bluescreen og frysing her) Vet ikke om det hadde noe med HW å gjøre, men hadde kun problemer med XP64, ikke noe annet.

 

Ellers har jeg ikke hatt problemer med x64. Har prøvd Vista home premium/ultimate x64, og W7 beta 7048(?) x64, og det funka knall.

 

Så for meg så har XP64 vært det mest ustabile OS som jeg har brukt.

Endret 14. mars 2009 av Beef Supreme

[JKJK]

Vista 64bit er en helt annen historie. Det ble sluppet samtidig med Vista 32, og derfor lagde de fleste hwprodusenter drivere til begge OS samtidig. Når det kommer til XP, så ble det sluppet en for IA64 i 2002 og en 64 bit versjon basert på server 2003 kjerne i 2003 ... 2 år etter 32 bit. Derfor var det mangel på gode drivere til xp64 lenge.

 

 

Men for å over til noe annet:

Ser ikke ut som jeg får noe annet resultat i IOmeter med 4KB allignment innstillingene.