@Pavlyuchenko
vielen dank für den test.jetzt ist nur die frage, was löst dieses problem aus
und wie kann man es beseitigen?
leider habe ich kein x35 board mehr. mich würde mal interessieren was crystalmark
auf einem solchen board bringt mit (nur die speicher geschwindigkeiten:ram read,write,copy) :
einer intel cpu die normal fsb 1333 hat auf 1600, und die rams auf 800 mhz,linked,synched.
@neocx
also ich habe das board schon mit fsb 1800 laufen lassen.die rams liefen
mit 900mhz und mehr. (Kingston HyperX KHX6400D2LL/1GN low latency type 900mhz@5-5-5-15,800mhz@4-4-4-12)
es ging sogar noch erheblich mehr, allerdings merkte man wie irgendwie der speicher
ins haspeln kam. windows fuhr hoch, allerdings erheblich langsamer als normal.
aber es hat wirklich alles gegeben und ist gestartet.
denke mal wenn man die rams auf 6-6-6-18 setzt,oder andere parameter ändert
flutscht das sogar auch noch butterweich.
hatte die rams mal im verhältnis 3:2 laufen (automodus per cputype getestet), oder in irgend einer (ähnlich
sinnlosen) konstellation, in jedem fall hatten die rams da einen fsb von 975.
(
sinnlos weil, du ein 1:1 linked verhältnis anstreben solltest,was ja bei fsb1333 prozessoren (standart 333 mhz fsb) kein problem darstellen sollte, da du den cpu fsb schon so weit hochgedreht hast,und am ram trotzdem gerade mal bei gesunden 400 mhz ankommt.schlecht ausgedrückt.nochmal einfacher:
wenn du eine fsb 1333 cpu benutzt, dann hat diese einen fsb von 333. wenn die rams nun synchron und linked l aufen würden, liefen sie ebenfalls auf fsb 333 sprich double datarate 666. da deine rams aber sicher bis 800 also fsb 400 gehen, sollte es kein problem darstellen die cpu um sagen wir mal 20 mhz anzuheben, und somit parallel die rams.
die rams sind auf jeden fall bis 400 mhz im sicherheitsbereich drin.kackt bis 400 etwas ab, sinds evtl
ie ram timings,spannung der cpu und rams nicht erhöht,schlechte kühlung auf cpu.das mainboard funzt bis 400 mhz fsb in jedem fall 100%,da braucht man sich keine gedanken zu machen
)
grundsätzlich funzte das (unerwarteter weise) sogar. wie gesagt, der rechner
fuhr aber langsamer, statt schneller hoch. denke das der ram controller mehrere anläufe brauchte
um seine rows zu lesen. scheinbar verpassten die rams den richtigen zyklus zur richtigen zeit.
trotzdem beachtlich das windows gekämpft hat, bis es komplett da war
was für rams benutzt du denn und mit welchen einstellungen?
wie ist dein ram gelinkt? synchron, asynchron?
hast du spannungen der cpu bzw. rams erhöht?
was für timings hast du gewählt? welcher hersteller und typ ist dein ram?
und vor allem, hast du die pci clock fix auf 33 mhz gesetzt? und die pci-e uhren auf 100?
oft kackt nämlich der pci bus ab. bei mir sehe ich das im post-display.
leider habe ich die funktion pci clock fix 33 mhz noch nicht gefunden bei dem mainboard.
aber im pci steckt meine x-fi soundkarte. und die ist da sehr zimperlich mit abweichenden takten.
auch wenn du keine pci geräte eingesteckt hast, so sind doch einige komponenten des mainboards
onboard pci.
ein gedanke der mir kommt ist:
das sisoft und everest zu kleine datenpakete ins ram schreiben, und die daten im
secondlevelcache/rambuffer (nur wenige bytes würden langen,wenn zu kleine testblöcke geschrieben würden) zurückgeholt werden.
chrystalmark könnte unter umständen größere pakete schreiben, und somit realer aufs ram zugreifen.
(beispiel raidcontroller mit cache. bei kleinen dateien gehen die zugriffe oft nur aufs cache.nimmt man
testblöcke von 512mb oder größer, zeitgt der raid seine wahre (langsamere) geschwindigeit.
genau so wirkts bei chrystmark. denn bei chrystalmark dauert ein ramtest im vergleich zu sisoft oder everest
erheblich länger.somit werden wohl auch mehr daten (bzw. größere blöcke) transferiert.
oder greift chrystalmark, genau wie winhex, direkt aufs ram zu (lowlevel zugriff), und sisoft bzw. everest gehen über den windows speichercontroller? falls ja, könnte es tatsächlich ein speichertreiber problem sein, welches nvidia mit einem treiber update fixen könnte.