The reason is that the "333" and "800" mhz is total BS. It's what we call, "Marketing Megahertz."

The ACTUAL frontside bus speed of a "333mhz" bus athlon system is 166mhz. The ACTUAL frontside bus speed of an "800mhz" bus p4 system is 200mhz.

Same goes for 266/533/400/etc. What these architectures do is use methods similair to DDR to achieve higher throughput using the same amount of cycles - more work per cycle. If, say, using one method, you can transmit 1 gig of data per second @ 133mhz, but then discover a way to transmit 2 gigs of data per second @ 133mhz... it's the same as if your first method was @ 266mhz.

One of the numerous reasons a p4 doesn't scream ahead like the numbers say it should is that the transfer rate of a supposed "800mhz" is a perfect-world scenario: You never actually achieve throughputs that high and typically never even approach the limits; other components prove to be bottlenecks beforehand.

Originally posted by StormBringer Frontside Bus. I/O buses, which connect the CPU with the systems other components

Click to expand...

Technically the FSB is *not* an I/O bus. It handles I/O only between memory and CPU, as well as handling ISR requests via the PIC. The southbridge (PCI bus) is the I/O bus, pretty much any device other then the cpu will go through the southbridge to access memory. The FSB is more of a "Traffic controller" then anything.

It's really an amazing thing, the way it works, if you get really into it. You can look at brand new motherboards, things produced just months ago.. and look at the technology which is approaching three decades in age.

Bluescreennoob: The primary function of the FSB is, as mentioned above, the memory controller half of your chipset. It is perhaps the second most important component, as it (not as much anymore, but it used to) dictates the operating speed of every other bus on the system. Back in the golden olden days, ALL devices ran at the same speed as the same FSB, even the cpu.

A secondary function of the FSB (although you can sort of say this is just an addition from time) is to handle ISR. When a device requests CPU time, it generates an interrupt service request (ISR) via an IRQ (not so much today, but in the old days, an IRQ was actually one physical wire on the system... you would jumper a device to use one physical line that represented, say, IRQ 7). Now while the CPU can recognize that a device needs CPU time to process some data, the CPU doesn't know WHAT to do. The PIC has a table of functions, which translate the request to a cpu function.