View Full Version : A-Data S596, SSD con controller JMicron JMF612
Redazione di Hardware Upg
30-10-2009, 07:34
Link alla notizia: http://www.hwupgrade.it/news/storage/a-data-s596-ssd-con-controller-jmicron-jmf612_30594.html
Sebbene non ancora annunciati ufficialmente, A-Data presenterà una famiglia di Solid State Drive con il nuovo controller JMicron 612
Click sul link per visualizzare la notizia.
il fatto che l'azienda abbia fatto un buco nell'acqua con il controller 602 non significa chene debba far altri....alla fine tutte e ripeto tutte le aziende han avuto i loro fiaschi, l'importante è che imparino dai loro errori... :D
Sig. Stroboscopico
30-10-2009, 07:48
Il problema è che una volta bruciati la concorrenza è molto favorita e gli acquirenti prevenuti.
Speriamo in un taglio del prezzo e in una maggiore concorrenza.
Ciao
Human_Sorrow
30-10-2009, 07:48
".. 250MB al secondo in lettura e 180MB al secondo in scrittura .."
2 da 64GB in RAID 0 mi renderebbero molto felice !!! :D :D
Non credo che JMicron abbia fatto un buco nell'acqua, viste le migliaia di SSD dotate del pessimo 602. Tuttavia, il costo di questo controller è contenuto e permette ai produttori di SSD di essere particolarmente aggressivi sul prezzo.
Vista la poca esperienza degli utenti, fisiologica per un settore al debutto, perché non fare una bella operazione di marketing su vasta scala? Tanto, finché il pubblico non percepisce la trombata in agguato, si vende.
interessante, a-data ha quasi sempre prezzi molto competitivi.
avvelenato
30-10-2009, 08:27
Il buco nell'acqua l'ha fatto in quanto chi spende centinaia di euro per un prodotto che anziché risolvere problemi e regalare soddisfazioni, crea problemi e regala frustrazioni, si ritroverà più restìo ad osare, in futuro. E probabilmente eviterà il brand anche se si rivelasse prestazionale ed economicamente concorrenziale. Non siamo macchine razionali e un certo grado di fanboysmo, di affettività o disaffettività nei confronti delle aziende, è prevedibile e neanche tanto sbagliato.
Detto questo, jmicron pagherà il suo errore, in quanto per incoraggiare le utenze a non diffidare più dei suoi prodotti, dovrà offrire un ottimo controller ad un ottimo prezzo, a costo di rimetterci un po' di margine. E a vantaggio di tutte le persone razionali che non si lasceranno influenzare dal trascorso.
per me più dei "buchi nell'acqua" fatti dalle aziende mi interessano i risultati! se l'SSD con il 612 jmicron è prestante non ha alcuna importanza se quelli di prima facevano pena! stesso discorso vale tra Intel e AMD...il giorno che AMD (come già successo negli anni) supererà Intel io venderò solo il processore migliore aldilà della marca...
magilvia
30-10-2009, 09:05
2 da 64GB in RAID 0 mi renderebbero molto felice !!!
mmm guarda, al momento nessun controller RAID è in grado di passare il comando TRIM quindi meglio lasciar perdere il RAID. Io sarei molto felice anche con uno solo di questi :D :D
AceGranger
30-10-2009, 10:10
Non credo che JMicron abbia fatto un buco nell'acqua, viste le migliaia di SSD dotate del pessimo 602. Tuttavia, il costo di questo controller è contenuto e permette ai produttori di SSD di essere particolarmente aggressivi sul prezzo.
Vista la poca esperienza degli utenti, fisiologica per un settore al debutto, perché non fare una bella operazione di marketing su vasta scala? Tanto, finché il pubblico non percepisce la trombata in agguato, si vende.
per un semplicissimo fatto: fu la prima e unica per un periodo di tempo a distribuire controller per SSD; l'altra era Intel, ma non vendeva il suo controller, ma semplicemente vendea il disco completo che veniva rimarchiato da Corsair e Kingston;
Di fatto ha fatto eccome un buco nell'acqua, visto che attualmente ovunque si parli di SSD Jmicron = Peste;
non appena sono usciti i controller Indilinx e Samsung è stato subito abbandonato da tutte le case produttrici serie;
mmm guarda, al momento nessun controller RAID è in grado di passare il comando TRIM quindi meglio lasciar perdere il RAID. Io sarei molto felice anche con uno solo di questi :D :D
Gli SSD con controller Indilinx possiedono anche il GC, che permette loro di Autotrimmarsi; praticamente se ti disconnetti dal SO il controller inizia da solo a ripulire il disco; la differenza è che con il comando TRIM la pulizia la fai in 5 secondi su tutto il disco, mentre con il GC il controller fa un pezzo per volta; è stato fatto apposta per i RAID e per i SO che non supportano il TRIM; di fatto con questo sistema ottieni li stessi risultati del TRIM
Io ho due SSD OCZ con il tristemente famoso controller JMicron 602 in raid 0, e' vero che di tanto in tanto si notano rallentamenti in scrittura, ma la cosa non e' affatto cosi' frequente e cosi' drammatica.
Alla fine con 100 euro ho 60 GB di disco di sistema perfettamente silenzioso, fa il boot in meno di 20 secondi, quando appare il desktop e' immediatamente funzionante senza alcun rallentamento, posso lanciare piu' programmi in rapida sequenza e si aprono istantaneamente senza esitazione, insomma rifarei subito l'acquisto.
Considerate che precedentemente come disco di sistema usavo un Velociraptor 300 GB e il salto di qualita' e' vistoso gia' con degli SSD considerati "scadenti".
Se adesso mi dicono che il nuovo controller risolve anche quei rari problemi che ho riscontrato... ben venga!
tengo famiglia
31-10-2009, 17:03
Una seconda chance se la meritano. Tutti ce la meritiamo quando sbagliamo. Se poi sbagliano anche la seconda...beh questo è un'altro discorso.
ArteTetra
31-10-2009, 23:34
250MB al secondo in lettura e 180MB al secondo in scrittura
Ma checcefrega dei sequenziali? :muro:
Sono le letture/scritture random e i tempi di accesso che contano veramente.
quoto Enrox
io ho l'ssd samsung da 256 gb sul mio notebook.
con su xp e la cache del disco attiva i valori che rilevano in scrittura sono molto differenti da quelli che si vedono nei bmk, tanto è vero che in scrittura a 4 k (il valore ufficialmente peggiore) scrive a 10 MB/s mentre in sequenziale viaggia tra i 35 e i 45 MB/s
NON ho usato dei bmk trovati su internet, ma vi spiego cosa ho fatto:
la partenza è una macchina XP sp2, con 2GB di ram, processonre core 2 due 2.8 GHz (ha giusto giusto due anni adesso), l'HD è quasi pieno (ha 6 mesi e rimangono liberi una decina di GB, quindi tutte le celle sono state sfruttare da tempo, e NON ho alcun programma per fare il TRIM)
la cache su SSD è abilitata, mentre ho azzerato la memoria virtuale per espandere la RAM (non mi serve a niente e massacra l'SSD per niente).
ho scritto un programma in VC++ che crea un file da 2.000 MB(1024*1024),
lo scrive con una senquenza di 2000 write da 1MB l'una. il buffer viene ogni volta modificato di modo da evitare possibili ottimizzazioni da parte di qualche cache.
la velocità media di scrittura è di 35 MB/s, talvolta è anche meglio.
poi faccio un ciclo di 50.000 volte con un buffer da 4KB posizionandomi random nel file (ma sempre allineato a 4KB in modo da non coinvolgere più celle del necessario)
qui la velocità scende a 8-9 MB/s, quindi ben distante dagli OCZ (che dovrebbero essere la stessa roba) ma che nei bmk dicono che scriva meno di 2MB/s
in lettura invece ci sono due situazioni ben distinte
1) se la memoria RAM è disponibile, xp fa un'ottimizzazione incredibile: anche se vi fa vedere che la ram usata in task manager è sempre la stessa (io viaggio sui 400mb con messenger e vc++ aperti) in realtà ha lasciato in cache quasi tutto il file da 2GB che ho appena scritto, al punto che le letture random da 1MB e da 4KB si vedono medie di lettura da 2 a 4GB/s, valori impossibili per il sata e che dimostrano la lettura dei files direttamente da RAM. a conferma il led dell'HD non lampeggia quasi per nulla (forse solo per quelle centinaia di mb che non ci sono state sulla RAM)
2) sconcertato da questi dati ho fatto un'altra prova, allocado nello stesso processo quasi tutta la ram dispobibile nel sistema, e qui le cose hanno ricominciato ad avere senso:
le velocità di scrittura è rimasta identica, mentre le velocità di lettura sono finaalmente scese a volori più ragioonevoli: 80MB/s leggendo blocchi da 1MB l'uno e 42MB/s per blocchi da 4KB.
le conclusioni che ne traggo sono le seguenti:
nell'utilizzo normale le penalizzazioni che si vedono nei bmk sono quasi ininfluenti.
la caduta di prestazioni la vediamo solo in scrittura sequenziale, se dobbiamo copiare grosse moli di dati: qui anche un HD 2.5 ha potenzialmente la meglio.
personalmente credo sia uno scenario anomalo quello delle grosse moli di dati per gli SSD che mediamente viaggiano su valori di GB tutto sommato modeste....
diciamo che in alcune situazioni il mio ssd viaggia, alla peggio come il vecchio 320gb-7200rpm, ma per il resto è nettamente superiore e lo dimostra in tutte le situazioni con una fluidità ed una rapidità sconosciute ai dischi tradizionali da 2.5
probabilmente queste performance sono bissate da ssd di qualità superiore come intel (che cmq dichiara velocità max in write di 70mb, adesso estesa a 100 via patch), ma nella pratica di tutti i gg la vedo difficile notare grosse differenze.
tenete conto, almeno in ambito notebook, che non sono sicurissimo che il collo di bottiglia sia sempre l'ssd quanto piuttosto bus, proc etc...
cmq, se qualcuno vuol darmi un ssd intel per eseguire gli stessi test per me va bene lo stesso ;)
ah, anche altra piccola controprova:
ho il macbookair su chi avevo montato con parallels una macchina 2003 con alcuni programmi e antivirus NOD32. lo scan sulla macchina 2003 durava circa 1' e 50"
poi ho preso il macmini server, che ha un proc a 2.5 GHz invece che a 2.2 e il doppio di ram (quindi peggio non può andare), ci ho messo la stessa immagine di 2003, eppure il tempo di scan è oltre il doppio !!
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.