Chovanie ramiek na X48 chipsete

[Mir]

Uz nejaky cas fungujem na chipsete Intel X48. Starsia generacia s podporou DDR3.

Pouzite ramky su Adata 1866+ s cipmi Elpida Hyper MNH.

Rozhodol som sa fungovat na FSB 400Mhz s ramkami na frekvencii 1600Mhz a 8gb Ram. Tento pamatovy radic je vsetko len nie dobry. Akonahle nahodite 8gb ram Intel vam garantuje len 1333 s CL8 pri napati 1,9v. Frekvenciu sa mi po dlhodobom testovani podarilo dosiahnut, ale stabilita bol iny problem.

Stabilitu CPU som nastavil a overil predtym za pomocou Linxu len s 4 giga ram na nizsich frekvenciach s pamatami Nanya. Niesu vhodne na taktovanie, ale pokial ich nastavite na default tak su velmi stabilne a spolahlive. Po nahodeni lepsich ramiek (znova len 4gb) OCZ mi relativne dlho trvalo ich odladit aby boli naozaj stabilne. Nove Adaty s podporou jednych z najlepsich pamatovych cipov slubovali lepsiu taktovatelnost...

4gb bola hracka. Ramky priadli na 1333 CL5. Frekvencia 1600Mhz a CL7 -7-7-18 CR1 bola hracka. Problem nastal pri 8gb.

Zvysenie napatia Northbridge malo iba ciastocny dosah, ramky som musel dat takmer na 1,9v. Elpida specifikuje pre tieto chipy 1600Mhz, CL8, 1,5v pricom "smrtelne" napatie je 1,95v. Musel som ist az na 1,85v a zdokonalit sposob testovania stability.


Procesor ani ked sa na hlavu postavy nevie na 1600Mhz FSB vyprodukovat viac ako 12,8gb/s. Ramky ale maju na tejto frekvencii dvojnasobny bandwidth - 25,6mb/s. Jedine zariadenia ktore vedia vyuzit aj druhu cast bandwidthu mimo dosah CPU su na PCI-E zbernici a jedine co ma napadlo je skusit prehnat cez chipset co najviac video streamov... MPEG2 mi vie dekodovat graficka karta Ati HD 5850 pomocou UVD...

Cesta streamov vyzerala nasledovne:

TV Tuner 1 : Mpeg 2 stream DVB-S (HD kanal)
Tuner - PCI-E - CPU/RAM - PCI-E - GPU/UVD - Zobrazenie

TV Tuner 2 : Mpeg 2 stream DVB-T (SD kanal)
Tuner - PCI-E - CPU/RAM (4gb timeshift buffer) - PCI-E - GPU/UVD - Zobrazenie

DVD: Mpeg 2 Stream (SD kvalita)
IDE Radic - PCI-E (Southbridge) - DMI - NB - CPU/RAM - PCI-E - GPU/UVD - Zobrazenie

Do toho spusteny LinX s prioritou Below normal.

Pri nestabilnom nastaveni ci uz NB alebo RAM sa dal ocakavat kolaps systemu od 30 do 90 minut. Pokial som vynechal prehravanie videa tak len LinX system nebol schopny zhodit ani behom 8 hodin torture testu. Data streamy zo zdroja mimo CPU teda vcelku intenzivne zvysili zataz na RAM.

Vyplyva z toho niekolko veci:

1. Grafika alebo ine zariadenia na PCI-E zbernici vedia vyuzit bandwidth ku ktoremu procesor nema pristup z konstrukcnych dovodov.
2. DDR3 a frekvencie nad 800Mhz maju iste opodstatnenie (v pripade sync frekvencie samozrejme). Procesor a zariadenia na PCI-e zberniciach nenarazia na RAMke na uzke hrdlo v systeme. Jedinym limitom je teda vykon CPU/GPU (ziadany jav).
3. Vplyv na 3d aplikacie bude mizivy a takmer nemeratelny. Je to tym ze CPU je u takejto zostavy obmedzene socketom a GPU pci-E zbernicou. Pretoze generovanie 3d obrazu zavisi na oboch cipoch ich vzajomna komunikacia nikdy nemoze presiahnut rychlost 8 gb/s, pripadne transport dat z RAM do VRAM. Avsak CPU moze pracovat s RAM neobmedzene a nemusi cakat kym GPU dokonci svoju cinnost a vice versa. Toto sa prejavi skor tou formou ze vplyv inych subezne spustenych procesov na chod enginu bude utlmeny takmer na nulu (pokial nejak intenzivne nevyuzivaju CPU).

U novsich I7 a neskorsich generacii je tento jav utlmeny faktom ze CPU vie vyuzit omnoho sirsie pasmo pamati, avsak pokial grafika neukradne viac nez dnes limituje PCI-E 16x 2.0 tak narazenie na bottleneck na ramke nehrozi, specialne u 3 a viac kanalovych RAM.

Meranie formou zataze ram maximalne dokazalo fakt ze nielen CPU vie zatazovat pamat pri tomto type zostavy. Realne dokazat ze tento typ konstrukcie ma pozitivny vplyv na vykon systemu je ale obtiaznejsie. Pre mnoho bezne pouzivanych aplikacii je alfou a omegou CPU. Pre druhu skupinu je to kombinacia CPU/G{U pre jeden specificky task (3d engine). Velke CPU cache su pritom navrhnute prave na to aby vedeli uchovat znacne mnozstvo dat a teda oddialit nutnost odoslat data do RAM.

Teoreticky test ktory by u tejto konstrukcie vedel vyuzit tuto kapacitu vykonu zahrnuje nieco ako 4 graficke karty s CUDA/OpenCL enginom generujuc data do RAMdisku subezne s CPU. Pricom realny tok dat v sucte vsetkych jadier presiahne 13gb/s a dosiahne minimalne 15-16gb/s...

Viete o niecom?

[dexterav]

ja som normálne fungoval 1700MHz CL8 1.75V
8GB
dalšia vec, často spomínaš že tvoj xeon nepodporuje šetriace funkcie , čo je blbosť...
ako som už raz napísal je vysoko pravdepodbné že tvoja doska plne nepodporuje ten xeon o čom svedčí aj nefunkčnosť šetriacich funkcíí

[Mir]

Zalezi od toho ake setriace funkcie:

Eist funguje, ale vypinam ho.

viz: q9550
http://www.cpu-world.com/CPUs/Core_2/In ... 9550).html

a x3360
http://www.cpu-world.com/CPUs/Xeon/Inte ... 3360).html

Specialne odsek "low power features". Predtym to takto bolo aj na intelackych strankach len ich priliz zjednodusili. Xeon x3360 tieto features nema, pretoze jeho domaca platforma Garlow a cipset Intel 3200 ich vobec nepodporovala. X38 a X48 su v porovnani s tymito "workstation" doskami od intelu omnoho plnsim produktom.

Aky si mal cipset a napatie na nom?