Sign in with
Sign up | Sign in
Your question

FSB on Athlon XPs??

Last response: in CPUs
Share
August 2, 2002 8:58:10 AM

Thinking about putting together a new system, based on Gigabyte GA-7VRXP mobo because I like the thought of DDR333. But all the XP's I found on Pricewatch seem to indicate a FSB of 266 MHz! What's going on here? Have they misunderstood their product, or is there a different version of the XP that runs at 266, or what?
I'm not very literate in all this stuff, so please type any replies slowly, so I can read 'em slow.
Many thanks.

More about : fsb athlon xps

August 2, 2002 10:16:45 AM

All Athlon XPs Run at a FSB of 133, which is DDR, so the theoretical actual bus speed is 266Mhz.

Boards which support RAM at 333 will usually allow different clock speeds for the RAM and the CPU FSB. It IS possible, with the right cooling and parts, to run an Athlon XP at 333Mhz, but this is pretty hardcore overclocking, and won't be supported by AMD.

HTH

<font color=blue><i>Your</i> PC may be quieter, but <i>my</i> PC makes a better hairdryer!</font color=blue>
August 2, 2002 10:17:48 AM

it is right, they all (APX) have a 266 mhz fsb, but the memory runs at up to 333 mhz.

<b><font color=orange>sing to prolong HDD life; spin right round like a record baby Right round round round
Related resources
August 2, 2002 11:36:56 AM

if you`re not gonna use 166fsb on a a-xp(and if u wanna use 166mhz fsb, then u have to unlock the L1 bridges), the 333MHz DDR doesn`t help really much. the guys who replied to u mean that u can use a 133 FSB with unsynchronized 333MHz DDR ram, but this has almost no difference with synchronized 266MHz DDR ram. if u really want the 333MHz mobo to be worth its salt, you`ll have to unlock the a-XP, but that will risk your chances of getting a garantee.

"Is Celeron good?"
"No. Celeron is bad."
LOL
August 2, 2002 3:41:00 PM

There are some rumours that there will be 333 MHz FSB Athlon XP in Q3/4... but this are all RUMOURS, AMD haven't made it official.

If you unlock the CPU you can change the multiplier (multiplier*FSB=CPU speed ie:12*133.33=1600MHz)... this can be done very easely (IMO)... with the new XP2200+ with T-bred core you just have to close one bridge to make the multiplier adjustable downwards. The XP2200+ runs at 133(266 DDR) Mhz FSB and with a 1800 MHz CPU speed, the multiplier is then 13.5. Lets say you set the FSB to 166 then you're CPU speed will be 2250 MHz, which is maybe reachable with liquid hydrogen cooling. To get the speed back around the 1800 MHz you have to lower the multiplier. The multipliers you can best choose are then: 10.5 or 11 (10.5 is somewhat slower the 1.8 GHz and 11 is somewhat faster), you wont need a better heatsink for such smale overclocks. The 'old' Athlon XP version with the Palmino (?)core is also unlockable, but instead of one you then need to close 5 bridges.
If you're interested I can learn you how to unlock your CPU... but remember that this will void your warrenty.

My watercooler contains so much water that the moon has influence upon it :eek:  .
August 3, 2002 7:08:41 AM

"There are some rumours that there will be 333 MHz FSB Athlon XP in Q3/4... but this are all RUMOURS, AMD haven't made it official."

Yes the rumors are basically about Barton and how it will have 166mhz fsb and have a larger cache. Of course all still rumors but the inquirer has been right many times.
August 3, 2002 12:53:46 PM

Well I heard some new one that claim to come from an AMD-worker about AMD testing and revising the T-bred core so it can run faster and that there probably will be 166 MHz samples because without a higher multiplier (max is 14x if I'm correct) the speed will be very limited.

My watercooler contains so much water that the moon has influence upon it :eek:  .
August 3, 2002 1:00:06 PM

How does Intel achieve those crazy multipliers around 20? Does that require it to have it's long pipeline, or can the multiplier be programmed for that setting on any processor? I know the Athlon is running out of gas for scaleability, but I still don't quite understand the thing behind multipliers and scaling.

"When there's a will, there's a way."
August 3, 2002 1:40:14 PM

Yeah it is mixing, however the Athlon is not at the end of its days.
Added IPC or performance per clock DOES NOT destroy scalability as most think. Of course a 10-stage core can go as far as it can until it stops, but they can go on till 0.09m K7s and they would still ramp. It all depends on AMD's yeilds, and how they can push the electrons in the silicon. Maybe Matisaro has some more semiconductor info on this, however I personally don't beleive it is at the end. Until AMD confirms...

--
The sound of determination is the echo of will...
August 3, 2002 2:30:11 PM

I personally would like to see the .09 Athlon (Barton?) hit 3.0Ghz. Might be possible under .09, but i'm sorta doubting AMD's .13 for their 10 stage pipeline K7 hit beyond 2.5Ghz or so. SOI would be nice, should definately help scaleability, although it looks like the Hammer may have worse scaling than originally estimated. 2.0Ghz is very high for a release model, i'm having a little doubt of my own whether or not they can deliver the first .13 Athlon Clawhammers.

"When there's a will, there's a way."
August 3, 2002 3:27:53 PM

Though I haven't been around on this forum for quite a while, I think I still can add some more useful information to the replies above:

Yes, it is correct that there are 333 MHz mobo's (Okay, 166 MHz DDR), but as the other said, that number concerns the memory. And yes, up to now Athlon XP's haven only had a 266 MHz (Okay, 133 MHz DDR) FSB. So normally, indeed there would be hardly any difference at all between a 266 MHz board and a 333 MHz board, but still there is.
First of all, how can thus difference in speed exist? Well, in today's computers architecture, there is the CPU that communicates with a chip called the nortbridge of the motherboard. This chip in turn communicates with the rest of the computer, including the memory. And the speed of the communication between the northbridge and the memory, that is what they mean with the 333 MHz.
Though I could go on explaining these things very detailed, I think that with a little help from Google or some browsing in the 'motherboards'-section of tomshardware.com, you can find very clear and detailed explenations of what I just told you. I'm sorry, but in three weeks I have exams, again, so I can't spend any more time than this ...

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
August 4, 2002 9:58:05 AM

The problem with different FSB and memory speeds is that it can create more latency which will results in a slower interaction between CPU and memory through the Northbridge.

My watercooler contains so much water that the moon has influence upon it :eek:  .
August 4, 2002 10:41:33 AM

Don't efficient caching algorithms should be capable of eliminating those latencies? The fact that the Via KT266a with PC2100 is outperformed by the KT333 with PC2700 DDR-RAM quite proofs this. Though the performance increase there could also be due to general optimisations.
One thought, though. Shouldn't the increased data-throughput from the RAM to the northbridge be capable of compensating the latency induced by the async clocks? I mean, if just look at the numbers, and compare PC2100 CL2 DDR-RAM to PC2700 CL2 DDR-RAM, the amount of clock cycles you need for the RAM to respond is the same, but at 166 MHz 2 clock cycles is shorter than in 133 MHz operation.
Wait, let's calculate something (plz, proof me if I'm wrong ... or if I'm calculating foolish things ...). 133 MHz implies a 7.5 nanosecond clock cycle, 166 MHz 6.0 ns. 2 clock cycles equal 15 ns and 12 ns, respectively. So, PC2700-CL2 RAM provides data 3 ns faster. This happens to be half a clock cycle of the FSB bus (at 133 MHz), which can be taken advantage of in a DDR-system, because there, two times per clock cycle, data is transferred. So I think a a PC2700 system is able to provide data with LESS latency than a PC2100 system.
In a constant data stream, I guess, the asynchronuous bus clocks could lead to problems, since the RAM is providing data at about 1.25 times the FSB's speed. So about once every four clock cycles the RAM is one clock cycle ahead of the FSB. But I think this problem is eliminated quite easily by implementing caches on the northbridge.
So, actually, I don't see any lantency-enlarging mechanisms in this setup. But since I have read all over the internet that asynchronuous setups actually DO enlarge the latency, I must have made a mistake here ... Hmmm ... Confusing ...

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
Anonymous
a b à CPUs
August 4, 2002 2:35:59 PM

You are leaving out one important point in your reasoning. I think this might help.

Think of asynchronous data transfer between memory and CPU like plumbing pipes. The FSB has a 266MHz pipe but the memory is supplying it with a 333MHz pipe. Since you can't get more than 266MHz through the FSB, having 333MHz memory is just wasted. The FSB just keeps taking data at it's rated speed even though the memory could supply more.
August 4, 2002 3:59:35 PM

Then again, the latency of the FSB is shorter than that of the memory, and having the memory running at higher speeds can reduce that latency, as I reasoned some hours ago.
What I was trying to point out in the post above, is that there is actually no reason to believe that the async clock setup would cause higher latencies, as Svol said. Concerning the data throughput, indeed, there can get no more data through the FSB on a system with a 333 MHz memory subsystem then on one with a 266 MHz mem subsystem.

Also an improvement to the overall system performance could be the fact that when the CPU is accessing the memory and at the same time a DMA-device or the AGP card is doing AGP texturing, advantage can be taken from the larger memory bandwidth. Though I'm not sure wether concurrent CPU-to-RAM and DMA access is allowed ...

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
Anonymous
a b à CPUs
August 4, 2002 4:33:41 PM

"What I was trying to point out in the post above, is that there is actually no reason to believe that the async clock setup would cause higher latencies, as Svol said."

Maybe svol was just trying to point out that in this situation there is opportunity for mischief in a bad design. But I agree there shouldn't be.

"Also an improvement to the overall system performance could be the fact that when the CPU is accessing the memory and at the same time a DMA-device or the AGP card is doing AGP texturing, advantage can be taken from the larger memory bandwidth. Though I'm not sure wether concurrent CPU-to-RAM and DMA access is allowed ..."

Agreed. Good point.
!