The whine I mentioned in the previous post is, by the way, not exclusively an Apple thing.
Actually, if my experience was representative, I’d say about 40% of all Intel laptops suffer from overloaded, “singing” capacitors, as this is inherent to how the Intel CPU power management is designed1. And, bear in mind, these are not only generic brands like Compal, but also Dells and the highly-respected IBM ThinkPads2.
How come the manufacturers don’t acknowledge and fix those flaws? A good question. Note how all those reports are Linux-specific? Is there something wrong with Linux (and, for the record, OS X) that makes the laptops whine? How is it that the Macbook whine can’t be heard when running Windows?
To explain this properly I need to introduce the concept of timer tick. Even modern preemptive multitasking operating systems don’t actually execute several tasks concurrently (unless they run on a multi-processor or a multi-core machine). Usually, they divide the processor time into small chunks, usually ranging from 1 to 10 ms. Every chunk is then assigned to a specific process or thread by a part of the operating system kernel called scheduler. On multi-processor systems this process is spread across all the processors (or cores), as there’s usually more tasks waiting to run than available CPUs. Since the chunks are so short, the user is therefore given a very convincing illusion of multitasking rather than “true” multitasking, whatever it is.
In technical terms, the system’s real-time clock (RTC) is programmed to trigger a timer interrupt (timer tick) every 1 or 10 ms. When this happens, the currently running task is preempted (hence preemptive multitasking), and the timer interrupt handler calls the scheduler, which then decides whether to continue running the current task or to run another, and if so, which one.
At this point, if the scheduler determines that there are no tasks that need to run at the moment (i.e. the system is idle), it may decide to put the processor into a low-power state (a Cx state, specifically). The CPU will then sleep until the next timer interrupt occurs, wakes it up to C0 and the scheduler decides on what to do next.
This design has the following consequences:
- The CPU can sleep for no longer than the period between two timer ticks.
- When the system is idle, the CPU is switched back and forth from Cx (x > 0) to C0 at timer frequency.
The timer frequency is often expressed in hertz (ticks per second). Traditionally, the most popular value was 100 Hz. Timers of at least Windows 95 to Me and Linux 2.4 run at 100 Hz. Early versions of Linux 2.6 used 1000 Hz by default, but more recently the frequency has been made a compile-time configuration option with choices of 100, 250 and 1000 Hz, though the majority of kernels still by default run at 1000 Hz. Newer versions of Windows use a different approach — the timer frequency is 100 Hz nominally, but the system uses per-application “multimedia timers” of 250 Hz or more on demand. Note that this demand implies multimedia load that generally prevents the CPU from sleeping anyway.
To recap what was written so far, an idle Linux 2.6 machine uses a 1000 Hz timer tick, hence the CPU is put to sleep and wakes up a thousand times per second, its core voltage fluctuating accordingly. An idle Windows machine, on the other hand, ticks at 100 Hz, and the CPU core voltage is only changed a hundred times per second. Why is it then that at 1000 Hz the capacitors whine, and at 100 Hz they do not?
The last piece of the puzzle is human specific. Behold: the absolute threshold of hearing. It turns out that human ear does not respond to all tone frequencies equally. Some frequencies (roughly in the range of 1000–6000 Hz) are generally perceived better than others. Moreover, according to this graph, the sound at 100 Hz needs to be more than 30 dB (or more than 1000 times, since the scale is logarithmic) louder than the one at 1000 Hz to be heard at all!
Indeed, the capacitors do whine at 100 Hz, but the sound is simply to faint to be heard by human ear. Thus, an average Windows user has no real chance of ever hearing the whine, and most manufacturers are completely unaware of the problem.
Conversely, Linux users are usually well aware of the whine, but for them the solution is easy: simply reduce the timer frequency to 250 or even 100 Hz (this has the benefit of reduced power consumption, by the way).
OS X users are stuck with the default frequency3, which given the evidence should be around 1000 Hz. Should be, because the sysctl output shows otherwise:
$ sysctl kern.clockrate
kern.clockrate: hz = 100, tick = 10000, profhz = 100, stathz = 100
I’m not really sure how this relates to the frequency of the whine. A frequency of 100 Hz should not be heard and all the other operating systems behave properly. Perhaps OS X diverges from other OSes in this area? If you happen to have a solution for this apparent paradox, please let me know.
If you have some spare time and wish to dig deeper, I recommend the following links:
- I’ve never seen an AMD-equipped laptop that would make use of C3, so I can’t tell if they are also affected. [back]
- See here and here for some reports, or just google it. [back]
- Though there might be subtle hints OS X scales the frequency down as the whine seems to fade out after a period of inactivity. [back]