SSD: thread generale e consigli per gli acquisti

[s12a]

Originariamente inviato da cricchio974

Scusate ragazzi.. Meglio mx100 mx200 (che differenze hanno?) oppure meglio samsung se costa poco di più?

L'MX200 è più recente dell'MX100. Ha più endurance dichiarata rispetto al precedente, ha un sistema di caching delle scritture che in teoria dovrebbe migliorare le prestazioni effettive. Prestazionalmente parlando il Samsung 850 EVO dovrebbe andare un po' meglio.

Originariamente inviato da mark1000

come lo giudicate voi questo ssd HyperX 3K SSD, 240 GB lo ha preso un amico e mi ha chiesto (dopo averlo preso) se era valido ma non lo ho mai sentito

Se è la versione '3K' e non HyperX Fury oppure HyperX Savage, È un un SSD con tipico controller Sandforce un bel po' datato. Alte velocità nel sequenziale con dati comprimibili, ma tempi di risposta e prestazioni nel random (in generale) e con dati non comprimibili mediocri.

Originariamente inviato da paolomarino

dove trovo l'informazione dei cicli di scrittura fatti e massimi ?

ecco cosa mi dà cristaldiskinfo:

Credo che il tuo SSD non fornisca direttamente questa informazione. Puoi solo fidarti del generico 'SSD Life Left' che al momento è ancora al 100%. Se hai uno dei primi Vertex 2 dovrebbe avere memorie da 34nm e 5000 cicli di scrittura. A spanne, vedendo il parametro E9 che rappresenta le scritture effettuate sulle memorie (scritture NAND) dopo la compressione dati, in GiB, devi aver effettuato 39744 GB di scritture. Questo dovrebbe corrispondere, considerando una capienza reale di 192 GiB (incluso l'overprovisioning non accessibile), di 39744/192 = 207 cicli di scrittura (dunque in teoria la vita rimanente dovrebbe essere sotto al 100%, dando per assunto che si basi sui cicli di scrittura e non su altro - ad esempio il numero di blocchi di riserva disponibili).

[mark1000]

Originariamente inviato da s12a

L'MX200 è più recente dell'MX100. Ha più endurance dichiarata rispetto al precedente, ha un sistema di caching delle scritture che in teoria dovrebbe migliorare le prestazioni effettive. Prestazionalmente parlando il Samsung 850 EVO dovrebbe andare un po' meglio.


Se è la versione '3K' e non HyperX Fury oppure HyperX Savage, È un un SSD con tipico controller Sandforce un bel po' datato. Alte velocità nel sequenziale con dati comprimibili, ma tempi di risposta e prestazioni nel random (in generale) e con dati non comprimibili mediocri.
.

grazie, è un HyperX Fury

[alethebest90]

Ragazzi un consiglio a volo cortesemente

il sandisk ultra 2 da 240gb come si comporta rispetto a 850 evo ed mx200 ??

ha il controller Marvell 88SS9190

e questi sono i dati dichiarati dall'azienda

Sequential Read 550MB/s
Sequential Write 500MB/s
4KB Random Read 91K IOPS


grazie in anticipo

[s12a]

Lo HyperX Fury è a 3/4 fra il V300 e lo HyperX 3k; è sempre dotato di controller SF2281. Probabilmente dalla sua avrà il firmware con gli ultimi bugfix del controller.

Originariamente inviato da alethebest90

Ragazzi un consiglio a volo cortesemente

il sandisk ultra 2 da 240gb come si comporta rispetto a 850 evo ed mx200 ??

Un SSD "onesto" che non sembra eccellere particolarmente specie con letture e scritture contemporanee (es: http://www.tweaktown.com/reviews/679...ew/index6.html ). Costa generalmente troppo per quello che offre a mio parere. Usa memorie TLC SanDisk, a proposito. Come per i Samsung Evo, le velocità in scrittura dichiarate sono solo per brevi durate grazie ad un buffer interno SLC.

[alethebest90]

Originariamente inviato da s12a

Lo HyperX Fury è a 3/4 fra il V300 e lo HyperX 3k; è sempre dotato di controller SF2281. Probabilmente dalla sua avrà il firmware con gli ultimi bugfix del controller.


Un SSD "onesto" che non sembra eccellere particolarmente specie con letture e scritture contemporanee (es: http://www.tweaktown.com/reviews/679...ew/index6.html ). Costa generalmente troppo per quello che offre a mio parere. Usa memorie TLC SanDisk, a proposito. Come per i Samsung Evo, le velocità in scrittura dichiarate sono solo per brevi durate grazie ad un buffer interno SLC.

ok grazie

l'ho preso in considerazione solo per l'offerta che fa amazon a 89€

sono in dubbio su questo o sul crucial mx200

[s12a]

Quello che intendo è che secondo me quell'Ultra II non vale 89 euro.

[alethebest90]

Originariamente inviato da s12a

Quello che intendo è che secondo me quell'Ultra II non vale 89 euro.

ah ottimo ! ed io che pensavo che fosse un ottimo prezzo

vabbe dai allora passo...sei stato gentilissimo

[s12a]

Originariamente inviato da alethebest90

ah ottimo ! ed io che pensavo che fosse un ottimo prezzo

In assoluto non è un buon prezzo, ma dopo aver controllato per sicurezza su trovaprezzi, ho notato che i prezzi degli SSD sembrano essere aumentati in generale. A meno (spedito) di quella capienza o giù di lì (240-250-256 GB) effettivamente sembra esserci solo il Kingston V300, al momento.

[alethebest90]

Originariamente inviato da s12a

In assoluto non è un buon prezzo, ma dopo aver controllato per sicurezza su trovaprezzi, ho notato che i prezzi degli SSD sembrano essere aumentati in generale. A meno (spedito) di quella capienza o giù di lì (240-250-256 GB) effettivamente sembra esserci solo il Kingston V300, al momento.

si infatti ricordo che un 840 evo e un m550 l'anno scorso si trovavano anche a meno rispetto a quelli di oggi

forse era anche l'effetto svuotamento di magazzino

[s12a]

C'entra nulla con il discorso, ma ho quasi completato le funzionalità base dell'emulo di CrystalDiskMark per Linux

[devil_mcry]

Complimenti

[s12a]

Originariamente inviato da devil_mcry

Complimenti

Ho provato a fare un confronto con i benchmark che feci appena preso il SanDisk Extreme II. CrystalDiskMark versione originale usa i MB/s (1 megabyte = 1000 kilobyte), mentre ASSSD i MiB/s (1 megabyte = 1024 kilobyte). La "copia" che ho fatto usa i MiB/s (1 megabyte = 1024 kilobyte). Pensavo ci fosse qualche problema con questo sistema operativo dato che i valori in lettura dal Samsung 830 64GB erano un po' sotto tono, ma evidentemente mi sbagliavo, anzi sembra andare pure meglio qui il SanDisk, usando la stessa metodologia di test di CrystalDiskMark.

[paolomarino]

Originariamente inviato da s12a

Credo che il tuo SSD non fornisca direttamente questa informazione. Puoi solo fidarti del generico 'SSD Life Left' che al momento è ancora al 100%. Se hai uno dei primi Vertex 2 dovrebbe avere memorie da 34nm e 5000 cicli di scrittura. A spanne, vedendo il parametro E9 che rappresenta le scritture effettuate sulle memorie (scritture NAND) dopo la compressione dati, in GiB, devi aver effettuato 39744 GB di scritture. Questo dovrebbe corrispondere, considerando una capienza reale di 192 GiB (incluso l'overprovisioning non accessibile), di 39744/192 = 207 cicli di scrittura (dunque in teoria la vita rimanente dovrebbe essere sotto al 100%, dando per assunto che si basi sui cicli di scrittura e non su altro - ad esempio il numero di blocchi di riserva disponibili).

Ti ringrazio molto

[Mike73]

Originariamente inviato da Growan

Oggi Babbo Natale ha portato tanti regali, compreso questo

Mi sa che non aspetterò l'aerografia, ed in questa settimana che viene cercherò di montare tutto (dato che ne devo fare 2), e lo proverò; sono troppo curioso

mhmmm mi prudono le mani.. ce l'ho sulla scrivania e non lo posso provare

[killeragosta90]

Originariamente inviato da Growan

Oggi Babbo Natale ha portato tanti regali, compreso questo

Mi sa che non aspetterò l'aerografia, ed in questa settimana che viene cercherò di montare tutto (dato che ne devo fare 2), e lo proverò; sono troppo curioso

Bella bestia! Si attendonno test e pareri personali

[mtofa]

Originariamente inviato da s12a

C'entra nulla con il discorso, ma ho quasi completato le funzionalità base dell'emulo di CrystalDiskMark per Linux

Bravissimo! Praticamente con Python hai creato l'interfaccia grafica al tool che hai citato?

[s12a]

Originariamente inviato da mtofa

Bravissimo! Praticamente con Python hai creato l'interfaccia grafica al tool che hai citato?

Esattamente; è comunque pensato per essere usato in maniera automatizzata, perché digitare a mano quello che serve per fare un singolo test diventa assai tedioso. Questo è quanto uso per un test in lettura random con blocchi da 4kB su un file da 25MB:

fio --filename=DUMMYFILE --size=25M --bs=4k --iodepth=1 --numjobs=1 --rw=randread --ioengine=libaio --runtime=60 --direct=1 --prio=0 --startdelay=2 --group_reporting --name=seqtest --output-format=json

Quello che faccio mostrare sul programma non è che una minima parte di quello che permette di fare FIO. Ecco un esempio di output completo human-readable da riga di comando da parte di questo tool:

seqtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
Jobs: 1 (f=1)
seqtest: (groupid=0, jobs=1): err= 0: pid=20522: Sat Jun  6 18:58:45 2015
  read : io=25600KB, bw=22417KB/s, iops=5604, runt=  1142msec
    slat (usec): min=5, max=147, avg=11.39, stdev= 6.69
    clat (usec): min=1, max=1092, avg=163.72, stdev=29.55
     lat (usec): min=33, max=1145, avg=175.45, stdev=31.18
    clat percentiles (usec):
     |  1.00th=[   50],  5.00th=[  137], 10.00th=[  139], 20.00th=[  139],
     | 30.00th=[  151], 40.00th=[  157], 50.00th=[  169], 60.00th=[  171],
     | 70.00th=[  175], 80.00th=[  185], 90.00th=[  195], 95.00th=[  201],
     | 99.00th=[  215], 99.50th=[  223], 99.90th=[  298], 99.95th=[  402],
     | 99.99th=[ 1096]
    bw (KB  /s): min=22248, max=22288, per=99.34%, avg=22268.00, stdev=28.28
    lat (usec) : 2=0.02%, 50=0.97%, 100=0.78%, 250=98.06%, 500=0.14%
    lat (usec) : 750=0.02%
    lat (msec) : 2=0.02%
  cpu          : usr=4.91%, sys=9.47%, ctx=6418, majf=0, minf=7
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=6400/w=0/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=25600KB, aggrb=22416KB/s, minb=22416KB/s, maxb=22416KB/s, mint=1142msec, maxt=1142msec

Disk stats (read/write):
  sdb: ios=5003/0, merge=0/0, ticks=824/0, in_queue=820, util=82.16%

slat = latenza di invio, clat=latenza di elaborazione, lat = latenza totale (ossia il tempo di accesso)
in questo caso il valore medio era di 175.45 usec, ossia 0.175 ms. Con questo dato si potrebbe creare un "clone" di AS SSD facilmente.

E si possono anche creare workload misti in lettura/scrittura configurati in maniera molto specifica. Ma il mio scopo era avere qualcosa di semplificato e di facile/rapido utilizzo, simile ai tipici benchmark su Windows.

[paolomarino]

Originariamente inviato da Growan

Fase di montaggio iniziata

scusa il piccolo OT.
Ma che case è ?

[mtofa]

Originariamente inviato da s12a

Esattamente; è comunque pensato per essere usato in maniera automatizzata, perché digitare a mano quello che serve per fare un singolo test diventa assai tedioso. Questo è quanto uso per un test in lettura random con blocchi da 4kB su un file da 25MB:

fio --filename=DUMMYFILE --size=25M --bs=4k --iodepth=1 --numjobs=1 --rw=randread --ioengine=libaio --runtime=60 --direct=1 --prio=0 --startdelay=2 --group_reporting --name=seqtest --output-format=json

Quello che faccio mostrare sul programma non è che una minima parte di quello che permette di fare FIO. Ecco un esempio di output completo human-readable da riga di comando da parte di questo tool:

seqtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
Jobs: 1 (f=1)
seqtest: (groupid=0, jobs=1): err= 0: pid=20522: Sat Jun  6 18:58:45 2015
  read : io=25600KB, bw=22417KB/s, iops=5604, runt=  1142msec
    slat (usec): min=5, max=147, avg=11.39, stdev= 6.69
    clat (usec): min=1, max=1092, avg=163.72, stdev=29.55
     lat (usec): min=33, max=1145, avg=175.45, stdev=31.18
    clat percentiles (usec):
     |  1.00th=[   50],  5.00th=[  137], 10.00th=[  139], 20.00th=[  139],
     | 30.00th=[  151], 40.00th=[  157], 50.00th=[  169], 60.00th=[  171],
     | 70.00th=[  175], 80.00th=[  185], 90.00th=[  195], 95.00th=[  201],
     | 99.00th=[  215], 99.50th=[  223], 99.90th=[  298], 99.95th=[  402],
     | 99.99th=[ 1096]
    bw (KB  /s): min=22248, max=22288, per=99.34%, avg=22268.00, stdev=28.28
    lat (usec) : 2=0.02%, 50=0.97%, 100=0.78%, 250=98.06%, 500=0.14%
    lat (usec) : 750=0.02%
    lat (msec) : 2=0.02%
  cpu          : usr=4.91%, sys=9.47%, ctx=6418, majf=0, minf=7
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=6400/w=0/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=25600KB, aggrb=22416KB/s, minb=22416KB/s, maxb=22416KB/s, mint=1142msec, maxt=1142msec

Disk stats (read/write):
  sdb: ios=5003/0, merge=0/0, ticks=824/0, in_queue=820, util=82.16%

slat = latenza di invio, clat=latenza di elaborazione, lat = latenza totale (ossia il tempo di accesso)
in questo caso il valore medio era di 175.45 usec, ossia 0.175 ms. Con questo dato si potrebbe creare un "clone" di AS SSD facilmente.

E si possono anche creare workload misti in lettura/scrittura configurati in maniera molto specifica. Ma il mio scopo era avere qualcosa di semplificato e di facile/rapido utilizzo, simile ai tipici benchmark su Windows.

Ottimo lavoro, potresti inserirlo nel circuito software open source per linux.

[s12a]

Quando raggiungerà uno stato di completamento accettabile, senz'altro. Non che manchi molto, dato che il programma è piuttosto semplice ed il grosso del lavoro è compiuto da fio.