LDT, RAM, HyperTransport Performance Revealed

B

burningrave101

[H]F Junkie
Joined
Sep 9, 2003
Messages
11,825
Among other knowledge extracted from this crusade, prevalent is the fact that memory bandwidth on this architecture is highly dependant on CPU clock speed, and that raising the HT bus or memory speed alone results in almost no performance gain. Users will see a considerable gain in performance by raising the LDT bus speed, keeping the CPU multiplier at its maximum, and making use of a memory divider if their memory is incapable of running at the new speed. The rule of thumb is memory bus efficiency is directly related to the CPU clock speed.

One other interesting tidbit I've extracted from these tests is that the HT link speed really isn't of great importance, unless you are really pushing lots of data down that path. An example of such heavy use could be two NVIDIA cards in SLI, Gigabit Ethernet, and/or RAID 0 array, all in use more or less at the same time. Only then would 1-2 GB/s not be enough to satisfy all of these components. All in all, the difference between 600 MHz and 1000 MHz ought to have absolutely no impact on performance, even at these usage levels. I just don't see how you can saturate ~3.8 GB/s of bandwidth with the use of Ethernet/SATA/IDE/video/sound - you would need to be stressing every one of those subsystems at once to at least come close.

To summarize, memory dividers are a perfectly acceptable way of maximizing system performance, as CPU clock is the factor around which everything revolves, HT link speed is not of great importance (even 600 MHz ought to be enough for 99% of users), and the absolute best way to squeeze performance out of your K8 system is to avoid the use of a memory divider, though that requires high-end memory.
Click to expand...

http://www.neoseeker.com/Articles/Hardware/Guides/athlon64oc/6.html

The LDT speed and HyperTransport speed really have no impact on performance whatsoever. RAM bandwidth has only a marginal impact that will only be noticed in bandwidth intensive applications. The CPU speed alone is the only thing you need to worry about overclocking when overclocking an Athlon 64.

Memory dividers will not hurt performance like they did in the case of the Athlon XP. The memory controller is now integrated on-die so it is always synchronous with the CPU speed.

In order words, buying expensive RAM to try and break 300Mhz is a waste of time. Buy RAM thats cheap and low latency that will overclock to a descent speed and thats all even the most serious of overclockers will need.
 
good to see that a review site has finally done what i have been trying to tell people for a long time now:

ht link speed doesn't matter
memory speed doesn't matter, above a certain limit
do not sacrifice cpu speed for anything

thanks for posting this though, hopefully word will finally get out and people will understand how they should oc their systems for maximum performance :D
however, i'd like to see the same tests done on a single channel setup, to see if they like memory overclocks slightly more than on dual channel.
 
Well, I think my memory is still good to have paired with my system.
Once I figured out what SATA port was locked, I managed to pull this off:


I think it's nice for a 5:6 1.55v OC. Especially since higher memory speeds seem to help my latency. Though at the same time, the CPU's speed is also increased. Meh. I'm just so damn happy with my setup at long last. Of course I'm not done tweaking. All that's needed is water and a 3.4v vdimm.
 
ok, could someone explain to me *exactly* what LDT speed is.
I understand memory speed, and HTT speed, and CPU clock speed, but whats LDT?
 
they seemed to have gotten some of their terms mixed up from how we use them around here.. though it seems that LDT (lightning data transport) is roughly analogous to HTT and FSB ;)

and what they call HTT link is what i consider the HT link speed.
 
So what's new? :p He still shows a 4-5% difference between 200MHz and 257MHz. Overall, it's not a big deal, but it doesn't hurt.
 
yup, all the more reason to focus on cpu speed.

now if i could just get over 2.35ghz with 1.65v :(
 
(cf)Eclipse said:
they seemed to have gotten some of their terms mixed up from how we use them around here.. though it seems that LDT (lightning data transport) is roughly analogous to HTT and FSB ;)

and what they call HTT link is what i consider the HT link speed.
Click to expand...

well since HTT and FSB are different, LDT can't be roughly the same as both
 
well a lot of people call HTT the FSB on a64's, even though it's wrong. but this guy called HTT the LDT :confused:
then called the ht link htt. :(


naming issues aside, it's a very nice write up, and i give props for that :D
 
yeah. too many different names floating around talkign about the same stuff.

summary
run your CPU as fast as you can.
slow down the HTT by a mult if it helps, wont hurt anything
run your memory as fast as you can, but feel free to use a divider, it wont hurt
 
agreed :cool:

i think that post should be the new oc sticky. tells people everything they need to know :p
 
(cf)Eclipse said:
they seemed to have gotten some of their terms mixed up from how we use them around here.. though it seems that LDT (lightning data transport) is roughly analogous to HTT and FSB ;)

and what they call HTT link is what i consider the HT link speed.
Click to expand...

HyperTransport (HT), formerly known as Lightning Data Transport (LDT), is a bidirectional serial/parallel high-bandwidth, low-latency computer bus. The HyperTransport Technology Consortium is in charge of promoting and developing HyperTransport technology. The technology is used by AMD and Transmeta in x86 processors, PMC-Sierra and Broadcom in MIPS microprocessors, NVIDIA, Via, SiS, ULi/ALi, and AMD in PC chipsets, Apple Computer and HP in Desktops and notebooks, HP, Sun, IBM, and IWill in servers, Cray in supercomputers, and Cisco in routers.

HyperTransport runs at 200-1400 MHz (compared to PCI at either 33 or 66 MHz). It is also a DDR or "double-data-rate" bus, meaning it sends data on both the rising and failing edges of the 1400 MHz clock signal. This allows for a maximum data rate of 2800 MTransfers/s per pair. The frequency is auto-negotiated.

HyperTransport supports an auto-negotiated bus widths, from 2 (bidirectional serial, 1 bit each way) to 32-bit (16 each way) busses are allowed. The full-sized, full-speed 32-bit bus has a transfer rate of 22,400 MByte/s, making it much faster than existing standards. Busses of various widths can be mixed together in a single application, which allows for high speed busses between main memory and the CPU, and lower speed busses to peripherals, as appropriate. The technology also has much lower latency than other solutions.

HyperTransport is packet-based, with each packet always consisting of a set of 32-bit words, regardless of the physical width of the bus interconnect. The first word in a packet is always a command word. If a packet contains an address, the last 8 bits of the command word are chained with the next 32-bit word to make a 40-bit address. The remaining 32-bit words in a packet are the data payload. Transfers are always padded to a multiple of 32 bits, regardless of their actual length. HyperTransport revision 1.05 contains an option allowing an additional 32-bit control packet to be prepended when 64 bit addressing is required.

Its electrical interface uses 1.2 volt Low Voltage Differential Signaling (LVDS).
Click to expand...

AMD has renamed its Lightning Data Transport (LDT) technology HyperTransport and, as predicted, plans to create a consortium of supporter companies to drive the adoption of the technology and its establishment as a standard.

HyperTransport is AMD's new core I/O bus, providing a high speed, high bandwidth connection between a system's Northbridge and multiple, parallel I/O buses via an array of Southbridge chips. That allows compatibility with existing I/O and add-in systems, such as PCI, since they can be added to as system as just one more module on the HyperTransport bus.

Other, newer transport technologies can also be supported, thanks to this modular approach - just hook up another HT bridge to the chain. AMD claims that up to 32 bridges can be daisy-chained together, irrespective of their own bandwidth and speed specifications.

The bus also doubles up as a multiprocessing bus, connecting each processor's Northbridge to all the other processors' Northbridge chips. That's essentially a NUMA configuration, giving each CPU its own local memory, connected via its Northbridge, and access to other processors' RAM banks.

AMD reckons the technology will provide up to 6.4GBps of internal data throughput, rather better than today's typical interconnect bandwidths of 266MBps.

Chimpzilla developed LDT to allow its Athlon CPU to be used in multi-processor server environments, but the change of name to HyperTransport reflects the technology's applicability to other environments, many of them highly lucrative embedded applications. Along with the name change, AMD announced Sun, Broadcom, Cisco and Nvidia as its initial band of supporters.

A canny bit of PR, that. Each company represents specific sectors AMD wants to target HyperTransport at: servers; broadband networking; routers and comms products; and graphics, SoCs, North- and Southbridge parts, respectively.

The supporters are also key players within those sectors, which AMD hopes will pull in their competitors. Indeed, Nvidia's arch-rival, ATI, quickly leapt onto the bandwagon and declared its support for HyperTransport soon after the AMD announcement.

Of all these companies, only Nvidia has been linked to shipping product - almost certainly its Xbox chipset, and the PC-oriented versions of it that it's hoping to sell to. Nvidia's decision to license the technology slipped out last month at the Platform Conference in San Jose. Then, an AMD spokesman said ten companies, including Nvidia, had licensed LDT, and 20-30 others were evaluating it.

That may be why AMD isn't launching its HyperTransport Consortium just yet, preferring instead to suggest it as something it plans to do (though when the launch will take place, it didn't say). ®
Click to expand...

From what i can tell the LDT is simply the multiplier used to get the effective speed of the HyperTransport bus. I dont think there is an LDT bus between the CPU and memory like he seems to suggest.

HTT speed x LDT multi = effective HyperTransport speed

Does anyone have a link to an article that has a good picture of the layout of how the Athlon 64 communicates with all the devices in the system?
 
it's just great we can get off this neccessity for buying super expensive ram to suffice good overclocks, always been a limiting factor for me because i'm not willing to break the bank on ram

much more grass roots approach, crank up the cpu and it'll fly regardless, i've been into AMD for far too long, but once the 800mhz p4's showed up and then 865/875 all with affordable prices and a lot of punch i began to get worried, now it's my personal opinion the P4 archtecture's is near end of life and going with a NF4 / winnie solution, even stock, is great, the easy overclocking and insane gains are just a nice bonus, something that can remind me of the earlier days of amd and doing a lot with a little bit of money

Intel Nazis: no flaming please, i don't want to hear about how cool intel is for whatever reason, i'm not biased towards either i give credit where it's due, amd is just kicking ass again for the enthusiasts and where i would have built a socketT/915 system 12 months ago, for today (which may change tommorow) money on amd is money well spent

now if only we can get past these clock barriers, both intel and amd haven't done much in the way of higher clock speeds but retooling what they can already do with equal or lesser clock speed, kind of the balance isn't it? if amd could get away with significant clock speed increases it would be all kinds of rediculous

one more thing, i don't yet own an A64 system for my home rig nor have i built one and used it on xp 64bit, are there any acrossed the board increases for a64's on xp64?
 
This needs to be stickied so that maybe people will save a hundred dollars or so and get winbond or micron instead of TCCD :)


"now if only we can get past these clock barriers, both intel and amd haven't done much in the way of higher clock speeds but retooling what they can already do with equal or lesser clock speed, kind of the balance isn't it? if amd could get away with significant clock speed increases it would be all kinds of rediculous"

Well, people are hitting over 3.0ghz with venice on stock voltage and I believe some on stock cooling. 3.0ghz is just around the corner I believe, and socket M2 I'm sure will have entry level chips of 3.0ghz. Intel needs to do something fast to compete with that beast (unless that garbage DDR2 holds back M2 :rolleyes: )
 
(cf)Eclipse said:
well there is no bus between the memory controller and ram.. period, the mem controller is a part of the cpu.. so it's just sorta connected. ;)
Click to expand...

I realize the memory controller is integrated on-die instead of being in the Northbridge but if there is no bus between the CPU and the memory then the data couldn't get from the RAM to the CPU. You forget that the RAM isn't integrated on-die as well :p.

BoostFrenzy said:
Intel Nazis: no flaming please, i don't want to hear about how cool intel is for whatever reason, i'm not biased towards either i give credit where it's due, amd is just kicking ass again for the enthusiasts and where i would have built a socketT/915 system 12 months ago, for today (which may change tommorow) money on amd is money well spent

now if only we can get past these clock barriers, both intel and amd haven't done much in the way of higher clock speeds but retooling what they can already do with equal or lesser clock speed, kind of the balance isn't it? if amd could get away with significant clock speed increases it would be all kinds of rediculous

one more thing, i don't yet own an A64 system for my home rig nor have i built one and used it on xp 64bit, are there any acrossed the board increases for a64's on xp64?
Click to expand...

Intel still has its strong points over AMD. It just depends on what you use the system for. For the average home user an Athlon 64 would probably be the best choice but for someone that does alot of CPU intensive tasks like graphic design the Pentium 4 would be a better choice because of HyperThreading. Multitasking is much better on a Pentium 4. Most applications are also optimized for Intel chips because thats what 80% of the desktop PC's have in them. The new 6xx series Pentium 4's also have EM64T now.

Windows XP 64-bit isn't worth installing right now. Its still in beta stages and there aren't really any 64-bit applications and games to even take advantage of 64-bit. 64-bit drivers are also still scarce.
 
burningrave101 said:
I realize the memory controller is integrated on-die instead of being in the Northbridge but if there is no bus between the CPU and the memory then the data couldn't get from the RAM to the CPU. You forget that the RAM isn't integrated on-die as well
Click to expand...
hehehe, don't be silly, of course the ram isn't on die. though it would be majorly hot if it was :D (though upgrading would suck)

here's how it breaks down for me:

cpu <--> memory controller <--> memory

there is.. no bus between the memory controller and the memory. nor the memory controller and the cpu. they're just connected.
if anything is a bus, its the memory controller, connecting the cpu and the ram.. but it's not really given a name, other than just "memory controller" :p

if i'm wrong.. well please correct me :cool:


edit: just wanted to comment on your last statement about win64. too true. microsoft has really dropped the ball on this one... it's been what.. 2 years now? :rolleyes:
at least rc2 is a lot better than the previous versions. maybe we'll have it out before the end of the year!! hehe
 
(cf)Eclipse said:
cpu <--> memory controller <--> memory

there is.. no bus between the memory controller and the memory. nor the memory controller and the cpu. they're just connected.
if anything is a bus, its the memory controller, connecting the cpu and the ram.. but it's not really given a name, other than just "memory controller" :p

if i'm wrong.. well please correct me :cool:
Click to expand...

Yea but dude, if they are connected then there is a bus. A bus is an interconnection highway between devices. Its what the data travels on from one place to the next. If there is no bus between the CPU and the memory then it can't go anywhere. The data from the RAM has to travel to the CPU whether the memory controller is integrated on-die or not.

This is why the HTT is referred to as the FSB. The FSB was only a connection between the CPU and the memory. The HTT on an Athlon 64 however is the point to point connection between all devices.

I'm guessing that bus between the RAM and CPU is just part of the HyperTransport bus and it runs at the same speed as all the other HTT links.
 
it should be whatever bus is between the memory controller and memory on all other ddr systems.
i dunno what connects the memory controller and cpu core though. probably something similar to that the L1 and L2 cache use to transfer data over.
 
(cf)Eclipse said:
it should be whatever bus is between the memory controller and memory on all other ddr systems.
i dunno what connects the memory controller and cpu core though. probably something similar to that the L1 and L2 cache use to transfer data over.
Click to expand...

The only thing that makes sense for it to be is the HyperTransport link and it runs at 1000Mhz (2000Mhz effective) at default.
 
between the memory controller and the ram? honestly? no, it makes no sense to me.
also for the link between the cpu core and memory controller... that link is probably an amd proprietary link, custom tailored for the task.
 
(cf)Eclipse said:
between the memory controller and the ram? honestly? no, it makes no sense to me.
also for the link between the cpu core and memory controller... that link is probably an amd proprietary link, custom tailored for the task.
Click to expand...

How could it not make sense to you? The data comes from the hard drive and is stored in the RAM and then accessed by the CPU. That data in the RAM has to physically travel to the CPU that houses the memory controller just as the data had to travel to the Northbridge which used to house the memory controller. The memory controller can't just reach out and grab the data in the RAM. And in order for data to move there has to be a direct link which is called a bus. The HyperTransport bus is that bus.
 
but then what connects the memory controller to the ram on systems without hypertransport?

i'm sorry. i wish i could put a name on whatever bus is between the memory controller and ram, but there just... isn't one. it's a bunch of traces on the mobo that connect the ram to the memory controller.. nothing more.

also, the cpu requests the chipset to get data from the hard drive. it goes through the sata/pata cable, to the chipset, down the ht link, into the crossbar switch to connect the ht link to the memory controller then it goes to the memory. unless maybe it goes into the cpu, gets assigned a memory address, then back out through the memory controller to the ram.
 
(cf)Eclipse said:
but then what connects the memory controller to the ram on systems without hypertransport?

i'm sorry. i wish i could put a name on whatever bus is between the memory controller and ram, but there just... isn't one. it's a bunch of traces on the mobo that connect the ram to the memory controller.. nothing more.
Click to expand...

And just exactly what kind of K8 system exists without a HyperTransport link or some other from of bus interconnected networking system?

Data cannot travel freely on a motherboard without a bus for it to travel on. Just because you put the memory controller in the CPU doesn't mean you eliminate the bus. All you did was change the location of the controller. That doesn't change how the controller functions.

I talked to a few other knowledgable people on the subject a minute ago over IRC and they all agreed to it having a bus between the CPU and RAM and that it makes no sense for there just simply not to be anything there.

Do you have any information that states there is no bus between the CPU and memory that you can link to?
 
hmm, there's some confusion here.

i was refering to all the boards that had ddr, like all the nf2 boards, every single intel board.. what bus goes between the memory controller on the northbridge and ram on them? whatever the answer is, it's the same for K8, just that the memory controller has been moved. nothing more.
and i know there's a bus, i never said there isn't, just that there's not really a name for it. before there was FSB, but that was the link between the cpu and northbridge, which had the memory controller. now, by that definition, the FSB is whatever the CPU speed is, because the link between the memory controller and cpu runs at the same speed.. as the m.c. and cpu :cool:
 
(cf)Eclipse said:
hmm, there's some confusion here.

i was refering to all the boards that had ddr, like all the nf2 boards, every single intel board.. what bus goes between the memory controller on the northbridge and ram on them? whatever the answer is, it's the same for K8, just that the memory controller has been moved. nothing more.
and i know there's a bus, i never said there isn't, just that there's not really a name for it. before there was FSB, but that was the link between the cpu and northbridge, which had the memory controller. now, by that definition, the FSB is whatever the CPU speed is, because the link between the memory controller and cpu runs at the same speed.. as the m.c. and cpu :cool:
Click to expand...

The bus between the CPU, Northbridge (memory controller), and RAM on an NF2 board is the front side bus (FSB). There has to be a bus between the CPU and RAM for the data to get to the memory controller on the CPU.

And where does it say that the link between the memory controller and the CPU run at the same speed? Its the memory controller itself that runs at the same speed as the CPU. That doesn't really have anything to do with the bus between the two.

The Athlon 64 has two external buses. One to access to the RAM memory, and the other to access the chipset. This second bus is called HyperTransport. Theoretically this architecture is better, since there is only an external bus in the other processors, which is used to communicate with the chipset (the north bridge circuit), which is responsible for the communication both with the RAM memory and with the other circuits of the computer. In theory, the Athlon 64 can communicate with the memory and with the other circuits of the computer at the same time, something impossible in the other processors, for there is only one communication way.

Another advantage of the HyperTransport is that it has a path for the transmission of data and another one for its reception. In the traditional architecture used by the other processors, a single path is used both for the transmission and for the reception of data. In theory, the Athlon 64 can transmit and receive data to the chipset at the same time.

The HyperTransport bus works at 3,200 MB/s in each direction (as it was explained, this bus uses one transmission path independent from the reception path) and that is why it is listed as being a 6,400 MB/s bus, which is not true and is one of the main misunderstandings published in the market. In brief, it is as if we said that a highway has a speed limit of 130 MPH just because there is a speed limit of 65 MPH in each direction.

This bus works at 800 MHz, transferring two 16-bit data per clock pulse, reaching a performance as if working at 1,600 MHz. Thus another misunderstanding is saying the external bus of the Athlon 64 is 1,600 MHz. Usually when we say "external bus" we are referring to the communication of the processor with the memory which, in the case of the Athlon 64, is performed at 200 MHz, transferring two data per clock pulse, in other words, "400 MHz."

It is important to notice that this bus can work at four transference rates: 400 MHz (800 MB/s), 800 MHz (1,600 MB/s), 1,200 MHz (2,400 MB/s) and 1,600 MHz (3,200 MB/s). VIA, one of the main manufacturers of chips for motherboards, claims its chipset for the Athlon 64, the K8T800, is superior to the competition for working with the HyperTransport bus at 1,600 MHz, accusing the competition (without mentioning names) of not working at the maximum transference rate the HyperTransport permits, but rather at one of these inferior taxes (see details at http://www.via.com.tw/en/k8-series/hyper8.jsp). We have to bear in mind that the AGP 8x bus works at 1 GB/s. Therefore, the HyperTransport is 3 times faster than this bus. Even if a manufacturer decreases the speed of the HyperTransport to 1,200 MHz or even to 800 MHz, this bus will continue working faster than the AGP 8x bus. In other words, even if this is true, to us this doesn't necessarily cause problems to the performance of the PC.
Click to expand...

http://www.hardwaresecrets.com/article.php?id=19

From that article it looks to me like the guy from neoseeker was correct in saying that there is two seperate buses one of them being the HyperTransport bus to the chipset and another bus between the CPU and RAM that runs at 200Mhz by default although i'm still not sure what we would call it since LDT is the same thing as HTT. It almost seems logical for it to still be called the FSB because it functions in the same manner as the FSB on any other system whether there is a memory controller integrated into the Northbridge or not. The data is just going directly from the RAM to the CPU instead of from the RAM to the Northbridge to the CPU.

It makes no sense for the bus to run at the same speed as the processor because a bus running at 2.2Ghz (3500+) would be pointless as that amount of bandwidth could never be used. The memory controller itself however is operating at 2.2Ghz (3500+) in conjunction with the CPU speed.

EDIT: Here we go :D.

The Athlon 64 has completely bypassed this mechanism and placed the memory controller directly on the CPU. The CPU itself has a direct, high-speed connection to the RAM. When the Athlon 64 wants to access a piece of memory, it simply fetches the data itself directly from memory. Because of this direct path, the latency from when the data is requested to the time that it is received is significantly reduced.
Click to expand...

Check out the diagram in the article for the Athlon 64. The memory controller on the 3200+ communicates with the RAM at the speed of 2Ghz but the data from the RAM is transferred via the bus at 200Mhz default x 2 (DDR).

http://www.silentpcreview.com/article169-page1.html
 
looks like confusion of names again ;)

so it's confirmed that FSB is the speed between the memory controller and the ram? then how come when you set the 'FSB' at 200mhz and then use a ram divider of 166mhz.. what happens then? the link between the memory controller and ram is actually 166mhz, but apparently the 'FSB' is still 200mhz. thus why i said that the FSB is the bus between the cpu and memory controller.


somehow i feel like i'm just having stuff thrown at me for the sake of proving me wrong, the first quote details how the hypertrasport link works, after clearly stating in the beginning that "The Athlon 64 has two external buses. One to access to the RAM memory, and the other to access the chipset. This second bus is called HyperTransport."
so that has nothing to do with ram, just how the cpu gets data to the chipset, which we've established already, and agreed upon ;)

as for that last statement.. it says nothing about the link between the memory controller and the cpu. just that the memory controller communicates with the ram at 2ghz. which isn't right, as it's technically impossible to send a signal across the pcb at 2ghz.
 
(cf)Eclipse said:
looks like confusion of names again ;)

so it's confirmed that FSB is the speed between the memory controller and the ram? then how come when you set the 'FSB' at 200mhz and then use a ram divider of 166mhz.. what happens then? the link between the memory controller and ram is actually 166mhz, but apparently the 'FSB' is still 200mhz. thus why i said that the FSB is the bus between the cpu and memory controller.
Click to expand...

I never said it wasn't. The FSB is the bus between the CPU and Northbridge (memory controller). Its also the link to the memory because without it the data couldn't get to the CPU. The FSB operates at 200Mhz default x CPU data rate and the data exchange between the Northbridge and memory is 200Mhz default x 2 (DDR).

=(cf)Eclipse said:
somehow i feel like i'm just having stuff thrown at me for the sake of proving me wrong, the first quote details how the hypertrasport link works, after clearly stating in the beginning that "The Athlon 64 has two external buses. One to access to the RAM memory, and the other to access the chipset. This second bus is called HyperTransport."
so that has nothing to do with ram, just how the cpu gets data to the chipset, which we've established already, and agreed upon ;)
Click to expand...

Yes i know that. My intentions of this thread was to explain to others how the HyperTransport bus and CPU/Memory bus works on an Athlon 64. Not just to prove you wrong :p.

=(cf)Eclipse said:
hehehe, don't be silly, of course the ram isn't on die. though it would be majorly hot if it was (though upgrading would suck)

here's how it breaks down for me:

cpu <--> memory controller <--> memory

there is.. no bus between the memory controller and the memory. nor the memory controller and the cpu. they're just connected.
if anything is a bus, its the memory controller, connecting the cpu and the ram.. but it's not really given a name, other than just "memory controller"

if i'm wrong.. well please correct me
Click to expand...

Remember you said earlier that there was no bus between the CPU and the memory and that they were just connected by traces on the motherboard. Well so far we've already established that there is two external buses and one of them is between the CPU and memory while the other is the HyperTransport link between the CPU and the chipset.

=(cf)Eclipse said:
as for that last statement.. it says nothing about the link between the memory controller and the cpu. just that the memory controller communicates with the ram at 2ghz. which isn't right, as it's technically impossible to send a signal across the pcb at 2ghz.
Click to expand...

Look at the diagram dude. It shows it right there. You see the arrow going from the memory controller to the RAM at 2Ghz and the arrow going from the RAM to the memory controller at 200Mhz x Memory Data Rate? Well thats how it works.

And if its technically impossible to send a signal across the PCB at 2Ghz then its impossible for the memory controller to run at the same speed as the CPU lol. The memory controller communicates with your RAM. If the processor is 2Ghz then it would have to communicate with the RAM at 2Ghz in order for it to be functioning at the same speed as the processor.
 
"and i know there's a bus, i never said there isn't, just that there's not really a name for it."
there's a bus between the ram and memory controller, just one that i don't know the name of. it's definitly not HT or FSB though. i'll call it the ram bus, cause regardless of what the name is, it runs at the speed of the memory. just it can just be called the ram speed.. ignoring the 'bus' word all together. i don't like 'busses. instead, i think we should call it the...
HYPERTRANSPORT TRAIN OF INFINITE DOOM :D

yeah, but all joking aside, i think i there's only two things i feel the need to comment on, and they are kinda interlinked



I never said it wasn't. The FSB is the bus between the CPU and Northbridge (memory controller). Its also the link to the memory because without it the data couldn't get to the CPU. The FSB operates at 200Mhz default x CPU data rate and the data exchange between the Northbridge and memory is 200Mhz default x 2 (DDR).
Click to expand...
you're slowly changing what you're saying, but that's ok. i am too ;)
such compromise is good, as long as we come to a correct conclusion. however that would mean that we have two fsb's that run at different speeds, due to that memory divider. there will be the FSB between the cpu and (off-die) memory controller at 200mhz, and the fsb between the MC and ram at 166mhz. that causes issues with me, because you can't have one variable with two values :eek:



And if its technically impossible to send a signal across the PCB at 2Ghz then its impossible for the memory controller to run at the same speed as the CPU lol. The memory controller communicates with your RAM. If the processor is 2Ghz then it would have to communicate with the RAM at 2Ghz in order for it to be functioning at the same speed as the processor.
Click to expand...

two words: memory divider
the specifics aren't clear (obviously :p) but i'm guessing there are two sections of the memory controller. the one that deals with all the logic and communicates with the cpu runs at the cpu clock speed (or on non-K8 boards, the FSB). then there's a divider that slows down the part that communicates with the ram. that way we don't have to have 2ghz signals running across the pcb (side note: which makes that spcr article misinforming) and the memory controller is still running at clock speed like everything i've seen says.
for those non-K8 boards i mentioned, it'll be the same, but 200mhz on one side and 166mhz or whatever the divider dictates on the other.
 
Dudes.

Bus is a term for a bunch of wires in parallel. That's what there is between the mem controller on this board and every other board. It SHOULD be exactly the same for every board, in fact, it should be determined by JEDEC standards. Not AMD, not Intel. (obviously, some people will have better signal integrity because they use more layers... blah blah blah)

There is a bus, but it is irrelevant to the overall picture.

Back in your corners! :D
 
A TRAIN I SAY!!!!
:D

though, would you happen to know much about how the memory controller functions mwarps? i'm still trying to figure out what various parts run at various speeds.. and how. and i can't find much documentation on it :mad:
 
(cf)Eclipse said:
however that would mean that we have two fsb's that run at different speeds, due to that memory divider. there will be the FSB between the cpu and (off-die) memory controller at 200mhz, and the fsb between the MC and ram at 166mhz. that causes issues with me, because you can't have one variable with two values :eek:
Click to expand...

No i didn't mean there is two FSB's. There is only one FSB and that is the bus between the CPU and the Northbridge that houses the memory controller. The link between the memory and the memory controller runs at a ratio of the FSB speed whether it be 1:1, 5:4, 3:2.



With the Athlon 64 the memory is accessed by the MC at the speed of the CPU and the data is retrieved at the speed of the RAM x 2 (DDR).



two words: memory divider
the specifics aren't clear (obviously :p) but i'm guessing there are two sections of the memory controller. the one that deals with all the logic and communicates with the cpu runs at the cpu clock speed (or on non-K8 boards, the FSB). then there's a divider that slows down the part that communicates with the ram. that way we don't have to have 2ghz signals running across the pcb (side note: which makes that spcr article misinforming) and the memory controller is still running at clock speed like everything i've seen says.
for those non-K8 boards i mentioned, it'll be the same, but 200mhz on one side and 166mhz or whatever the divider dictates on the other.
Click to expand...

Based on what information though? What article states that the memory controller does no communicate with the RAM at the speed of the CPU? Its been said in article after article that the on-die memory controller operates at the same speed as the CPU. If it didn't then we wouldn't see the performance we do from the Athlon 64. The memory controller alone is the primary feature of the Athlon 64 that gives it the performance over the Athlon XP in 32-bit code.

And why can't you send 2GHz and higher signals across the PCB? Link me to an article that says you can't. Link me to something that says the Athlon 64 only communicates with the RAM at a ratio of the CPU speed.

I'm sorry dude but i've read alot of A64 articles and i've never seen any of them say that. If you can link to some information that does stipulate this then maybe we can take it from there.

That article at SilentPCReview got their information from the extensive K8 architecture overview at CPUID.com.

http://www.cpuid.com/K8/index.php

The clock generator always drives the north bridge, and provides the reference frequency for the HyperTransport link between the north bridge and the CPU. The HyperTransport frequency can so be considered as the FSB, because the CPU uses this frequency to generate its own internal clock, through an internal multiplier.
As shown on the diagram, the memory controller speed is the same than the CPU speed. Memory requests are consequently sent at the CPU speed, on a 64/128 wide bus, according to the number of memory channels. We can see there is no more link between the clock generator and the memory. The memory clock is so obtained from the CPU clock, divided by a factor that depends on the memory specifications. The table below shows the dividers used according to the CPU frequency and the requested memory clock.

Of course, the integrated memory controller does not improve the memory bandwidth, but it allows to drastically reduce the request time. The measured latency is very low, as we'll see further. Moreover, unlike an external memory controller, the performances of the integrated controller of the K8 increase as the CPU speed increase ; consequently, so does the requests speed.
The integrated controller has a particular interest for multi-CPUs systems : in this case, the addressable memory size and the total bandwidth increase with the number of CPUs.

The problem with the integration of the memory controller is the lack of flexibility. The controller is dedicated to a memory technology, and every change in memory standard will need a change in the CPU design. Of course, this does not occur very often (at least not so often as CPU family change), but this could drastically increase the cost of the CPU, as its manufacturation process needs to be changed.
Click to expand...
 
You must log in or register to reply here.
Back
Top