AMD2 moederbord altijd 800 mHz geheugen ?

[Brothar]

Momenteel wil ik obv een Asrock AM2NF3-VSTA moederbord een nieuw systeem maken.
Ik heb al DDR2-667 geheugen, en wil dat dus gaan gebruiken, en zocht nu een optimale processor daarbij.
Met de "oude theorie" van FSB*multiplier=processorsnelheid cq geheugensnelheid dacht ik bij 667 mHz geheugen een cpu met snelheid 2700 optimaal te zullen benutten.

Maar ... ik lees net de FAQ PMG. En lees dus dat de desbetreffende AMD processoren geen FSB meer kennen, meer een HTT-bus, die met een veelvoud van 200 Hz draait.
Krijg ik dan een optimaler systeem met geheugen op 800 mHz, en moet ik me niets aantrekken van de snelheid van de processor ?

Overigens geeft de handleiding van het moederbord aan dat 667 geheugen geschikt is.
En aangezien het een moederbord met een AGP slot is, en de AGP-bus op 66 draait, dacht ik dat dat 667 geheugen een slimme keus was ...

[TERW_DAN]

Geheugensnelheden hebben weinig meer van doen met de AGPbus. Daar zitten als het goed is netjes locks op, zodat dat geen problemen meer geeft. En anders is de divider wel in te stellen.
Als de manul aangeeft dat 667 gewoon gaat werken dan lijkt me dat iets waar je gewoon van uit kunt gaan.

[Brothar]

TERW_DAN schreef op vrijdag 08 mei 2009 @ 15:19:
Geheugensnelheden hebben weinig meer van doen met de AGPbus. Daar zitten als het goed is netjes locks op, zodat dat geen problemen meer geeft. En anders is de divider wel in te stellen.
Als de manul aangeeft dat 667 gewoon gaat werken dan lijkt me dat iets waar je gewoon van uit kunt gaan.

Dus het op elkaar afstemmen van snelheden van processor (in dit geval dus HTT-bus) en geheugen heeft met de huidige hardware geen zin meer ?

Dat dat 667 geheugen werken zal, dat was wel duidelijk, de vraag is alleen of de overal snelheid beter wordt met 800 mHz geheugen (dat dus wel afgestemd is op de snelheid van de HTT-bus).

[GENETX]

Geen zin MEER... Alsof het ooit veel zin heeft gehad. Al die mensen die hameren op 1:1 ratio's... 667MHz is gewoon wat langzamer als 800MHz wat weer wat langzamer is als 1066MHz. Je zult een beetje verschil merken maar het gaat hier om enkele procenten. Als je nog goed geheugen hebt moet je dat gewoon gebruiken.

Denk er wel om dat geheugen bij AMD underclocked kan worden. Zo draaide mijn 667MHz geheugen in mijn laptop op 640MHz omdat mijn kloksnelheid (1600MHz) door 5 werd gedeeld voor het geheugen: 320MHz en dat maakt DDR (Dual Data Rate) 640MHz.

Je moet dus de kloksnelheid delen om een bepaalde frequentie te krijgen bij AMD. Volgens mij kun je nu ook halve multipliers gebruiken voor het geheugen. Voor optimaal benutten moet je CPU dus op een veelvoud van 166MHz lopen, anders wordt je geheugensneleid omlaaggeklokt. Maar ook hier: Het blijft procentenwerk.

[Speedy-J]

Brothar schreef op vrijdag 08 mei 2009 @ 15:30:
[...]

Dus het op elkaar afstemmen van snelheden van processor (in dit geval dus HTT-bus) en geheugen heeft met de huidige hardware geen zin meer ?

Dat dat 667 geheugen werken zal, dat was wel duidelijk, de vraag is alleen of de overal snelheid beter wordt met 800 mHz geheugen (dat dus wel afgestemd is op de snelheid van de HTT-bus).

Dat maakt nu weinig meer uit of je nu sync of offsync werkt met je geheugen.
In de tijd met de AMD K7 was dit wel een probleem.
ALs je meer bandbreete wil dan ben je idd beter af met 800Mhz geheugen

[Verwijderd]

er is wel verschil, maar dat is te verwaarlozen. meestal merk je niets.

[TERW_DAN]

En vergeet niet dat je met dualchannel natuurlijk ook de dubbele bandbreedte hebt ten opzichte van een enkele dimm.

[Brothar]

TERW_DAN schreef op vrijdag 08 mei 2009 @ 15:50:
En vergeet niet dat je met dualchannel natuurlijk ook de dubbele bandbreedte hebt ten opzichte van een enkele dimm.

Ja, dat las ik in de FAQ.
Ach, gewoon een processor halen nu, en dan maar bouwen. Bestaande VGA-kaart en harddisk erin, en de basis voor een foto-opslag en bewerkingssysteem is er.
Dan later 2 SATA schijven in Raid 0, als die gedumpt gaan worden, en ik ben het heertje.

Merci iedereen. Ik zocht het dus weer te moeilijk, begrijp ik.