#1
Endelig kan i lære det !! :e
#1
haha :D :p
Men ja den artikel giver god indsigt :i
haha :D :p
Men ja den artikel giver god indsigt :i
#3
#1 ja, det er godt nok helt vildt så mange, der ikk fatter det :l
...og så tåger de ud og køber RAM til 3k og bundkort, der kan køre 300+ MHz for at OC deres 130nm Athlon 64 - DE SKAL JO KØRE HØJ FSB!!! :e
...og så tåger de ud og køber RAM til 3k og bundkort, der kan køre 300+ MHz for at OC deres 130nm Athlon 64 - DE SKAL JO KØRE HØJ FSB!!! :e
#4
#3:
Præcis...
Det eneste det giver er rambåndbredde.. Men det kan man sgu ik udnytte hvis man ik har en ordentlig cpu ( tror jeg nok ).
Præcis...
Det eneste det giver er rambåndbredde.. Men det kan man sgu ik udnytte hvis man ik har en ordentlig cpu ( tror jeg nok ).
#5
#4, Jo, det er jo netop det man kan, at man så bare sænker multiplier på CPU og smider HT op ;)...
Men man vil aldrig få noget ud af at køre RAM højere MHz end HT, da max båndbredde jo stadig er HT-clock*16*2 (ved Dual-channel), og RAM'mene vil derfor ikke kunne få mere data igennem :)
MVH.
TOke :)
Men man vil aldrig få noget ud af at køre RAM højere MHz end HT, da max båndbredde jo stadig er HT-clock*16*2 (ved Dual-channel), og RAM'mene vil derfor ikke kunne få mere data igennem :)
MVH.
TOke :)
#6
Eller, nej, glem det, glemte lige, at det eneste der KAN påvirke max båndbredde er RAMmenes egen hastighed :r :00 :p
Men den stiger jo kun når du hæver HT :r
MVH.
Toke :)
Men den stiger jo kun når du hæver HT :r
MVH.
Toke :)
#7
#5 forklar mig lige hvad HT frekvensen har at gøre med RAM frekvensen og båndbredde? Håber du mener clock generatoren :)
#8
Nice artikel woodgnome :)
Der blev i 2004 skrevet en artikel som siger lidt det samme.. Jeg har linket til den et utal af gange for at få folk til at forstå at "fsb ikke er hvad fsb var"..
During the era of Socket A, it was always about lowering the multipliers and raising the FSB. Generally, the higher the FSB, the higher the system bandwidth.
http://www.insanetek.com/revie...
Desuden undrer det mig stadig at folk ikke at luret at HTT=fsb og HT er linken mellem CPU og NB. Der er mange som siger "hæv HT" når der snakkes oc.
Der blev i 2004 skrevet en artikel som siger lidt det samme.. Jeg har linket til den et utal af gange for at få folk til at forstå at "fsb ikke er hvad fsb var"..
During the era of Socket A, it was always about lowering the multipliers and raising the FSB. Generally, the higher the FSB, the higher the system bandwidth.
http://www.insanetek.com/revie...
Desuden undrer det mig stadig at folk ikke at luret at HTT=fsb og HT er linken mellem CPU og NB. Der er mange som siger "hæv HT" når der snakkes oc.
![[G.N.U.]](/images/users/profile/36302.jpg)
ja brug lige HTT i det mindste for det forvirrer med HT :)
#10
#8 HTT er heller ikke det der svarer til FSB - det er stadig clock generatoren (eller, den svarer til FSB'ens frekvens) 8).
HTT er (som jeg har tilføjet) HyperThreading Technology og forveksles med HyperTransport Technology (som er forkert).
HTT er (som jeg har tilføjet) HyperThreading Technology og forveksles med HyperTransport Technology (som er forkert).
#11
HT er da Hyperthreading og HTT Hypertranport..
#13
#11 Nemlig. HTT er Hyper Transport tech. hvor HT er Hyper Threating. :e
Det var nemlig det der skabte forviring, da Athlon64 blev lanceret, da Intel længe havde haft P4 3.0 800FSB HT, og så kom AMT med deres Athlon64 og sagde den havde en HTT på 800 (i de første 754 mobo) eller 1000 (på 939).
Det var nemlig det der skabte forviring, da Athlon64 blev lanceret, da Intel længe havde haft P4 3.0 800FSB HT, og så kom AMT med deres Athlon64 og sagde den havde en HTT på 800 (i de første 754 mobo) eller 1000 (på 939).
#14
Jævnfør http://en.wikipedia.org/wiki/H... er HTT = HyperThreading Technology og http://en.wikipedia.org/wiki/H... HT = HyperTransport.
Citat fra 2. link "There has been marketing confusion between the use of HT referring to HyperTransport and the use of HT to refer to Intel's Hyper-Threading feature of their Pentium 4 based microprocessors. Hyper-Threading is known as Hyper-Threading Technology (HTT) or HT-Technology. Because of this potential for confusion, the HyperTransport Consortium always uses the written out form: "HyperTransport"."
Citat fra 2. link "There has been marketing confusion between the use of HT referring to HyperTransport and the use of HT to refer to Intel's Hyper-Threading feature of their Pentium 4 based microprocessors. Hyper-Threading is known as Hyper-Threading Technology (HTT) or HT-Technology. Because of this potential for confusion, the HyperTransport Consortium always uses the written out form: "HyperTransport"."
#15
kan da godt ske det ikke giver noget som i siger men i en 3d2001 er der nu lidt forskel på det ca 500 point så lidt giver det men syntes nu stadig windåse kører lige hak bedere og man behøver ikke give det vilde for at nå høj fsb.
#16
medmindre man er en value knægt hehe ;)
#17
#7 Selvfølgelig, clock-generator (I ved hvad jeg mener! :r)...
Ikke spille så bedrevidende... Gnom :00
;) :p :e
MVH.
Toke :)
Ikke spille så bedrevidende... Gnom :00
;) :p :e
MVH.
Toke :)
#18
Spørgsmål 1: Kan vi blive enige om at <B>HyperTransport</B> er linken mellem <B>CPU og NB</B>?
Spørgsmål 2: Så er vi også enige om at <B>HyperTransport ikke har noget som helst at gøre med kommunikation mellem CPU og Ram </B>ikke?
Godt..
CPU'en modtager en "reference clock" fra en clock-generator så den ved hvilken hastigheden den skal lade dataen løbe mellem sig selv og rammen.
<I>Since there is no FSB to use as a reference for the CPU-core's clockspeed (as well as some of the other clocks), we need something else to provide the required reference clock signal.</I>
Det er altså ikke clock-generatoren som transporterer data mellem cpu og ram. Clock-generatoren virker bare som reference for cpu'en.
Hvad kalder man så linken mellem CPU og Ram? Jeg kalder den HTT. Jeg ved ikke hvorfor, men jeg kalder den i hvert fald ikke for HT. Det er vel i og for sig stadig en "bus", om man så kalder den "front side" er vel lidt hips om haps.
Spørgsmål 2: Så er vi også enige om at <B>HyperTransport ikke har noget som helst at gøre med kommunikation mellem CPU og Ram </B>ikke?
Godt..
CPU'en modtager en "reference clock" fra en clock-generator så den ved hvilken hastigheden den skal lade dataen løbe mellem sig selv og rammen.
<I>Since there is no FSB to use as a reference for the CPU-core's clockspeed (as well as some of the other clocks), we need something else to provide the required reference clock signal.</I>
Det er altså ikke clock-generatoren som transporterer data mellem cpu og ram. Clock-generatoren virker bare som reference for cpu'en.
Hvad kalder man så linken mellem CPU og Ram? Jeg kalder den HTT. Jeg ved ikke hvorfor, men jeg kalder den i hvert fald ikke for HT. Det er vel i og for sig stadig en "bus", om man så kalder den "front side" er vel lidt hips om haps.
#19
Tjah. Jeg troede egentlig altid clock-generatoren svingede med samme hastighed som HTT-bussen. Og ja, det vil jeg nu engang kalde den. Og så kommer der en divider på ram der er "HT multi" højere end den ser ud. Og så er multiplier på cpu i virkeligheden en anden.
Men det kan jeg sa så se er forkert, selvom det var noget tættere på sandheden end den traditionelle metode.. Og virker 100% fint som model i alle tilfælde indtil nu ;)
Men det kan jeg sa så se er forkert, selvom det var noget tættere på sandheden end den traditionelle metode.. Og virker 100% fint som model i alle tilfælde indtil nu ;)
#20
#19, det gør den vel også.. det er da clock-generatoren som definerer HTT hastigheden.
#21
#18 nu virker jeg måske lidt tvær men ja.. NB er der jo stadig til PCI-EX16, nu må jeg indrømme at jeg faktisk ikke ved om den blev brugt til AGP i sin tid ^o) men det vil jeg tro?.. HTT skaber en lynhurtig forbindelse til Memory controlleren
#22
#17 jeg spiller aldrig bedrevidende! ?:(
:e
#18
Ja
Jo
AMD teknikeren i den mail jeg har liggende kalder linket imellem CPU og RAM for Direct Connect architecture. ...Som HyperTransport egentlig også er. Det er vist et navn der er gældende for hele AMD64 arkitekturen, men har dog ikke lige kunnet finde mere info om det specifikke link imellem RAM og CPU :l
#21 jo, NB var både mem controller og AGP controller "dengang" :)
:e
#18
Ja
Jo
AMD teknikeren i den mail jeg har liggende kalder linket imellem CPU og RAM for Direct Connect architecture. ...Som HyperTransport egentlig også er. Det er vist et navn der er gældende for hele AMD64 arkitekturen, men har dog ikke lige kunnet finde mere info om det specifikke link imellem RAM og CPU :l
#21 jo, NB var både mem controller og AGP controller "dengang" :)
#23
Betyder det, at selv om man putter divider på Ram opnår man samme ydelse? Eller betyder det at man heletiden skal sørge for at opnå så høj multiplier som muligt? Jeg er lidt lost der, så hvis i lige kan forklare så bliver jeg glad :D
#24
#20 der står den kører 200 mhz i linket. Jeg gik ud fra at den kørte 1000.
#23: Rams ydelse er den samme ved samme hastighed på a64. Så man mister altså ikke sådan ydelse ved at bruge en divider som før i tiden, ud over at man ikke kan stramme en timing som max async latency så meget, men det er temmelig minimalt.
Afhængig af appliaktionen vinder man dog heller ikke vildt meget ved over 200-220 mhz på ram, især ikke hvis timings skal slækkes. Der er dog stadig applikationer der gerne spiser båndbredde. Som hovedregel er det bare en god ide at maxe sine ram og så clocke efter det, men huske at det ikke er det der er altafgørende.
#23: Rams ydelse er den samme ved samme hastighed på a64. Så man mister altså ikke sådan ydelse ved at bruge en divider som før i tiden, ud over at man ikke kan stramme en timing som max async latency så meget, men det er temmelig minimalt.
Afhængig af appliaktionen vinder man dog heller ikke vildt meget ved over 200-220 mhz på ram, især ikke hvis timings skal slækkes. Der er dog stadig applikationer der gerne spiser båndbredde. Som hovedregel er det bare en god ide at maxe sine ram og så clocke efter det, men huske at det ikke er det der er altafgørende.
#25
#1
"Sådan er det ikke på en Athlon 64. Der handler det om at maksimere CPU'ens hastighed og i mindre grad RAM'enes hastighed mens clock generatorens hastighed ikke har nogen effekt på ydelsen. "
Du vil måske så fortælle mig at jeg ikke vinder noget ved at køre 300 Mhz på rammen fremfor 200 ? :e
"Sådan er det ikke på en Athlon 64. Der handler det om at maksimere CPU'ens hastighed og i mindre grad RAM'enes hastighed mens clock generatorens hastighed ikke har nogen effekt på ydelsen. "
Du vil måske så fortælle mig at jeg ikke vinder noget ved at køre 300 Mhz på rammen fremfor 200 ? :e
#26
#23 max multi er ikke det man skal gå efter, men max. CPU hastighed er. Derefter kan man, som #24 skriver, justere clock signalets og RAM'enes hastighed til at opnå max. ydelse. Dividere burde ikke give noget ydelsestab, men det kan man selfølgelig altid prøve efter med SiSoft Sandra eller lignende.
#25 nej, men det er heller ikke det jeg skriver. Jeg skriver at man ikke vinder noget ved at køre med høj hastighed på clock generatoren og lav multiplier frem for lav hastighed og høj multiplier.
At RAM'enes hastighed så øges i takt med forøgelse af clock signalets hastighed er en anden sag. ...Som i begrænset omfang kan omgås, hvis man bruger Athlon 64'ere med E stepping, der understøtter RAM dividers mindre end 1:1. Eller RAM multipliers eller whatever... I VED HVAD JEG MENER :e
#25 nej, men det er heller ikke det jeg skriver. Jeg skriver at man ikke vinder noget ved at køre med høj hastighed på clock generatoren og lav multiplier frem for lav hastighed og høj multiplier.
At RAM'enes hastighed så øges i takt med forøgelse af clock signalets hastighed er en anden sag. ...Som i begrænset omfang kan omgås, hvis man bruger Athlon 64'ere med E stepping, der understøtter RAM dividers mindre end 1:1. Eller RAM multipliers eller whatever... I VED HVAD JEG MENER :e
#27
Det var da dejligt at læse noget jeg har været klar over i lang tid, nu ved jeg da at jeg har fat i den lange ende - før var det jo bare min helt egen teori :D
Mvh. Uffe
Mvh. Uffe