Not since Rudy Ray Moore broke out the
polyester bell-bottoms in "Avenging Disco Godfather" has anyone stuck it to tha'
man like hardware hacker Tomohiro Kawada. Tomohiro didn't just overclock a few
Celerons and call it quits; nope, he broke out a pair of pliers and a blowtorch and got
medieval like Marsellus Wallace with a machine that was never supposed to be built: the
dual-Celeron 450. The only way to stick the man any harder would be to build one of these
things and use it as a tax write-off. Little did he know that he was opening up a
big Pandora's box, not only getting the attention of hardware geeks on the low-down, but
also the attention of companies wanting to capitalize on the ever-growing overclocker
population. Now that becoming an SMP-bustin, Celeron-overclockin' fool is as easy as
buying a motherboard and two CPUs, Intel is definitely showing signs of frustration.
For a detailed discussion of how Celerons used to be overclocked, back before the days of the BP6 and Slotkets, you should try to head over to Tomohiro's site, where in a sense, some history was made. Unfortunately, his site doesn't seem to respond anymore, so you might have to go to one of the various sites that regurgitated his information in their own "how-tos." Fortunately for the sake of preservation, most of these sites just reworked his content, keepin' it real. Check out the FastGraphics article for a taste. They've got photographs and "push this, pull here" instructions that will tell you exactly how to go about building one of these freaks of nature, should you want to go retro.
The one thing these sites won't tell you is how exactly all of this stuff works. That's where I came in. My older Dual Celeron article (Winter '98) explained the way in which the little Celeron could be transformed into a veritable PII-SMP killer. I dug around in some Intel manuals and sorted out the whys and wherefores. I've now reworked this information to address some of the new concerns about the Dual Celeron, while still keepin' it real with much of the original information in tact. If you read my original article, or if you already know all about how Celeron SMP works, continue on to my discussion of the issues that are hot today.
To understand what's going on here, you need to know a little bit about dual-processor systems. When you've got two processors, one of the main issues you have to work out is who gets control of the bus and when (this issue is called bus arbitration). Back in the 386 days, when you only had one processor on the bus calling the shots, bus arbitration wasn't an issue. The old Intel CPUs had a bus request pin (BREQ#) that would go low when the CPU needed the bus, and that's all you needed to worry about. In today's world, things are a bit more complicated.
Bus arbitration for Intel SMP systems
The Pentium II is made for dual-CPU SMP systems, so it has two bus request lines, BR0# and BR1#. These two pins make up the BREQ[1:0]# signals that the PII uses to request control of the bus. To help explain how these signals work, we should define some terms.
When you have two CPUs duking it out for
ownership of the same bus, you've got to have some way to decide who wins. In the
case of the PII, the winner is whichever CPU has the lowest Agent ID. The CPU with the
lowest Agent ID will always have priority when it comes to bus ownership. This
method doesn't sound very fair, though. The way to keep one CPU from always hogging
the bus is to change the Agent ID every so often. In an Intel SMP system, Agent IDs
are reassigned whenever the RESET# signal goes active. Intel SMP systems use a
round-robin scheduling scheme to decide who gets what ID. In the case of a
two-processor system, this means that if one processor had the lowest ID the last time the
RESET# signal was asserted, the other one gets it on the next RESET#; the processors just
swap IDs on every RESET#.
Each time the RESET# signal is asserted,
each CPU samples both of its BREQ# pins (BR0# and BR1#) to find out which ID it has been
assigned. The BREQ# pin on which the CPU samples an active level determines its
Agent ID. If BR0# is active, then the CPU's Agent ID is 0. If BR1# is active,
its Agent ID is 1. In this way, each processor is able to identify itself and learn
what its Agent ID is.
Its important for each processor to
know what its own agent ID is, because it uses this knowledge to request the bus.
Remember how I said that a 386 would just assert its BREQ# pin if it needed the bus?
Well, since each Celeron has two bus request pins, it needs to know which one to use when
requesting the bus. Whether it uses BR1# or BR0# depends on what Agent ID it was
assigned. If a CPU has Agent ID 0, it uses BR0# to request the bus; likewise, if it
has Agent ID 1, it uses BR1#. All the agents keep track of the current bus owner,
and they all cooperate to pick the next bus owner in the round-robin scheme.
(By the way, all of the above info on bus arbitration can be extrapolated out for the Xeon. The Xeon has four BREQ# pins instead of two, so you can have four Xeons on one bus, and things work similarly to what I've described.)
Next: How Intel hobbled the Celeron