Well, I've got the answer. With the increased of the CPU clock speed, the internal memory bandwidth is increased but not the RAM speed.

Source : http://www.cmpe.boun.edu.tr/courses/cmpe51...4%20FX%2055.doc

Here's empire23's not so superior guide to HTB or hyper transport bus/lorry.

Might be wrong, but this is what i can derive from the pinouts and chats with Charge-n-go, enjoy.

HT aka LDT uses differential signalling, and each "channel" is made of two unidirectional (in and out) links. With 16bits each direction, and two lines for differential signals, that makes 2*2*16 = 64 pins for data/address/commands. The LDT clock and control lines are also differential, and there are one for each direction, so that's another 8 lines. That makes a total of 72 lines for HyperTransport/LDT.

Differential signalling improves signal integrity by immunizing against skew and common mode noise, so you can pump data at ridiculously high clocks. This buys you bandwidth even with a reduced pin-count. Encapsulating information into packets saves the number of pins because you can have commands,addresses and data on the same wire. However, encoding and decoding packets increases latency.

The Intel FSB uses GTL+ single ended signalling, and is a bi-directional bus. Data comes in 64 bits at a time, so there are 64pins. P4 uses split data and address busses, so there's another 32 pins for addressing. On the control side, there are 5 pins for transaction types, 2 pins for address strobing and 8 pins for data strobing. That gives at least 111 pins related to the FSB. I probably missed some pins along the way

All of the above have very little to do with overclocking. When you "bus overclock" you're changing the "base" clock which goes into the CPU. Because the CPU's I/O is synchronous, the FSB/HT/DDR clocks increase in proportion to the base clock. The I/O has to communicate with "something". Even if your CPU can handle the increased I/O rate, the device on the other end (ie. the northbridge or DRAM) may not. That's when you mess with the multipliers/dividers to bring the I/O or memory bus clocks down to levels that are in-spec.

AMD64 doesn't have much granularity in the HT multplier, only 0.5x, 1x, 2x, 3x, 4x or 5x are selectable. The specific control register is covered in the AMD64 "BIOS and Kernel Developer's Guide", document no #26094, pg 49. Likewise for memory controller, there are only 1/2, 2/3, 5/6, and 1/1 dividers selectable (pg 88,89).

Bus clocking is constrained by capability of the devices on the bus and signal integrity. Signal integrity is influenced by a lot of things, including the type of IC packaging, the electrical signalling scheme, the materials used in the PCB, and the routing of the circuit.

i oso come out with own drawings now.

This is the difference between FSB and HTT system.



FSB transfer data from RAM, AGP and the I/O to CPU on the same bus. The total transfer rate is only 6.4GB/s on dual channel DDR400. The control and address use different lines.

On HTT, I/O and PCI-e data/address/command are packeted and communicate with CPU on a 4.0GB/s HTT bus (2000MHz 16-bit) in either direction. RAM communicates with the integrated memory controller on another bus running at 6.4GB/s (DDR400 dual channel). So we have a total of 10.4GB/s on HTT bus.

This post has been edited by charge-n-go: Sep 21 2005, 11:39 AM

Silky you are finally here huh?

I was about to write something on the quote above, but u r faster than me now

What i can do is to attach image only, hahah.



Direction into the CPU : L0_CADIN_H/L[15:0] <--- 16-pins / 16-bit
Direction out from CPU : L0_CADOUT_H/L[15:0] <--- 16-pins / 16-bit

Other pins are for clock and controlling

Eh, btw... the SB -> NB link is 1Gb/s per direction.

That depends on the chipsets involved. It's not a set rule.

haha, it should be both direction, but i miss out the arrows at another end. Actually all the buses drawn in the diagram is bi-direction.

This post has been edited by charge-n-go: Oct 30 2005, 11:51 PM

I can do 8x and 4x for you

No 3DMark though.

A64 3000+ @ 1.6GHz, x8
HTT: 200, x4, 1.2V
RAM: 200, 2.5-2-2-0 1T 1:1

SuperPI 1M:


Sandra Multimedia:


Sandra Memory:


3DMark2001 SE Build 330:


Pathetic benchmarks, I think it's my refresh rate

I don't think many mainboards can do 400MHz HTT easily. Anyway that won't help much, if at all. All you have to do is bump up the LTD multiplier and it will do more per clock anyway.

what would be interesting to test is how memory bandwith scales with the LTD multiplier from 1x to 5x while keeping everything else the same. This will confirm or deny the theory that the memory controller is not tied to the HTT bus.

on request :


TestBed :
AMD 3200+ Venice 0518
DFI Ultra-D BIOS 7.04bta
TwinMOS UTT [ch-5] @ 2-2-2-5

Here is my steps :
1. setting up the BIOS
2. save & reboot, load into Windows xp pro sp2
3. terminate all unused background applications
4. double check the setting thro cpu-z v1.30
5. close cpu-z, run SPImod1.4
6. benchmark from 16k to 1M, 3 times for each to get the best score
7. close SPImod1.4, run SandraLite2005
8. benchmark CPU Arithmetic Benchmark, CPU Multi-Media Benchmark, Memory Bandwidth Benchmarak, and Cache & Memory Benchmark
9. after benchmarking finished, load back SPImod1.4 and take screenies

---=== FINISH ===---

Here is the results that i collected :

Benchmark & screenshot #1
200MHz[htt] x 10[multiplier] @ 2.0GHz, LDT frequency 4x :


Benchmark & screenshot #2
400MHz[htt] x 5[multiplier] @ 2.0GHz, LDT frequency 3x :





-----=====-----=====-----=====-----=====-----=====-----=====-----=====-----=====-----=====-----=====-----=====-----=====

If you watch out carefully, you will found out that i used different LDT frequency for both test
my mistake, so for more accurate result, i benchmark again @ 200MHz[htt] x 10[multiplier] with LDT frequency 3x

Benchmark & screenshot #3
200MHz[htt] x 10[multiplier] @ 2.0GHz, LDT frequency 3x :



End of test :
From the benchmarked results that i collected, oviosly we can see that marks for
200MHz[htt] x 10[multiplier] > 400MHz[htt] x 5[multiplier]

So, i concluded that by incressing htt frequency wont gain any of the system bandwidth nor performance at all.


regards,
Evogenix

This post has been edited by Evogenix: Sep 22 2005, 03:44 PM

Whoaaa got LDT x 10 meh?

I tried using 200 x 4 and 400 x 2, but 400 couldn't POST. My mobo tops out at 360ish HTT AFAIK.

x10 is multiplier
3x is LDT frequency

faild to boot into BIOS @ high htt frequency might cause by
1. mainboard limitation
2. proc's memory controller limitation

Evogenix

Nah I tried upping voltages but it didn't help.

It's the limitation of the mobo. It doesn't related to the proc memory controller.

This is the most highest HTT i've ever achieve with my board and the new E6 Venice...b4 this my winnie and venice a few months back managed to get 370 and that is the most out of it....

390 is the best for me....no benchies how ever....sorry...

Good suggestion dude.

I do this bcoz from wat i noticed, some people will js o/c their HTT base clock and tune the multiplier within safe region of 800MHz to 1200MHz, while leaving their CPU and RAM at stock speed, and then overjoy bcoz the mobo can o/c so high and have performance gain. AFAIK, this works with FSB only bcoz higher FSB bandwidth decrease the latency.

I'll come out with new methods to prove our assumptions and theory earlier


Thanx skyther, Evogenix, antonio_zth for the screenies

This post has been edited by charge-n-go: Sep 22 2005, 06:10 PM

Experiment procedures updated

pls refer to post #2

THanx for joining ppl


* anybody can come out with better procedure, pls suggest here

This post has been edited by charge-n-go: Sep 22 2005, 06:09 PM

i think test#2 already shown in my screenie
the benchmark #1 and benchmark #3 accually the same setting.
the only difference is the LDT frequency 4x[benchmark #1] and 3x[benchmark #3]

there is slightly decressment with the score as shown in the srceenie from 4x to 3x

Evogenix

This post has been edited by Evogenix: Sep 22 2005, 06:15 PM