Dal Giappone un hard disk con 1 GB di memoria cache

[faber80]

effettivamente facendo 2 calcoli, nn so quanto convenga questa soluzione, in quanto

1. i dischi 2.5 arrivano finora a 320GB, e i costi nn sono proprio "leggeri"
2. la meccanica 2.5 non è performante quanto quella dei 3.5, anche con tutti gli accorgimenti, appena hai un pò di frammentazione lo noti.
3. nn ho ben capito se il modulo ram MANTIENE i dati allo spegnimento del PC (xkè se nn lo fa è già una ciofeca)
4. come già detto da qualcuno, questa soluzione permette di aiutare il disco SOLO nella ri-lettura di dati precedentemente immagazzinati nella ram, ma nn cambia la velocità di nuovi caricamenti
5. sappiamo tutti come evolve velocemente il mercato dei prodotti tecnologici: il SolidDisk sarà il futuro, con capienze enormi (è solo una questione di tempo (poco)), costi irrisori (dategli il tempo di diffondersi), latenze insignificanti, resistenza agli urti molto più alta dei classici hd meccanici, consumi ridotti

ergo.... in base a questo piccolo ragionamento, per me nn vale la candela;
attendo gli SSD

[ulisss]

Originariamente inviato da faber80

3. nn ho ben capito se il modulo ram MANTIENE i dati allo spegnimento del PC (xkè se nn lo fa è già una ciofeca)
ergo.... in base a questo piccolo ragionamento, per me nn vale la candela;
attendo gli SSD

non conserva i dati ... quindi serve solo a velocizzare l'accesso ai dati ...

[Nevermind]

A me par na strunzata.

I dischi da 2,5 poi sono molto meno preformanti normalmente.

LA velocità di scrittua alla fine è data dal disco puoi avere una cache grande come una casa ma il tempo è sempre quello.

[raptus]

La cache NON funziona solo come rilettura!!!
Il principio di funzionamento di una cache (p.es quella del micro) è di accedere ad un dato non troppo distante da quello richiesto. QUindi quando cerco un byte leggo tutta la pagina (p. es grande 8 byte).
Se questo è vero per i programmi, non lo è per i dati su memoria di massa!!!

E nessuno che pensa alla scrittura: questa sarebbe immediata!
CMQ soluzioni simili in passato si erano già viste, anche sui controller scsi raid.
Non so cosa succede con questo, ipotizzo però una piccola batteria tampone che continua a far girare il disco da 2e5" e lo ferma quando si può. (nessuno ci ha pensato?)

[filippo1974]

A parte che non ho ancora capito come questo affare intende gestire problemi di mancanza improvvisa di alimentazione, durante il trasferimento dei dati dalla RAM locale al disco fisso vero e proprio...

comunque questa soluzione nel suo complesso non è certo innovativa, né tantomeno "coraggiosa". Ricordo, qualche anno fa, che era uscito un "hard disk" che in realtà era una scheda con alcuni slot per SDRAM, più la logica di controllo e una batteria per tenere i banchi di RAM alimentati quando il PC era spento. L'interfaccia era una comune IDE.

Vantaggi: niente parti meccaniche, e quindi più performances e meno problemi di affidabilità.

Svantaggi: numero di slot limitati: considerate le limitate capacità dei singoli banchi di SDRAM del tempo, la capienza complessiva dell'aggeggio era estremamente limitata (qualche GB), almeno per gli standard degli HD odierni.

Ciao
Filippo

[Michelangelo_C]

Ok che può migliorare le prestazioni, ma non mi pare molto differente da dotare il PC di 1 GB di ram in più. A meno che non ci sia una batteria tampone che permette di scrivere i dati dalla cache del disco al disco stesso quando il PC viene spento.

[Cadavere]

Confermo quanto detto da raptus (tutto, compreso il piccolo circuito UPS inserito nel disco che nessuno ha neanche notato nel disegno).

Vorrei ricordare agli utenti distratti alcune "leggi" dei dischi fissi.
La velocità di un disco può essere aumentata o aumentando la densità dei dati scritti -più dati a parità di superficie o più piatti per aumentare la superficie-, o aumentando la velocità di rotazione del disco. Entrambe le soluzioni diminuiscono però la resistenza alle vibrazioni. Attualmente il modo più semplice per ridurre le vibrazioni di un di un disco è la sua miniaturizzazione, il che comporta anche a riduzione dei tempi di accesso -in un disco piccolo la testina deve fare un movimento minore-.
Quindi, analizzando queste problematiche abbiamo:
1) Dischi molto capienti -grande densità di dati e tanti piatti su cui scrivere- ma inesorabilmente LENTI.
2) Dischi poco capienti -principarlmente dovuta a piatti più piccoli- ma VELOCI.
3) Le vie di mezzo che tutti usiamo normalmente nei nostri pc "casalinghi" che di fatto non vanno bene per nessuno scopo.

I dischi da 2,5 sono lenti semplicemente perchè hanno la necessità di resistere MOLTO di più alle vibrazioni e devono consumare poco. Quindi l'alternativa migliore in quel caso è un disco che gira meno velocemente e sia più leggero (leggasi "meno piatti"). Una piccola ricerchina su internet vi permetterà di scoprire che i dischi da 15k da 3,5" hanno piatti con diametri solo leggermente superiori a quelli usati nei dischi per portatili.

Infine, vorrei chiarire che i "dischi novità" giapponesi di cui parla l'articolo esistono in commercio dal 2005. Il fatto che in europa non siano arrivati realmente è solo dipeso dal fatto che per noi tali dischi sarebbero inutili (con problematiche del tipo "dove posso mettere i miei 400gb di puntate dei simpson in un disco così piccolo???"). Il problema si potrebbe risolvere tranquillamente con un "economico" disco secondario da alcune centinaia di gb -magari esterno con interfaccia esata-.

P.S. Lo ridico perchè magari qualcuno nota solo i PS dei commenti: IL DISCO CONTIENE UN SISTEMA DI ALIMENTAZIONE AUSILIARIA CHE INTERVIENE IN CASO DI MANCANZA DI CORRENTE PER DARE IL TEMPO AL DISCO DI RIVERSARE LA CACHE SUL SUPPORTO MAGNETICO. I CONDENSATORI NEL DISEGNO OCCUPANO UN TERZO DEL DISCO, POSSIBILE CHE NESSUNO LI VEDE?

[Venice39]

Certo che hanno fantasia questi giapponesi, un uso alternativo dei vari componenti base del computer, ma alla fine cosa hanno creato la chimera del disco fisso?

Alla fine sempre un disco fisso è, quindi alla fine il rischio meccanico o magnetico c'e sempre, e un giga di ram non lo vai a sprecare per farci da tampone a 2,5 pollici, che gia di suo avra della cache a disposizione (8 o 16 mega).

Poi come soluzione è troppo stramba, il contenitore che racchiude tutta sta roba per smaltire il calore generata della ram, e dal disco fisso (e 2,5" arrivano a pieno carico a 55 -60 gradi), come si comportera? Nel contenitore saranno gia incluse due ventoline per ricambio dell'aria?

Certo è una gran bella idea, per smaltire i magazzini dai disci fissi da 40 e 60 giga ide a 4200 rpm.

Venice

[simona_70]

E' il classico uovo di colombo... unire i banale chip da 1gb ad un disco dotato classicamente di cache ridottissima (32mb è davvero poco)...
Ci penso da mesi e mi sono smepre chiesto come mai non ci aveva pensato nessuno.
Non sarebbe male anche una sorta di "adattatore" sul quale inserisci la ram che metti nel mezzo tra il sata della main board ed il sata sul disco fisso.

[raptus]

Chissà in RAI ZERO:

2Gb di ram ... LOL

[Aegon]

Secondo me il sistema non è tanto stupido. Come ha evidenziato qualcuno, la cache non serve solo alla ri-lettura dei dati, ma anche per le operazioni di lettura-scrittura.

1GB per tutto quello che si può fare forse è poco, tuttavia questa soluzione permette di:

- Tenere sulla cache il file di paging, pronto per la lettura ed in coda per la scrittura (per sistemi con poca ram migliora le prestazioni in maniera esponenziale).
- Consentire un processo di deframmentazione in background. Purtroppo questo dipende dal FS, altrimenti integrando l'algoritmo di defrag nel chip dell'hd si avrebbe una memoria di massa SEMPRE ordinata quasi in tempo reale.
- Velocizzare le operazioni di lettura/scrittura contemporanee (vedi P2P)
- Nei GIOCHI, l'accesso ai grossi files contenenti le textures sarebbe praticamente immediato <- ri-lettura dei dati.

Per chi non può permettersi un SSD non mi pare tanto male...

[k0nt3]

Originariamente inviato da Aegon

- Tenere sulla cache il file di paging, pronto per la lettura ed in coda per la scrittura (per sistemi con poca ram migliora le prestazioni in maniera esponenziale).

se quel giga di ram non fosse confinato all'HD non ci sarebbe bisogno di usare il file di paging forse

Originariamente inviato da Aegon

- Consentire un processo di deframmentazione in background. Purtroppo questo dipende dal FS, altrimenti integrando l'algoritmo di defrag nel chip dell'hd si avrebbe una memoria di massa SEMPRE ordinata quasi in tempo reale.

la deframmentazione dipende dal filesystem.. molti filesystem moderni usano tecniche per limitarla e ci riescono anche piuttosto bene (NTFS non è mai stato all'avanguardia sotto questo aspetto)

[Aegon]

Originariamente inviato da k0nt3

se quel giga di ram non fosse confinato all'HD non ci sarebbe bisogno di usare il file di paging forse

Se usi un sistema windows, il file di paging viene creato in ogni caso circa pari al doppio della ram. Non ho provato un sistema da 4GB, ma Windows è strutturato così..

Originariamente inviato da k0nt3

la deframmentazione dipende dal filesystem.. molti filesystem moderni usano tecniche per limitarla e ci riescono anche piuttosto bene (NTFS non è mai stato all'avanguardia sotto questo aspetto)

Lo so, infatti ho scritto "purtroppo dipende dal FS, altrimenti...". Se windows usasse algoritmi seri (vedi b+tree di reiser) non ci sarebbe bisogno del defrag :\
Volevano battere reiser4 con WinFS ma non son riusciti neanche a tirarlo fuori...

[k0nt3]

Originariamente inviato da Aegon

Se usi un sistema windows, il file di paging viene creato in ogni caso circa pari al doppio della ram. Non ho provato un sistema da 4GB, ma Windows è strutturato così..

in realtà è la dimensione massima che è circa il doppio della RAM (ma si può cambiare l'impostazione dal pannello di controllo), mentre la dimensione reale è molto minore (spero).
d'altra parte è vero che windows fa uso del file di paging anche quando c'è molta RAM libera (questione di politiche), ma io continuo ad essere dell'opinione che se quel giga di RAM fosse a completa disposizione del SO verrebbe sfruttato meglio

Originariamente inviato da Aegon

Lo so, infatti ho scritto "purtroppo dipende dal FS, altrimenti...". Se windows usasse algoritmi seri (vedi b+tree di reiser) non ci sarebbe bisogno del defrag :\
Volevano battere reiser4 con WinFS ma non son riusciti neanche a tirarlo fuori...

difficile che con WinFS volevano battere raiser4.. contrariamente a quello che si pensa WinFS non significa Windows FileSystem, ma bensì Windows Future Storage!
in sostanza il FileSystem sarebbe sempre stato NTFS in ogni caso, mentre WinFS doveva appoggiarsi ad esso per fornire un interfaccia al FS (il tutto era implementato facendo girare una versione light di MS SQL Server).
se proprio si può paragonare a nepomuk, con la differenza che nepomuk funziona

[Dott.Wisem]

Originariamente inviato da Aegon

Se windows usasse algoritmi seri (vedi b+tree di reiser) non ci sarebbe bisogno del defrag :\

Veramente, anche NTFS usa i b+tree come struttura dati per mantenere le informazioni sui file memorizzati su disco.

La frammentazione del disco è un fenomeno fisiologico e non può essere eliminata. Al massimo si può tentare di arginarla usando delle tecniche di scrittura ritardata.

Comunque io, relativamente al discorso della frammentazione, non mi preoccuperei tanto dei file grossi frammentati in più pezzi (poiché qualunque file system decente, cerca di trovare il più piccolo insieme di blocchi contigui atti a contenere il file, prima di scriverlo), quanto piuttosto della miriade di file piccolini ai quali le applicazioni accedono spesso in maniera consecutiva, che, se salvati in posizioni molto distanti nell'hard disk, possono portare ad un degrado notevole delle performance. Anche in questo caso una scrittura ritardata può aiutare molto (si potrebbero considerare i file scritti a breve distanza di tempo l'uno dall'altro, come se facessero parte di un unico insieme di blocchi contigui).
Un altro problema è quello dello streaming: se io apro un file in scrittura e ci inizio a scrivere dentro, si pone il problema che il sistema operativo non sa a priori quanto sarà grande questo file (si pensi ad esempio all'acquisizione in real-time di un filmato). Come si deve comportare il sistema operativo, in questi casi? Quanti blocchi contigui deve allocare per il file, se non sa ancora quale sarà la sua dimensione finale? Anche in questo caso, una scrittura ritardata può aiutare molto, ma si tratta pur sempre di un palliativo.

Volevano battere reiser4 con WinFS ma non son riusciti neanche a tirarlo fuori...

Stando a questi benchmark, reiser4 non sembra poi sto granché...

[bist]

Originariamente inviato da k0nt3

se proprio si può paragonare a nepomuk, con la differenza che nepomuk funziona

Start date 01. January 2006
End date 31. December 2008

Come fa a funzionare se non è ancora uscito.

[k0nt3]

Originariamente inviato da bist

Start date 01. January 2006
End date 31. December 2008

Come fa a funzionare se non è ancora uscito.

perchè a ottobre (o meglio novembre) sarà incluso in kde4, ma già adesso funziona nella beta1 (solo che le applicazioni che lo usano si contano sulle dita di una mano di un falegname)

[matteoscor89]

lo ritengo inutile come hanno detto molti...quando avvii il pc questo non ti fa risparmiare, se apri un programma mai aperto prima il tempo non cambia(anzi peggiora visto che è un disco da 2,5)...

quindi me sembra na strunzata...

[infopaperino]

Ok.. ottimi questi hard disk ma, che sia una novità assoluta mi viene da ridere e anche hwupgrade ha preso una bella cantonata.
Seguo il programma "Certified by Intel" in Italia e sono già disponibili notebook che ho testato personalmente con questo Giga di memoria cache.
L'implementazione è hardware e funziona benissimo, le prestazioni sono ottime e i consumi di corrente del notebook si abbattono.
Cercate su Google con chiave "Verified by Intel®" filtrando le pagine in italiano... avrete le indicazioni dei notebook di cui vi parlo.

Più avanti i Giapponesi o gli Italiani ??? :-)

[infopaperino]

Ops... si è incasinata la scritta... la chiave era
Verified by Intel®