How Does A Cpu Attain Its Frequency?, Electrical Engineering associated

Hi

I have a friend who during his experiments has encountered an oddity with one microprocessor in reaching very high speeds not possible. This is not a bug with any software reading, all prove the same thing and benchmarks are showing the MHz values to actually be correct much to our shock, as the scores are very high too. These programs are enthusiast and professional applications used by the likes of Intel and AMD to analyze and compare results.

Can anyone explain how a typical processor of nowadays, say the 130nm node Athlon XP derived their clock frequencies, in sufficient detail?

I need to be able to understand the concepts to explain the happening and to be able to help others spot problems in the IT and overclocking community. I also need to be able to explain what is happening here and how. It's for all of us, really.

• Most importantly, are there any low level divide instructions executed to prevent incorrect clock frequency readings?
• Are there any tests to accurately determine the absolute external and internal clock frequencies of a core?
• How does the TSC work and how accurate is it?
• What part do motherboard PLL timers play in affecting the clock frequency, and how accurate is this method?
• What is the logical step-by-step query process to arriving at a clock frequency of a processor? (is the information contained in the in-core registers? If so, how was that determined)
• What does the kernel level (in Windows) have to do with the CPU clock frequency?

That's all thanks. Look forward to some educated input.

Does no one here understand Time Stamp Counters, PLL timers, feedback loops, register buffers and microprocessor buses?

We certainly understand feedback loops.

As for the rest of your questions: Nope. Nor does anyone here understand FPGAs, x86 or, (God help me for admitting my age), 65xx assembly code, nor do we have a front porch. Especially for you to spit on.

Go to Intel or AMD or, maybe one of the folks that make REAL processors, like IBM or Hitachi, or TMC, (if they're around anymore).

This post has been edited by Sapo on Oct 23 2007, 03:03 AM

Why not just start with a google of "Athlon XP clock frequencies"?

Hi Sapo and NoCleverName

I know all the basics available in technical White Papers on microprocessor functioning but what I need is intrinsic electrical engineering knowledge which only someone whose worked with microprocessor development will really be aware of. These details are normally undisclosed but some of the senior programmers will understand the basics (most of which I already know and are not much help). Such as how to make an application query a set of small low level divide instructions with known return times to calculate core frequency (which is what many applications which do measure clock frequencies will do) as a proof check that the RDTSC timer is functioning correctly, and how to further read the core EAX registers containing the latest clock frequency values.

But what I need is how and by what method do the core registers derive those frequency values, in precise explanation so to work out where the inaccuracy could creep in.

Good question. In a scientific sense this question is answered by the uncertainty principle, whereby, the energy of the electrons at the given frequency have a certain quantum probability and location. Where the copper lines act as a quantum-well we can calculate how many electrons will jump across to the other copper lines based on the frequency, and ultimately, the wave equation of the electrons.

In a practical sense, they run millions of tests in order to determine the actual clock speed, whereby for all practical purposes, they essentially eliminate the chance of electron waves acting across forbidden boundaries. In many situations, you can of course clock the CPU at far greater speeds, and rarely induce an error.

If we had a complete and absolute understanding of electromagnetic forces we could calculate the exact solutions. At this point in time, although our theoretical approximations give us a very good idea, practical testing is the only guaranteed method, and the engineers generally error on the side of caution in regards to the clock speed.

No matter the operations performed, they will simply keep testing for the correct output, given the operating conditions and many billions of trials. The moral of the story I guess, the more you overclock a CPU, the more likely it is to produce an output error. On the other hand, a little overclocking will rarely demonstrate any difficulties.

(Walks up to a PNP junction and jumps down a man hole in order to avoid the collision)

Hi templeghost

How can you calculate the rate of electron movement across a boundary without determining a clock frequency the core is executing at first? How would you determine the clock frequency needed is a tangent to my main question.

This is my main query, because this is what I need to do. The tests are usually 5-10 standardized test suites which include stability testing, but which ones are they and how do those tests gather the correct frequency?

All processors are overclocked at the factory by the way, most of the last Intel lineup since July 2006 were and then released as separate SKU's.

There are likely people around here who could offer much more input on this than I can. I can only speak to it from a CPU design, and quantum-mechanical perspective, or from a system design perspective to some degree.

Being that we are not producing the CPU's, but trying to understand how much we can overclock them in real world situations, I guess we would have to consider the frontside bus more than anything.

Where the CPU is running at some mutliple of the bus, if we increase the bus speed we greatly improve performance, as is often done with video cards. However, the increased bus speed can be very problematic for other devices, IDE hard drives being a good example.

If we presume the CPU was engineered with some room to spare, perhaps the greatest concern is with the extra heat caused by overclocking, and so extra cooling becomes of paramount importance. As far as what software is used to test the CPU and overall system performance, and the related clock speed, I really have no idea. Although simple binary based memory and hard drive writes and reads would seem ideal.

In this modern world, I think I am the bus, and I can't keep up with all the data which is buzzing through the core.

Hi templeghost

I've overclocked since 1999, since 2001 with cascade, dry ice and ln2 and my uncle was a microprocessor engineering in the 90s, so I'm aware of most of the available information. The thing I'm unaware of, is what none of the processor corporations are answering to and my uncle won't comment on either. Just how the system works out core frequencies and what the most accurate way to do this is.

Thanks for your input.

I didn't read the entire thread but there are different measures of clock frequency for a processor. There are equivalent measurements of computational power that are computed on benchmark programs and the times for which these programs take to execute are compared against some standard and then scaled, so, for example if a Pentium 1GHz runs some set of benchmark programs in 10 seconds and an Athlon 1GHz runs the same set in 9 seconds, then the Athlon might be considered equivalent in computational speed (for that application at least) to a ~1.1GHz Pentium.

You also generally have an external oscillator to the process that sets a reference speed for clocked operations inside the processor, though generally nowdays, an internal clock multiplier is used to increase the internal frequency of computations and its the internal frequency that's generally specified as the clock frequency in this case (though in the past this internal multiplication wasn't performed and the external and internal clocks were the same speed).

It even gets a bit more complex now, when you consider that various buses and memory elements on modern processors often don't run at the same clock speeds eitherm so you might have 3 different clock speeds, of which one or more of these might be internally multiplied to some other frequency etc.

In the case of AMD, they've been speccing clock speeds relative to benchmark programs running on IBM x86 processor, so they're not giving that actual internal clock speed of the processor, but instead are just specifying approximate computational speeds versus some reference x86 processor where the actual internal speed is specified, and benchmark programs typically give you results in this form as a relative computational speed, and not a physical clock frequency.

With regard to how the physical frequencies are generated, most are generated via. a physical resonance, such as a quartz crystal or ceramic oscillator, though you could have an oscillator determined by various electrical time constants instead, but these typically vary with temperature and are generally avoided in preference for a physical resonance that varies less.

Also, some benchmark programs might read BIOS information and attempt to determine internal processor multiplier settings in order to compute what the equivalent internal clock speed for a processor would be, but this would appear not to be generally applicable for all PCs as both this BIOS information and the manner in which internal clock multipliers are configured could differ from one PC to another, so I wouldn't rely on a benchmark program to give accurate results for internal processor clock speeds for anything other than a motherboard it was specifically designed to perform the computation for.

This post has been edited by StevenA on Oct 25 2007, 08:11 AM

http://www.intel.com/cd/ids/developer/asmo...9859.htm?page=1

Hi StevenA and meBigGuy

This is what I'm touching on.
The processor frequencies are set by a piezoelectric quartz crystal oscillator called Phase Locked Loop timer (PLL timer) which generates a regularly timed series of mechanical vibrations between two slightly different shapes that are used to mark time, thus processor clock signals (frequencies). Every typical electronic consumer device uses them. They are found on both the motherboard and built into the CPU, and both need to be in synchronization to receive a feedback value and normal operation. The CPU PLL is used for the motherboard PLL as reference and the CPU stores the values of the PLL timer in registers, such as the EAX register.

When we overclock, or the processor factory overclocks (increases speeds), it is those PLL timers and internal multipliers that are manipulated; they set the total clock speed.

The processor also has a base timer called Read Time Stamp Counter which records the actual processor ticks per clock. It can only be accessed in assembly language and it shows you what the actual value of the processor is in real-time.

Then you have Windows API QueryPerformanceCounter and other functions which try to find the bootup clockspeed and do not "monitor" the real-time clock speed. Some applications especially those which utilize the Etimer function will make use of this, but they do not monitor throttling of CPU frequencies in real-time.

The BIOS provides real-time clock speeds from the CPU and MB PLLs.

Applications just read them. How they read them is what meBigGuy linked to, by using Etimer function, C functions, timeGetTime function and so on. But EACH of these methods depends on many internal factors which are subject to error. Surely this is not the best and most accurate method to find out the real clock frequency of a processor?

How accurate is the PLL timer? What happens if it is in error and how does one test it?

Cheers.

This post has been edited by Guest_macaronee on Oct 26 2007, 07:54 AM

Electronically, the internal clock frequency is really only typically determined by 2 components - an external crystal oscillator frequency and a PLL multiplier to this. A PLL itself doesn't generate any specific frequency but instead allows ratios of frequencies to be constructed (though there might actually be more than one PLL stage and so you might actually have more than one frequency multiplier involved).

So, for example, if we have an external 100 MHz crystal oscillator and an internal PLL in the processor is multiplying this frequency by 20, then the true electrical clock signal internally would be 2000Mhz or 2GHz.

I don't know how standardized motherboards are regarding the external clock frequency, nor am I familiar with how consistantly BIOS features configuring a PLL multiplier are implemented for various motherboards, but the external oscillator is usually not too difficult to determine by manual inspection of a motherboard, but the configuration of internal PLL(s) in the processor would seem to be something very dependent upon the specific motherboard and processor combination you're working with.

I believe in the original XTs there was a signal derived from the AC power that would give the processor a 60Hz reference signal to determine "realtime" values, and I believe this has been retained for compatible in PCs over time.

The problem with measuring real quantities of time, in software, is that there's no direct way a processor can determine its rate relative to an external time without some way to compare things - so if you tried to write a program to measure how fast you're computing something, there's really no way to do this solely via. software because a program just takes X number of instructions or clock cycles to execute, and if you slowed them to 1/10th the speed, you'd get the exact same result, but it would just take 10 times as long to compute.

So the hardware needs to provide an external clock, timer or date function etc. and in the past this was derived directly from the ~60Hz ac power signal, but BIOS clock/timer functions, I'd assume, have been used as substitutes for this because an ac signal from the wall wouldn't necessarily be a very reliable source.

In any event though, benchmarks to measure internal clock speed would rely upon external hardware timing, which I'm certain is standardized for all hardware, but likely not for PLL settings and crystal oscillators, so the next most reliable way of determining an equivalent internal clock speed would be to execute some benchmark computation on a specific processor and then compare this timing versus the standard 60Hz signal and then if internal clock rates are altered, the relative ratio of times could be compared and the equivalent internal clock rate could be closely determined, but this relies upon using a specific computational architecture. If you have something like a multiprocessor or new architecture that optimizes the execution, you won't really be getting an estimate of the internal clock rate, but instead an estimate of the relative computational power of the different architecture, so it would seem rather difficult to write a program to estimate that actual frequency of the internal clock speed of a processor unless you're working something standardized in that regard and generally the processing speed is the one thing that PCs aren't standardized on (as most everyone's trying to make them faster).

Again, I admit that I'm not familiar with what standardized BIOS reporting features might be available in this regard though, so there may already exist standards for reporting PLL settings that I'm not familiar with, but this of course would need to be something implemented in a compatible way between multiple processors, though the "Read Time Stamp Counter" function you mentioned sounds like it may provide that information, in which case you'd want to use the 60Hz interrupt timing and compare how many such counts occur for each 60Hz interrupt.

So, for example, if you have a known processor that increments its "Time Stamp Counter" by ~20 million counts per real time 60Hz interrupt and you already know that the internal clock speed for this is set to X GHz, then you can write a program that computes X GHz=SCALING_VALUE*(Counts_This_60Hz_Cycle-Counts_Last_60Hz_Cycle) and then you can constantly poll/interrogate the counter function every 60Hz cycle and report this value as the internal clock speed. If the internal clock rate is increased by 30% (either due to a change in the external clock or PLL multiplier setting) then your counter should increase 30% faster per external 60Hz cycle (which should be provided by a standard BIOS function on all PCs). In the above example, the scaling value would be 1.1/20,000,000 for speeds in terms of GHz (that's just an example), so if you measured the Time Stamp Counter between two 60Hz interrupts as being 17,200,000 and 37,200,000, you'd be computing 37,200,000-17,200,000=20,000,000, then 20,000,000*1.1/20,000,000=1.1 GHz, and if the internal clock rate was being altered dynamically, you'd be able to track this at a 60Hz rate.

BTW, the crystal oscillator and PLLs should be very stable. If you're seeing large disagreements reported by software from expected internal clock frequencies, I'd assume it arises from a difference in how the BIOS/motherboard sets and reports crystal oscillator and PLL settings (oh, and yes, you're right that some external oscillators include both a crystal oscillator and a PLL multiplier and so function as a variable frequency oscillator for purposes of overclocking ... I wasn't thinking of a motherboard specifically designed for overclocking and some of the dedicated ICs they have for this - yes, if you can read an internal clock cycle counter in the processor and compare it against the 60Hz external hardware reference, that would appear the best way of nulling out all these possible influences and would only rely on the presence of those two features).

This post has been edited by StevenA on Oct 26 2007, 09:06 AM

Hi

I'm not quite sure what your driving at?, then again I haven't read through all of the posts. The PLL circuit, that you talk about, can very accurately generate stable frequencies depending what it's feedback counters are pre-loaded with. Alternatively, if the PLL circuit is of the dual modulus swallow type, then it maybe able to increment or decrement it's frequency at steps approaching 1kHz steps, bearing in mind that the PLL circuit output might be running at 2GHz. The general idea of any processor is run it at as high a frequency as possible, but within spec. If you overclock the CPU, like go beyond spec., then two things might happen:
1) it will get physically hot due to the switching gradients becoming flattening out
2) the CPU might crash and therefore issue a repeated reset signal

Also bear in mind that any PLL is under tight negative feedback control.
Also, some MCU,MPU's depending on manufacture, divide the raw clock down, whilst others don't. To find out the real clock frequency of a particular processor there are a number of factors you should consider, such as 'how many clocks does it take to accomplish or execute a mid range cpu instruction'?, raw clocks are usually sub divided into machine cycles, and then it may take 2 or 3 machine cycles to execute one instruction.

I don't think PC motherboards are supposed to fixed/repaired, if you suspect a hardware problem on your motherboard then simply throw it away and get new.

Cheers
Darren

This post has been edited by Darren on Oct 26 2007, 06:31 PM

Hi StevenA and Darren

That's true, I never quite thought about it that way.

One thing; the 60Hz AC signal you reference won't be used globally if at all anymore because the present motherboards can only accept DC voltage from SMPS and the frequency used in many countries of the world is 75Hz. There's no mechanism in a modern typical PSU to generate a 75Hz AC signal to a 60Hz DC AFAIK.

Yep, when we overclock the CPU we're experiencing wild fluctuations in CPU frequency based on processor load (like throttling). Oddly enough, benchmarks used and approved by everyone for professional competition are returning high values in accordance with what you would expect if the actual processor frequency was that high (scaling) and taking in to account fully the processor architecture (i.e., it is weak in Int ops compared to a Pentium 4 3GHz, so it remains consistently weaker no matter what frequency it is benchmarked at).

Every software reports these high frequency values.

That's why I'm asking all this to know what is really happening, where is the error, why are all monitor/benchmark software reporting this, and what are the actual physical fact of happenings.

The ones in our motherboard cannot increment or decrement is step values because they run at a base timer of 3.6MHz which you can checkup using an application, and they are used then to compare to synchronize other PLLs within the CPU to arrive at a stable processor frequency value to feedback to the Operating System, BIOS and the application which queries them.

If two PLLs return differing values, the system is said to shut down as the CPU cannot determine the CPU real-frequency or voltage, nor can the motherboard.

However, our CPU returns very high values of both frequency and voltages when we overclock, and it overheats immensely but does not shut down (if we cool it more). It has damaged hardware components to failure though, many, two of our new SMPS has blown up twice while experimenting within 60 minutes. We cannot work out why.

One problem I've noticed is; everything which uses a timer (i.e., programs which execute and measure a section of code) cannot run without a computation error, and the system has huge kernel level load coming (80-100%) from we have no idea where.

Yep, we did that and the program we used which runs exactly that to base its frequency value gave very high CPU frequency results... which literally shocked us.

Is there any way I can check if our motherboard/CPU PLL timer is functioning OK (some sort of device measurement)? Because any other expert I've talked to yet said "your PLL is faulty, that's why". But when asked to explain, they could not explain it since there were too many contradictions in what they think and what is happening. If we measure the PLL timer and its ticking perfectly fine when overclocked, then all we can conclude is that the processor is indeed running at higher frequencies as the software is telling us (unless there is something else we are missing and no one s telling).

Which will be a new chapter in microprocessor design and functioning for sure, if ever.

Thanks again.

This post has been edited by Guest_macaronee on Oct 27 2007, 04:19 AM