Paxville
Put simply, Paxville DP means a pair of 2.8GHz Netburst processor cores (longer pipeline Netburst at that) with 2MiB of L2 cache per core, on a 200MHz shared bus link to the memory controller. Each core also has HyperThreading, allowing a pair of scheduled threads to run on that core's single set of execution resources. So for each Paxville CPU in a system, should HyperTheading be enabled for the CPU cores, the operating system will see four 'CPUs'. All modern operating systems have support for HyperThreading, so that's not a problem.I mentioned the longer pipeline Netburst core for Paxville, which means that when codes being run on the CPU are cache and memory subsystem agnostic, they'll run at the same speed as other CPUs out there with the same basic pipeline configuration and HT. Think Pentium 4 520 or 620. Both have 2.8GHz cores with 31-stage main integer pipes. Don't think Pentium D 820, though, since its Smithfield core is not HyperThreading-able, unlike Prescott-1M/2M or Paxville.
With two cores, each separate from each other and sharing no resources, there's over 300 million transistors per CPU, built on the company's 90nm major process node. Being a late-generation Netburst core it also sports a number of the latest on-silicon power-saving initiatives to come out of Intel in recent times, along with support for EM64T, the Intel implementation of AMD64 discussed on the previous page. In terms of power saving stuff, Paxville implements the latest Intel SpeedStep technology block, which Intel call Demand Based Switching on workstation and server platforms. DBS adjusts what are called P-states, of which a number are implemented inside a modern processor. Those P-states set out a clock level based on multiplier, and a voltage to go along with that clock level, that determine how the clocking mechanism can scale the performance (speed and per-watt) of the CPU.
Fiddle with P-states and you change processor frequency and power consumption, based on load/demand (usually). DBS is the Intel mechanism for Xeon, and Paxville supports the latest version of that technology. Paxville also supports what folks like me like to call the C1E halt state. Pretty much another P-state adjustment, C1E also adjusts processor load and consumption by running it at its lowest possible multiplier and voltage after software issues the HLT command.
Lastly, there's support for Intel TM2, which is a throttling mechanism for when the CPU gets too hot. The CPU only executes code on every second tick of its internal clock (the 2.8GHz of the Paxville Xeon DP), effectively halving its performance without adjusting frequencies, something which can cause software timing problems under load.
The CPU will choose what to do - TM2 throttle, C1E halt or P-state adjust - based on software and hardware conditions on the host platform. Good stuff given 90nm Netburst cores with long pipes get toasty, and Paxville has two of them. With twice the L2. More on heat and things later.
I'd take the chips out of the test system and photograph them for your viewing pleasure, but I fear the gravity shift generated by the heatsinks keeping the CPUs cool would cause me severe problems, and hinder my ability to write. They're contained in a Socket 604 Xeon package, though, and slide into a 'Dual-core Ready' Xeon mainboard with a few chipsets to choose from. So with all that CPU tech absorbed (it's just a 2.8GHz 2MiB dual-core P4 with HT as far as the basics go, if you can't be bothered remembering the rest), let's talk E7525 and the specific Armari integration we used to write this piece.
