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.

Bus agent: An agent is a device or a combination of devices that represent a single load on the bus.

 

Agent ID: The agent has to have a way to identify itself. No, "007" is not a valid Agent ID. 

 

Active signal: All of the signals we'll be talking about here are "active low". This means a low voltage corresponds to an active signal, and a high voltage corresponds to an inactive signal.   It sounds backwards, I know, but that's how it is. The GTL+ bus protocol that the PII employs determines if a signal is high or low by using a reference voltage (which is 2/3 the termination voltage). By default, the termination voltage at the pins on the chip is held high at 1.5V.  To assert a signal on a pin (to generate an active signal), you bring the line low.  This 1.5V thing may sound like extraneous information, but it isn’t.  So remember it because it'll come up again in a moment.

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. 

It’s 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