this from XS
mikeyakame is an egineering student and has explained this very well...credit goes to him.
Originally Posted by mikeyakame
Well let me try and explain it easiest I can.
You have clock signals for each device on the bus, ie CPU, MCH, DRAM, GPU, SMBUS, CMOS, etc.
All the clock signals are driven from the Host Bus BCLK (base clock) and such it is used as a reference point.
Hardware such as CPU, Northbridge, Southbridge, etc all reference Host BCLK to drive their own internal clock signals. They sample certain reference points and values to best ascertain when they need to drive their own clock waves, and when they need to initiate both address and data strobes to communicate across the Host Bus. It's all about timing.
Now as the electrical traces between say CPU and Northbridge are a reasonable length, the data sent from Northbridge to CPU for example won't arrive instantaneously, it will arrive fractions of a nanosecond after it was sent which is picoseconds or PS. Now Intel gives out electrical design specs, and vendors are meant to follow them.
Within specification of the design we might know that minimum transit time will be 150ps when sending any data from MCH(NB) to CPU, so we compensate for the transit time by driving the CPU clock signal 150ps after the Host Bus BCLK voltage crossing point.
This is called skewing clocks. It's just using known data and making compensation adjustments to make sure that critical specs are within tolerance, and that commuincations between external devices on the common bus flow without incidence or get lost in transit.
The default skews are fine within AGTL+ FSB spec. Problem is AGTL+ (advanced gunning transceiver logic) has a design limitation of 400mhz BCLK (400mhz fsb) and past this it is impossible to keep within original spec and guarantee 100% reliable operation. The faster a clock frequency becomes, the smaller clock periods become. Now there is still minimum tolerances that have to be met, whether running 200Mhz FSB or 600Mhz FSB, and this is the kicker...the most critical tolerance called "Period Stability" which is basically the farthest apart two succesive clock signals are allowed to be before the system will hard lock. So whether you run 200 or 600, the Period Stability value, <= 150PS, still comes to play.
To give you an idea.
533Mhz FSB has a clock period of 1.86ns (1860ps)
466Mhz FSB has a clock period of 2.14ns (2140ps)
400Mhz FSB has a clock period of 2.5ns (2500ps)
333Mhz FSB has a clock period of 3.0ns (3000ps)
As clock period gets smaller with FSB frequency increase, the critical stability values don't change and become extremely problematic. You are trying to meet criteria designed around having two times as much time between successive clocks, with successive clocks being driven at double the speed. We've got alot less room for error or instability, so much so that even slight variations will crash or destabilize our system at least with default clock skews designed to be effective upto 400Mhz FSB, not taking into account vendor board design flaws, mass manufacturing variances, and so on.
So this brings me to where the money is
Intel realised this problem and of course secretly had a means of making post-manufacturing compensation through NB registers. So What are CPU and NB Clock Skew values you ask...
They are simply delay values that can be wound in on top of the skew values in the design. As we raise voltages and frequencies we get whats called Clock Jitter, it gets worse the farther you go beyond the electrical design limits of your particular board, also if your PSU can't keep up, and many other reasons. Clock jitter results in unstable clock signals, It could be as little as 50ps jitter, which means that when the clock signal is driven there is a 50ps max deviation from one driven clock wave to a successive clock wave or even between one driven many clock periods apart. It's just inconstent deviation, that's why its a huge problem. It may never deviate to the point it begins to destabilize things except once every 20 minutes or 2 hours. It may deviate farther than normal occasionally and this phenomenon if the system is idle probably won't be noticed, but if its under heavy load it may show up as a glitch, a pause, a brief hang, a random BSOD, or worst usually is a full hard system lock.
Now what the NB and CPU Clock Skew settings in bios are, is a means to manually compensate through "trial and error" for the most part since none of us own high priced Logic Analyzers to calculate these values with maths! by farther delaying when a clock is driven at the NB or CPU or even DRAM (we advance dram clocks sometimes depending on memory sticks to compensate for very short MCH read delay turnarounds and to obtain data validity), we can take into account the deviations from clock jitter and more importantly timing resolution (which is probably 50ps or so on the MCH, its too coarse for extremely high fsb but we can compensate with a combination of GTL References, Vtt, Vnb, Vcc, Clock Skews and other things) by eye and feel and response. It's no science it's a black art.
It takes time to get used to your particular hardware, and pay attention to the small details...how long it takes to POST, miniscule delays between BIOS POST codes on the LCD Poster, changes in OS response, even setup options being sluggish to select. There are so many things you can pick up on that believe it or not happen because of clock jitter and deviations. There will be FSB frequencies where you can have the bios and system tuned to respond amazingly fast, and others where no matter how hard you try the system is hit and miss. When this happens just go up or down a few mhz on FSB and try again, you might find a frequency that works better for your settings. Like I said up or down doesn't matter, BCLK drives FSB and its too high of a reference clock frequency so even going +-1mhz sometimes can completely destabilize settings you worked on for days to get right. Keep that in mind.
