Newsgroup: it.comp.hardware
Titolo: Per chi ha detto che le RAMBUS hanno una pessima latenza...

 lettura casuale non c'è storia...
Sono STRONZATE, forse quei dati erano per le prime Rambus PC600, mentre per
le attuali PC800 i cicli di lettura e scrittura sono:
9-1-1-1-1R  7-1-1-1W 8/7 CL
(come ho potuto anche verificare con SiSoft Sandra che mostra le
impostazioni BIOS delle RIMM).


al solito sandra dimostra di non avere la piu' pallida idea di quello
di cui sta parlando, limitandosi a presentarti dei dati del tutto
privi di qualsiasi riferimento o spiegazione - sempre se sono dati
esatti...
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 denominatori di tutte le latenze).
Guarda che il bus del P4 va a 400Mhz ovvero 100 Mhz in QUAD PUMP (4x).
E le RIMM vanno a 800Mhz... quindi 9 cicli a 800Mhz sono roba da ridere...

 E le RIMM vanno a 800Mhz... quindi 9 cicli a 800Mhz sono roba da ridere...
Non sono nemmeno sicuro che siano 9 cicli (forse meno) perchè SiSoft Sandra
mi rileva anche "SAMSUNG MR16R 0828BN1-CK8 ... 129MB/8 (128X16) RDAM PC800
CL2-2 upto 411 Mhz"

"SAMSUNG MR16R 0828BN1-CK8 ... 128MB/8 (128MX16) RDRAM RIMM PC800 CL2-2 upto
411 Mhz"
Notare CL2-2

 E le RIMM vanno a 800Mhz... quindi 9 cicli a 800Mhz sono roba da ridere...
La frequenza del clock esterno è 100Mhz!!!!
...che poi i trasferimenti sul BUS vanno come se fosse un 400mhz è un'altra
faccenda...

 faccenda...
Appunto siccome il system_bus č in QUAD PUMP č esattamente a 400Mhz, ne piů
ne meno, non ci sono differenze prestazionali!

 ne meno, non ci sono differenze prestazionali!
Brain, se non ci credi chiedilo a Salmon...

 ha scritto nel messaggio
news:WPz_7.411$LO4....@news2.tin.it...

Dunque,il vantaggio della  tecnologia RAMBUS è evidente confrontando
la dimensione della matrice di memoria delle PC800 con quella ad esempio
di un normale modulo PC100: funziona a 128bit  e 100MHz contro i 64
bit del modulo PC100. La velocità di spostamento perciò è doppia, come
nel caso dei moduli DDR.
Se i 128bit fossero gestiti in modo tradizionale darebbero grossi problemi
pratici, perchè il connettore del modulo dovrebbe dimensioni esagerate;
quindi non praticabile.
Il protocollo Rambus adotta una soluzione elegante al problema: all'interno
del chipset un quadruplicatore di frequenza trasforma il bus a 128bit
e 100MHz in un bus a 16bit e 400MHz a doppio fronte.
Il bus inoltre è di tipo multiplexato poichè dati e indirizzi viaggiano
sulle stesse piste. Anche i segnali di controllo visggiano più velocemente
con maggiore efficienza rispetto alle Sdram; in questo modo il chipset può
mandare simultaneamente molte richieste di accesso a locazioni diverse
senza inutili attese, con evidenti vantaggi negli ambienti multitask come
Win2000 e Linux.
Questa veresatilità però ha un prezzo: infatti il processo di conversione
da 128 a 16bit richiede tempo. e questo fa aumentare la latenza
nel reperire il primo bit presente nella matrice di memoria, oppure
provoca una pausa ogni volta che la cpu inizia a accedere in locazioni
di memoria non usate. Inoltre il fenomeno è aggravato dal fatto che
il protocollo Rambus è di tipo seriale e non parallelo rispetto allo
standard
Sdram
Comunque questo handicap non è un problema in un ambiente dove
esiste un grande trasferimento di lunghe stringhe di dati, come per esempio
in un videogame, ma può appesantire il sistema in caso di transazioni
piuttosto piccole e frequenti.
Saluti.

Io ho 2 moduli RIMM da 128MB marchiati "SAMSUNG MR16R 0828BN1-CK8"
CK-8 significa che lavora a 800Mhz (PC800)
Il tempo di accesso del mio modulo ovvero il  tRAC (Row Access Time) č di 45
ns come ho potuto verificare dai datasheet della SAMSUNG (oltre che
direttamente dall'etichetta posta sul modulo RIMM)
Il link č
http://www.samsungelectronics.com/semiconductors/DRAM/Rambus_DRAM_RIMM/Norma
l_RIMM/Non-ECC/MR16R0828BN1/mr16r0824(6,8,c,g)bn1.htm

direttamente dall'etichetta posta sul modulo RIMM)
Non è il tRAC il tempo che devi guardare. Ma la latenza totale, ovvero
il tempo che intercorre tra il momento in cui richiedi un dato e il
momento in cui è effettivamente disponibile in cache e il tempo è
circa 70 ns. Questo lo dicono i bench, libero di credere a quello che
vuoi. 
Ciao
-- 
e-mail:dialtone#NOSPAM#@
aruba.it
Togliere #NOSPAM# per rispondere
E chi ha la fantasia per metterci una firma?!
http://groups.google.com/advanced_group_search?hl=it
tutto quello che vuoi sapere ed E' MEGLIO 
che tu non abbia mai osato chiedere

 vuoi.
Dei bench me ne frego altamente, quello che contano sono i datasheet!!!

 Dei bench me ne frego altamente, quello che contano sono i datasheet!!!
Non ne sarei cosě sicuro che quello che contano sono i datasheet.

Dei bench me ne frego altamente, quello che contano sono i datasheet!!!
ovvero compro una macchina per cosa leggo sulle brochure e non in base alle
prove su strada?
Ok.. se ti piace cosi'..
ciao r.d.

Dei bench me ne frego altamente, quello che contano sono i datasheet!!!
ROTFL!!!



datasheet che non sai neppure leggere, visto che il dato che hai preso
in considerazione e' soltanto una parte delle latenze in gioco.
continua a pensare quello che preferisci, ma per favore non insultare
la nostra intelligenza - grazie.


in considerazione e' soltanto una parte delle latenze in gioco.
sai perche' cita solo quel dato ? perche' compare nella pagina che lui ha
citato. il datasheet ho provato a scaricarlo, ma il server dopo un po' "si
dimentica di me" e dei 500kB me ne arrivano solo 30 o 40...
poi, se anche fosse riuscito a scaricarlo, dubito lo abbia mai guardato.