Nuovo SSD SATA II 2.5 pollici 192GB da Transcend

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/storage...end_28114.html

Transcend presenta un nuovo SSD di 192GB, con prestazioni interessanti sia in lettura che in scrittura

Click sul link per visualizzare la notizia.

[Paganetor]

Alla fin fine mi sa che il grosso di questi SSD lo fa il controller interno, visto che le memorie sono comuni "flash" che possono essere gestire in parallelo migliorando le performance in lettura/scrittura e ridistribuendo i cicli di scrittura su tutte le celle per allungare la vita utile...

[Aenor]

direi che qeust 192 GB sono proprio una spesa giustificabile, sisi.. incomprensibile acquistare adesso imho

[filippo1980]

Il prezzo mi sembra un po' eccessivo... qalche tempo fa non era uscito un articolo su un SSD della Intel con prestazioni nettamente migliori (se non sbaglio 210 mb/s in lettura e 170 mb/s in scrittura) allo stesso prezzo? Sempre se non vado errato l'unica "differenza" era nella capienza visto che erano "solo" 128 gb...
Penso che al momento, comunque, la capienza sia l'ultimo dei problemi...
Per chi ha bisogno di grandi quantità di storage le soluzioni "normali" sono ancora troppo convenienti... questi SSD servono a gestire il SO e poco altro (IMHO) e a questi prezzi difficilmente riusciranno a coprire una grossa fetta del mercato consumer...

[superbau]

per me dovremo aspettare i nuovi sataIII o come si chiamano per vedere il grande passo di massa

[Spacio]

ma se si mettono 2 raptor da 74 in raid 0 non vanno più rapidi e spendi intorno ai 200 euro?

EDIT: mi ero dimenticato che questo è da 2.5 scusate

[marchigiano]

Originariamente inviato da Paganetor

Alla fin fine mi sa che il grosso di questi SSD lo fa il controller interno, visto che le memorie sono comuni "flash" che possono essere gestire in parallelo migliorando le performance in lettura/scrittura e ridistribuendo i cicli di scrittura su tutte le celle per allungare la vita utile...

è lo penso pure io... a questo punto sarebbe meglio fare un controller buono costoso ma con chip memoria intercambiabili così la spesa si ammortizza nel tempo, perchè altrimenti uno oggi si compra un intel, spende un botto poi dovrà rispendere quando avrà bisogno di più capacità...

Originariamente inviato da Spacio

ma se si mettono 2 raptor da 74 in raid 0 non vanno più rapidi e spendi intorno ai 200 euro?

i raptor non hanno un seek medio di 0,1-0,5ms...

[Spacio]

Originariamente inviato da marchigiano

i raptor non hanno un seek medio di 0,1-0,5ms...

Giusto anche questo è vero, però boh il prezzo mi sembra ancora troppo alto, secondo me ancora il gioco non vale la candela, poi magari ad alcune persone in alcuni ambiti può essere fondamentale avere un seek time così basso, ma per una diffusione di massa 500+ euro per meno di 200 GB ancora non mi sembra l'ideale

[SwatMaster]

Originariamente inviato da filippo1980

Il prezzo mi sembra un po' eccessivo... qalche tempo fa non era uscito un articolo su un SSD della Intel con prestazioni nettamente migliori (se non sbaglio 210 mb/s in lettura e 170 mb/s in scrittura) allo stesso prezzo? Sempre se non vado errato l'unica "differenza" era nella capienza visto che erano "solo" 128 gb...
Penso che al momento, comunque, la capienza sia l'ultimo dei problemi...
Per chi ha bisogno di grandi quantità di storage le soluzioni "normali" sono ancora troppo convenienti... questi SSD servono a gestire il SO e poco altro (IMHO) e a questi prezzi difficilmente riusciranno a coprire una grossa fetta del mercato consumer...

Quoto. Poi c'è anche da mettere in conto che questi gingilli soffrono ancora di problemi di gioventù non indifferenti. Leggevo prima una notizia a proposito su Tom's proprio riguardo gli SSD Intel.

[CUBIC84]

Il prezzo è troppo alto e la capacita è bassa... Passeranno, non so, 2-3 anni prima che i dischi di questo tipo comincino a diventare appetibili...

[s12a]

Per raggiungere i prezzi degli hard disk mainstream e da storage probabilmente, ma secondo me entro un anno quelli buoni, come rapporto euro/GB, diventeranno concorrenti diretti di hard disk come i Velociraptor. Io personalmente aspetto che SSD veloci dalla capacita` compresa fra i 60 e gli 80 GB raggiungano i 2 euro/GB; a quel punto molto probabilmente ne prendero` uno per i programmi ed il sistema operativo relegando l'hard disk da 640 GB al resto dei dati.

In ogni caso c'e` ancora molto da lavorare su controller, firmware, e soprattutto supporto del sistema operativo con un file system ed una gestione di tutto il resto ottimizzati ad hoc (ma se neanche su Linux, per quello che ne sappia, c'e` ancora qualcosa del genere, di strada ancora ce ne vuole). Se gli SSD ad esempio avessero modo di conoscere meglio la struttura e la disposizione dei dati in input potrebbero lavorare con piu` efficienza e sicurezza.

Programmi di terze parti come MFT che lavorando a basso livello danno un boost in scrittura e salvaguardano le celle di memoria degli SSD trasformando blocchi di dati da casuali a sequenziali non fanno altro che quello che dovrebbero fare file system, OS e SSD progettati per lavorare in sintonia fra loro.

[rockroll]

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...

[rockroll]

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...

[rockroll]

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...

[rockroll]

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...