Gå til innhold

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

GullLars

Av GullLars
i Lagringsmedier

Anbefalte innlegg

Videoannonse

Videoannonse
Annonse
SuperSjantis

SuperSjantis

Skrevet
Skrevet (endret)

Hey! Jeg har hatt en OCZ Agility III 60GB en stund som jeg har brukt som systemdisk, men trenger mer plass med SSD-kraft, så jeg skal om et par måneder investere i en 120GB :)

 

Jeg har ingen interesse i benchmarking av disker, og ser kun etter en disk som vil funke godt som systemdisk, og som det vil bli prakket noen spill på(Steam-&--#62;Skyrim, CoD, BF3 osv.). Jeg er klar over at spill ikke får noe ytelses-hopp når det kommer til SSD, men jeg foretrekker å ha de største spillene på SSD'n grunnet oppstart- og loadingtid.

 

Jeg har sett litt rundt det siste halvåret og holdt en knapp på Corsair Force og Corsair Force GT, men jeg vet ikke om det er det beste valget til mitt bruk :hmm:

Jeg skal forresten handle på dustinhome, så Crucial sine disker er vel utelukket :hm:

 

Anbefalinger, noen?

Endret av Reap
Lenke til kommentar
Anders Jensen

Anders Jensen

Skrevet
Skrevet

Den Intel SSD'n er bra ja. Skal du ha det beste, så er jo Plextor M3P 256GB raskest, men den koster også mye mer. 4K QD 1-5 random er det viktigste.

Helt enig, men ville bare påpeke at dette i realiteten er det samme som å si at responstid er det viktigste, selv på en SSD som har veldig lav responstid sammenlignet med HDD. Skulle ønske det ble mer fokus på dette. SSD har fortsatt veldig høy responstid sammenlignet med andre komponenter som CPU, RAM, ja selv LAN forsinkelse.

  • Liker 1
Lenke til kommentar
GullLars

GullLars

Skrevet
  • Forfatter
Skrevet (endret)

Den Intel SSD'n er bra ja. Skal du ha det beste, så er jo Plextor M3P 256GB raskest, men den koster også mye mer. 4K QD 1-5 random er det viktigste.

Helt enig, men ville bare påpeke at dette i realiteten er det samme som å si at responstid er det viktigste, selv på en SSD som har veldig lav responstid sammenlignet med HDD. Skulle ønske det ble mer fokus på dette. SSD har fortsatt veldig høy responstid sammenlignet med andre komponenter som CPU, RAM, ja selv LAN forsinkelse.

Tja, ytelse ved QD 1 avhenger av forsinkelser (NAND, kanal, kontroller, interface, HBA), mens ved QD 2-5 er det snakk om SSDen klarer å hente ut parallellitet med samme lave latency, ikke alle klarer det like godt. EDIT: jeg ser jeg leste innlegget til Anders feil. Jeg er helt enig i at det er snakk om latency for hver request.

 

C300 er gode SSDer sånn sett, de har ca 80-85% av teoretisk skalering fra QD 1 til 4 (om man ser bort fra target (channel) overlapping i teoretiske max).

8K IOPS @ QD 1, 27K IOPS @ QD 4. 27/8 = 3,375x skalering. Så ca 15% overhead.

Andre SSDer går typisk fra 5000 eller 7500 til 15 eller 20K IOPS fra 1 til 4, altså 2,67-3x skalering.

Om man antar 8 flash kanaler og QD 4 får man teoretisk max skalering fra 1 på 3,575 pga request target overlap.

Det betyr at C300 ligger rundt 3,375/3,575 = 94% av ideell skalering (sett bort fra latencies ved QD1 som reduseres relativt til throughput når QD skalerer.)

Forutsatt at jeg har analysert det riktig.

 

Kan noen som har peil på matte og datamaskin arkitektur sjekke om denne rekursive definisjonen av ytelsesskalering for random read virker fornuftig?

Skalering(QD) = ytelsesskalering over forgie QD  (delta ytelse) som en gang av QD=1, altså 1 = Ytelse QD
EDIT: byttet om plass på Skalering(QD) og Skalering(1) og rettet den fra å referere til seg selv i forgie steg til å referere Ytelse(QD-1). Det er altså indirekte rekursjon.
Skalering(QD) = 1-1/(#kanaler-(Ytelse(QD-1)-1))
Skalering(1) = 1.
Ytelse(QD) = sum(Skalering(QD)).

Dette fører til følgende ytelsesskalering for en SSD uten overhead i kontrolleren og 8 kanaler:

post-163450-0-99264700-1333205440_thumb.png

Dette ser ut til å sammenfalle ganske bra med målte observasjoner for mange SSDer, om man drar grafen litt lenger ut over X-aksen for å ta høyde for overhead. Mange SSDer med 8 kanaler har blitt målt til å skalere noenlunde godt opp til ca QD 10, og treffe et platå rundt QD 12-15.

Etter hva jeg har sett av benchmarks ser det ut som punktene forskjøvet 1,2 til 1,4 ganger QD bortover X-aksen stemmer godt.

 

EDIT1: leste innlegget til Anders Jensen feil.

EDIT2: rettet formelen i kodeboksen, hadde oversatt den feil fra Excel formel til kode. Det var indirekte rekursjon. Ytelse(QD) er sum Skalering fra 1 til QD, men vet ikke helt hvordan jeg skal skrive det her. Skalering blir kanskje feil ord, det skal være den deriverte av Ytelse med hensyn på QD, dYtelse/dQD.

EDIT3: etter å ha testet samme formelen med 32 kanaler (tilsvarer 4R0 8-kanal SSD) ser det ut som jeg mangler en faktor. Den faller av for fort når QD nærmer seg antall kanaler. Jeg tror det skal være en (1+[?]) under en brøk et sted, eller noe tilsvarende som gir en asymtote som gjør at Ytelse går mot antall kanaler i stedet for å bli antall kanaler, og da at Skalering(QD) = dY/dQD går mot 0.

Endret av GullLars
  • Liker 2
Lenke til kommentar
Anders Jensen

Anders Jensen

Skrevet
Skrevet (endret)

Generelt når det gjelder skalering så bør en stille seg spørsmålet om god skalering er viktig. Det er fort gjort å se seg blind på god skalering. Det viktigste er ytelse.

 

Når det gjelder modellering av datamaskiner så er kønettverksterori en tilnærming som kan gi veldig nøyaktige modeller. Dvs. en modellerer en datamaskinen, i dette tilfellet en SSD, som et nettverk av køer. typisk vil hver Flash brikke være en kø, hver kanal fra kontroller til flash brikke en kø, kontrolleren selv en eller flere køer i parallell avhengig av implementasjon og til slutt bussene inn mot den tilkoblede datamaskinen som en kø eller flere køer i noen tilfeller (DP SAS, IB).

 

Jeg tror de fleste kontrollere i dag er nokså serielle (kun én kø i parallell). I allefall de som sitter i SATA/SAS enheter med en singel core ARM CPU i dataplane. Hvis (når) vi får dedikert hardware i dataplane med CPU i separat controlplane eventuelt multi core CPU i dataplane så vil kontrolleren bli flere køer i parallell. Eksternt grensesnitt vil være én kø for SATA og PCIe og to eller potensielt flere køer for DP SAS og Infiniband.

 

Flere køer i parallell gir god skalering opp til antallet køer, og dårligere når QD blir større. En annen måte å se det på er at når antallet parallelle køer i et system er større enn QD til workload så er deler av systemet per definisjon idle. Så skalering er et tveegget sverd. Det forteller egentlig bare at det er ledig kapasitet til overs. Sånn sett er QD1 den "hellige gral" da den ytelsen alltid er tilgjengelig uansett workload, men i praksis er det for dyrt å optimalisere for QD1 og veldig ineffektivt for workloads med større QD.

 

Med unntak av kontrolleren i en SSD kan vi nok anta FIFO scheduling. For kontrolleren vil det nok ofte være FIFO også for lesing, men den har nok noe logikk for å spre requests utover back-end kanalene når det er store køer. Det er jo lite vits i å stå å stange på en opptatt kanal hvis en også har read request til en ledig kanal liggende i køen. Når det gjelder skriving så er firmware i kontrollerne så kompleks at en bare kan glemme å modellere det på gutterommet. Det må da finnes noe her i verden som er mer interessant? :) Å modellere lesing bør være overkommelig, men jeg har ikke tid til det så her er noen lenker for den som ønsker å begi seg ut på den øvelsen.

 

Som nevnt på wiki er bufferstørrelser et problem med denne denne modellen da en ofte antar uendelig buffer, som selvfølgelig ikke er riktig. Det kan gi dårlig modellering ved store QD.

 

Et alternativ er å lage en programsnutt som visualiserer hvordan jobbene flyter rundt i en SSD. Husker vi lagde noe slikt på NTNU for å visualisere hvordan et OS på en server jobbet med websider. Da kan en justere buffer størrelser båndbredde og forsinkelse i systemet mens en ser hvordan ting flyter. Kanskje noe Altinn burde vurdert...

 

 

Generelt:

http://en.wikipedia....Queueing_theory

 

Mer eksakt litteratur for å lage matematisk modell:

http://en.wikipedia....Fork-join_queue

Endret av Anders Jensen
  • Liker 3
Lenke til kommentar
Nizzen

Nizzen

Skrevet
Skrevet

Har lest alt av tester i dag jg har funnet, og er like skeptisk nå som før jeg begynte å lese tester av Vertex 4. Det MÅ liksom være noe galt med OCZ uanestt. Nå er det Sekvensiell lesehastighet ved lav QD som er problemet. Og noen andre småproblemer med.f.eks høyt strømforbruk ved idle.

 

Det med "elendig" sekvensiell lesehastighet ved lv QD er jo ofte ganske viktig. Spennende å se om dette blir tunet anneledes eller "fixet" i en ny firmware. OCZ har allerede uttalt til Anandtech at ting skal fixes i ny firmware.

Igjen så OCZ litt tidelig ute med å slippe en ssd synes jeg. Blir nok flere firmware oppdateringer ja. Acc time er jo hinsides bra! Men alikevel skeptisk :p

 

JEg lærer nok ikkje, og må teste noen i raid uansett. Vertex 3 maxiops er jeg forresten veldig fornøyd med og kjører dem fast i raid-0 på en av hovedmaskinene. Vertex 4 med toggle nand blir nok en vinner :D

 

For akkurat ett år siden hadde jeg 4 stk vertex 3, altså rett før påske. 2 av dem solgte jeg på TG, for deretter kjøpe V3 MI en liten stund etterpå :p

 

Akkurat nå kan man ikkje sette verdensrekord med V4 i pcmark Vantage ser det ut som :D Elendige resultater.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste
×
×
  • Opprett ny...