-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
WHat FSB will the athlon 64 fx have?
- Thread starter mrgoblin
- Start date
yhelothar
Lifer
i heard that there won't be much difference.. that's why AMD did not implement it. The reason why it would not have much difference is, when CPU frequencies gets high, the FSB needs to be high to so it can keep up with the CPU. Though Athlon64's aren't clocked very high, thus, it does not need a very high FSB.
Dulanic
Diamond Member
No, what you said is incorrect and that is no reason. Before FSB used to be the limiting factor of memory bandwith... however as Ive said the Athlon 64 has a on-die memory controller and it is linked DIRECTLY to the memory, so the whole meaning of FSB kinda changes with the Athlon 64. All links from the Athlon 64 are hypertransport except to the memory which is just a direct bus. So in the sense of the FSB your thinking of there is none.
Opteron/Athlon 64 processors do not use or have the same old front side bus current PCs currently have.... The processor does not communicate with system RAM over the FSB. The memory controller is built directly into the processor and system RAM is directly connected to this controller. The processor then connects (via another HT link) to the HyperTransport Hub, which also contains the AGP controller. (in a multiproc system each processor has its own HT Link to the HT Hub, and to a HT link to an adjacent processor(s)!)
There are 3 standard HT link speeds, 400mhz, 800mhz and 1.6Ghz. Each HT link can be 2, 4, 8, 16, or 32 bits wide. In its fastest configuration (1.6Ghz, 32-bit) it will be able to transfer up to 12.8 GIGABYTES per second. This leaves quite a bit of room for expansion. Currently no processor pushes that much data per second.
In multiprocessor situations (this is based on articles I've seen on the Opteron) I believe the Processor to Processor link runs at 1.6Ghz and 16/32-bits. Then the processor to HT Hub link (HT Hub contains the AGP controller) runs at 800mhz and 16/32 bits. With the HT Hub to Southbridge link running at 400mhz and 16/32 bits. Since the links already provide more bandwidth than the processor will actually use making them go faster would prove pointless. And in a mutliproc system the Proc to Proc HT links are already running at their fastest speeds.
The clock speed on some Opteron boards is adjustible from what I have seen in some Opteron articles. These adjustments do not affect HT link speeds in the least bit, they only affect the clock rate at which the processor runs. And the memory clock seems to be adjustable as well.
Dulanic
Diamond Member
It will surpass it... there is alot less latency since the memory travels straight to the CPU, it no longer has to travel through the northbridge and then go across the FSB to the CPU at a limited speed. Now the memory bandwith is only limited by how fast of memory the CPU will support itself.
Zugzwang152
Lifer
cache amounts? athlon64 is coming with 256k and 512k options. opterons come in 512 and 1mb no? could be wrong here.
Red Dawn
Elite Member
There will be a lower end Athlon 64 that has only 265k of cache and will run only in 32 bit mode
Lower end cost effective Athlon64
The athlon 64 fx like other hammer processors will not have a FSB to system. The traditional FSB we all know is from CPU to memorycontroller and Backsidebus(BSB) is cpu to L2 cache. Since it is integrated the FSB on all hammer processors now depends on the CPU's clock speed. if it is 2Ghz the FSB is 2ghz. That also means that it can support any memory speed type as long as the speed of the ram is not more than the CPU's clock frequency and it's l2 cache throughput... The integrated memory controller is then connected to the "memory Bus". This can be 100,133,166,200 DDR depending on AMD to what ram speed they will like to support these days. On like todays fsb's the cpu is connected to the northbridge 'memory controller' and then to the 'memory bus'. This is also limited because as cpu clock speed grows latency does not reduce. FSB remains the same. Also this only allows one read/write opteration per cycle. That means that you cannot read and write at the same time no matter how much bandwidth you have*(6,4Gb/sec++). But hammer systems don't work like that. The memory bus does not require any distrubance from the system. The cpu and the memory will be happy 🙂 . If data need to be read from memory it will pass through the cpu and then hypertransport link to the system.
Behind the cpu core is a hypertransport Bus. It supports various frequency's. 200/800Mhz DDR upstream/downstream datapads. It can carry various amounts of bits up to 32bits and also more than one read/write operation per clock cycle because it is a serial bus unlike traditional FSB's and is bidirectional. Even 20 PCI-Express devices can be connected without problems! Traditional FSB's today have to share the bandwidth. For example a system with 6.4Gb/sec bandwidth will have to share its bandwidth with the AGP bus e.t.c...but on a hammer system this is done parralel with the hypertranspot bus. its like hyperthreading but on hardware level. Therefore I/O bottlenecks will autotmatically be removed. It can even work with only 3,2gb of bandwidht depending on the memory speed and still support pci-express and the rest. What you can conclude from this is that the 'new' FSB here is the speed of the HTB(hypertransport-bus). todays systems work with 800Mhz DDR clocks and 16bits datapad. That will get you a total of 6,4 gb/sec per sec of total I/O throughput with 3,2Gb/sec upstream and downstream read/write instantly. but with 32-bits datapad it can climb up to 12,8Gb/sec with 6,4 gb.sec up/down.
Behind the cpu core is a hypertransport Bus. It supports various frequency's. 200/800Mhz DDR upstream/downstream datapads. It can carry various amounts of bits up to 32bits and also more than one read/write operation per clock cycle because it is a serial bus unlike traditional FSB's and is bidirectional. Even 20 PCI-Express devices can be connected without problems! Traditional FSB's today have to share the bandwidth. For example a system with 6.4Gb/sec bandwidth will have to share its bandwidth with the AGP bus e.t.c...but on a hammer system this is done parralel with the hypertranspot bus. its like hyperthreading but on hardware level. Therefore I/O bottlenecks will autotmatically be removed. It can even work with only 3,2gb of bandwidht depending on the memory speed and still support pci-express and the rest. What you can conclude from this is that the 'new' FSB here is the speed of the HTB(hypertransport-bus). todays systems work with 800Mhz DDR clocks and 16bits datapad. That will get you a total of 6,4 gb/sec per sec of total I/O throughput with 3,2Gb/sec upstream and downstream read/write instantly. but with 32-bits datapad it can climb up to 12,8Gb/sec with 6,4 gb.sec up/down.
The L2 cache has been separated as a BSB since the Pentium Pro for Intel, and the K6-3 for AMD. Far from a traditional FSB.
I don't see why the speed of the memory controller must not be less than the speed of the RAM, and same with the L2 cache throughput. You can always run the memory frequency faster than the speed set by the clock generator for a memory controller located in the North Bridge simply with a multiplier. This should also apply to an integrated memory controller. The L2 cache is located on the other side of the memory controller and therefore is not limited in any way by the memory controller speed. In fact, throughput can be changed for the L2 cache (apart from processor clock speed, and any multiplier) simply by increasing the width of the L2 cache bus. If I have interpreted your statement incorrectly and you mean that memory bus throughput cannot exceed L2 cache bus throughput, well, it is unlikely that this will ever happen. The memory hierarchy forces larger memory sizes to have higher latencies the further they are from the processor.
Direct memory access without CPU arbitration....this already exists for AGP Fastwrites, does it not?
Again, this is a feature that already exists on the current Athlon systems.
Yes i think i missed out somethings..my bad. Forget about athlon system's and of AGP fast writes. What you said was right. About the points of l2 cache ws also true but about the memory speed and memory controller..what i meant was it can only be based on two factors that must not override each other: the bus speed or bus width.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
-
-