Newsgroup: it.comp.hardware.cpu
Titolo: Conroe shows dodgy RAID performance anomalies

http://www.theinquirer.net/default.aspx?article=32818
-- 
Ciao mine
http://metropolis.blogs.com/
BMW 120d Attiva driver

 
http://www.theinquirer.net/default.aspx?article=32818
LOL il mio RAID5 rulez! :-P
-- 
Saluti
Alec (28,72+,CT)
Powered by AMD Athlon64 X2 5200+
Fueled by Sapphire X1800XT-OC
OnLine by Tiscali 12Mega 

 
http://www.theinquirer.net/default.aspx?article=32818
Problema di southbridge, credo, più che della piattaforma in sé. Chissà come 
si comporterà il chipset NVidia?
MaxArt 

SydneyBlue120d ha scritto:

Alla faccia di chi dice che i chipset Intel sono i migliori ;-)
Probabilmente è facilmente correggibile con un aggiornamento driver.
Da sempre tutti i chipset hanno i loro bug, senza eccezioni.
Fortuna vuole che per Conroe si può anche scegliere per un chipset Ati
o Nvidia.

 MaxArt



Potrebbe essere un problema al southbridge, l'ICH8.
In qualisiasi modo, è già bene che queste cose siano note prima dell'uscita, 
piuttosto che dopo..
A.CiD


Piu che un problema di southbridge ad occhio e croce c'entra
anche il driver software, questo perche l'implementazione RAID5
su quel chip e' "parzialmente in hardware".
Con una configurazione RAID5 con N dischi i dati vengono
appaiati in gruppi da (N-1) blocchi di dati "accoppiati"
con un blocco "di xor" che contiene lo xor degli N-1 blocchi
a cui e' associato (l'idea e' che si perde uno dei blocchi
"accoppiati" si prende il blocco "di xor", si fa lo xor
dei blocchi "sopravvissuti" ed il risultato e' il valore
del blocco "perso" che puo quindi essere ripristinato
altrove ecc. ecc.).
Il problema e' che se si scrive un dato:
1) *prima* di scriverlo effettivamente bisogna recuperare
    il blocco "di xor" corrispondente;
2) poi si fa lo xor del blocco "di xor" con i dati
    "vecchi" del blocco dati che si sta per scrivere
    (per eliminarli dallo xor cumulativo);
3) poi si fa fa lo xor con i dati "nuovi"
    (per inserirli nello xor cumulativo);
4) si scrive il blocco dati "nuovo";
5) si scrive il blocco dati "di xor".
Quindi se si vuole realizzare un implementazione
"tutta hardware" bisogna integrare sul controller RAID
un bel mucchio di ram
oppure (come fanno Intel ed altri con le implementazioni
"sul southbridge") si usa la ram del computer
come cache dei blocchi di xor e dei dati veri e propri
(magari con il supporto del S.O. se possibile
  in modo da evitare inutili duplicazioni dei dati).
Basta anche solo che il software non tenga conto
di alcune situazioni "improbabili ma possibili"
e quello che nei benchmark vola
(perche i benchmark simulano anche situazioni
  pessime ma mica le simulano tutte, senza contare
  che spesso vengono utilizzati per testare
  le prestazioni dei driver) poi nella vita reale
si ingolfa.
Nel caso dei Conroe, a  causa della cache L2 condivisa
se un core inizia a trashare la cache finisce pure
con il rompere le scatole all'altro core (con maggiori
cache miss, maggior utilizzo della cpu, maggior
traffico sull'FSB, ecc. ecc.) con conseguente maggior
overhead a carico di entrambi i core.
Con una "cache RAID" bella grossa e con molti dati
da leggere/aggiornare/scrivere (da/su cache e da/su disco)
vi potete immaginare il resto.
Anche con gli Athlon64 X2 con un driver con gli stessi
"difetti" potrebbe accadere una situazione simile, ma
visto che i core hanno cache L2 distinte l'unico punto
dove potrebbero esserci congestioni di traffico e' il
crossbar switch ma con conseguenze meno nefaste rispetto
al Conroe.
In ogni caso non e' un problema gravissimo
(se verra' risolto per tempo).
L. Micheletto


Piu che un problema di southbridge ad occhio e croce c'entra
