Newsgroup: it.comp.hardware.storage
Titolo: M4: degrado prestazioni QD=32 nei benchmark

Non sto sempre a fare benchmark, anzi da quando l'avevo acquistato l'ho
fatti solo due volte: all'acquisto appunto e poi all'aggiornamento del
firmare con la versione 390 a gennaio. E sempre tutto ok.
 
Ora li ho rifatti prima e dopo aver aggiornato il firmware all'ultima
versione 000F (per altro complessivamente leggermente meno performante
della precedente), ma con mia grande sorpresa ho notato che, anche con la
versione 309 che a gennaio era ok, il mio M4 ha dimezzato le prestazioni
con CrystalDiskMark e AS SSD (risultati identici), ma solo in random read
qd=32 e in random write qd=32 (da circa 310 in lettura a circa 150 e 80,
valori medi).
 
Questo succede indipendentemente dal driver utilizzato (prestazioni uguali
sia con IAstor 10.8, sia con msahci).
 
Ecco un esempio di risultati prima e dopo che si palesasse questo problema:
 
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
                           Crystal Dew World : 
http://crystalmark.info/
 
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
 
           Sequential Read :   495.702 MB/s
          Sequential Write :   197.807 MB/s
         Random Read 512KB :   382.730 MB/s
        Random Write 512KB :   195.571 MB/s
    Random Read 4KB (QD=1) :    23.744 MB/s [  5796.9 IOPS]
   Random Write 4KB (QD=1) :    58.388 MB/s [ 14254.8 IOPS]
   Random Read 4KB (QD=32) :   281.655 MB/s [ 68763.5 IOPS]
  Random Write 4KB (QD=32) :   170.168 MB/s [ 41544.9 IOPS]
 
  Test : 1000 MB [C: 60.2% (71.8/119.2 GB)] (x5)
  Date : 2011/12/19 13:29:36
    OS : Windows 7 Ultimate Edition SP1 [6.1 Build 7601] (x64)
 
Ed ora ecco i valori attuali:
 
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
                           Crystal Dew World : 
http://crystalmark.info/
 
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
 
           Sequential Read :   506.803 MB/s
          Sequential Write :   195.102 MB/s
         Random Read 512KB :   388.102 MB/s
        Random Write 512KB :   190.871 MB/s
    Random Read 4KB (QD=1) :    27.929 MB/s [  6818.7 IOPS]
   Random Write 4KB (QD=1) :    76.042 MB/s [ 18565.0 IOPS]
   Random Read 4KB (QD=32) :   141.237 MB/s [ 34481.7 IOPS]
Random Write 4KB (QD=32) :   117.852 MB/s [ 28772.4 IOPS]
 
  Test : 1000 MB [C: 52.1% (62.1/119.2 GB)] (x5)
  Date : 2012/04/14 17:44:02
    OS : Windows 7 Ultimate Edition SP1 [6.1 Build 7601] (x64)
 
 
Come si vede, ottimi i risulati tranne che per il valori qd=32.
 
Ovviamente nell'utilizzo pratico non si nota nulla, tutto velocissimo come
sempre, ma vorrei capire cosa e' successo. Ho controllato i parametri e
NCQ, TRIM paiono ok. Allineamento perfettamente ok. Siccome l'unica
variabile cambiata da gennaio a ora e' stato un aggiornamento al bios del
notebook in oggetto (Asus K93SV), ho anche reinstallato la vecchia versione
del bios, ma nulla e' cambiato, comportamento identico con entrambe le
versioni del bios. 
 
Ho notato pero' una cosa stranissima. Quando passo da un driver all'altro e
ovviamente riavvio il sistema, al successivo riavvio, se eseguo
IMMEDIATAMENTE un test i risultati raddoppiano e tornano come erano prima
di questo problema! Ma se poi rifaccio il test, si dimezzano nuovamente e
restano dimezzati a vita, a meno che non rifaccia il giochetto del cambio
driver.
 
Questa cosa e' senza senso per me, e vorrei sapere se qualcuno, per esempio
2Fast, ha qualche idea in proposito, anche se non mi preoccupo piu' di
tanto visto che le prestazioni restano fantastiche e il problema non si
ripercuote nell'utilizzo massiccio del sistema.

 piu' di tanto visto che le prestazioni restano fantastiche
 
Non ho idea di che succeda, ma invece di preoccuparti gioisci: le 
prestazioni che contano sono tutte aumentate: a meno che tu non usi quel 
disco su un server, QD non arriverà mai a 32. Su un desktop il 98% del 
tempo QD sta fra 1 e 2, o al massimissimo 4. :)
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://www.worldcommunitygrid.org/index.jsp
 
http://www.rnaworld.de/rnaworld/
 
http://home.edges-grid.eu/home/
 
 
http://www.gpugrid.net/
 

 ripercuote nell'utilizzo massiccio del sistema.
 
dovresti provare a disabilitare la cache in scrittura e riabilitarla
(probabilmente si disattiva inspegabilmente ..)
 
ci sono diverse segnalazioni sul forum, non so se la soluzione
e' permanente e spiega il fatto che cambiando driver ottieni
momentaneamente le prestazioni ottimali
(al momento non posso fare prove, spero in settimana)
 
ad ogni modo e' possibile fare il downgrade al vecchio fw
(la procedura e' identica all'upgrade) , in attesa di ulteriori
informazioni e' meglio non aggiornare alla versione 000F
a meno che non si abbiano problemi da risolvere
 
ciao
luca
 

 tempo QD sta fra 1 e 2, o al massimissimo 4. :)
 
Quoto... uno scenario reale che usa un QD pari a 32 praticamente non 
verrà minimamente avvicinato, specialmente appunto in un contesto 
desktop :D
 
 


Ottimo consiglio quello di provare a disattivare e attivare la cache. Dopo
provo e ti dico.
 
Solo una piccola correzione, ma fose non mi sono spiegato bene io: il
problema era presente anche con il precedente firmware 309.

 (probabilmente si disattiva inspegabilmente ..)
 
Bravissimo, il problema e' esattamente questo. La disattivi, la riattivi,
fai due bench a piena velocita'. Poi al terzo si disattiva nuovamente.
Secondo te da cosa puo' dipendere? Ho guardato sul sito Crucial, ma forse
saro' poco attento io, non ho trovato nulla.


sono bravissimi sul sito Crucial, non io ;)
 
ho letto diverse discussioni ma a quanto pare e' stato solo diagnosticata
la causa e non la cura .. potrebbe essere una comunicazione errata tra il
chipset/driver ed il controller/firmware dell'SSD che induce il sistema 
operativo
a disabilitare la cache in scrittura, puo' avvenire anche dopo diversi mesi
(a quanto pare anche 6)
 
questo e' un vecchio thread sull'argomento:
http://forum.crucial.com/t5/Solid-State-Drives-SSD/low-4K-64K-with-AS-SSD/td-p/84448
 
 
mentre in quest'altra discussione e' spiegato come risolvere
(ma a quanto pare non e' permanente) :
http://forum.crucial.com/t5/Solid-State-Drives-SSD/Another-Crucial-M4-128GB-drive-with-Slow-4K64-Writes/td-p/92178
 
 
secondo me ti conviene aspettare la soluzione definitiva per
questo problema, non perder tempo con Secure Erase,
reinstallazioni, aggiornamenti BIOS, cavi, ecc..
 
concordo con Lem e Lorenz, nell'uso quotidiano non ti accorgerai della
differenza, pero' la scrittura random e' un punto di forza dei Crucial m4
ed e' giusto trovare una soluzione al problema, che sia tramite registry,
BIOS, driver, firmware o altro (?)
 
ciao
luca
 

 Secondo te da cosa puo' dipendere?
 
Non so, ma segnalo che con Linux la cache dell'M4 (firmware 0309) è 
regolarmente attiva:
 
lem@biggy:~$ sudo hdparm -W /dev/sda
 
/dev/sda:
 write-caching =  1 (on)


  write-caching =  1 (on)
 
Magari su Linux rimane sempre attiva...:)
 
 


c'e' anche da dire che le "lamentele" riguardano il modello da 128GB
 
Lem ha il 64GB (confermi ?) , mentre Ale (Intel), Loki (Intel) e BS82 (AMD)
hanno il 128GB , sono andato a memoria, eh ;)
 
ciao
luca
 

 Lem ha il 64GB (confermi ?)
 
Confermo.
 
Ho anche un Vertex3 da 60GB, ma quello è sul laptop.


 hanno il 128GB , sono andato a memoria, eh ;)
 
si ma sinceramente è un secolo che non faccio un bench :D ehhehhhe
 
io devo ancora aggiornare, al momento aspetto!
 

 Loki (Intel)
 
corretto.

  write-caching =  1 (on)
 
Pure a me e' apparentemente attiva, ma resta il fatto che dopo due o tre
test, qualche volta ne basta uno, le prestazioni del qd=32 si dimezzano.
Quindi bisognerebbe vedere se nel tuo caso le prestazioni qd=32 si
mantengono uguali.