> From: David Woolley <[EMAIL PROTECTED]> > Date: Mon, 19 May 2008 08:32:37 +0100 > Sender: [EMAIL PROTECTED] > > > Evandro Menezes wrote: > > > > > And, please, don't consider the power used by NTP itself, but rather > > the power used by the CPU idling in a higher power state than before > > NTP woke it up. Modern processors can draw 100W without doing > > anything useful, but it falls down to less than 10W it it's allowed > > run the HALT instruction instead when there's nothing to do. > > HLT instructions are a complete red herring here. They've been available > for over 35 years, to my personal knowledge, and probably a lot more > than that. No mainstream Linux, and probably no Linux has not used > them. The recovery time to a HLT state from an interrupt service > routine should be 10s of nanoseconds[A], although high level language > ISRs may compromise this, and from user level, should be of the order of > half the context switch time, which ought to be well under one > microsecond. These are the normal exit times, and may actually be > shorter than to busy idle. > > HLT is special in power management terms in that it doesn't require > heuristics on anything better than MSDOS, for any application that is at > all multi-tasking friendly. > > > > > The picture that Red Hat refers to is that the CPU is removed from a > > deep C-state in order to run NTP for microseconds and then it remains > > in the running state for a few fractions of a second until it goes > > back to a deep C-state. So it's not a matter of NTP's duty cycle, but > > But you've already told us that you get a 90% power saving before you go > to the deep state. In my view, a server that is running at a > sufficiently low CPU load that going deeper that HLT is useful is badly > over-dimensioned. > > If high load depends on time of day, you will have to dimension air > conditioning for peak loading (which means times when you will never go > deeper than HLT), which will determine capital costs, and probably some > of the running costs. If you are getting significant energy bills, you > are likely to be on a peak usage tariff, and from an environmental point > of view, is it much better, once you've created the manufacturing costs > for the server, to get maximum economic value from it by marketing low > priority work for it. This also applies to the electricity generation > and transmission infrastructure, which needs to be dimensioned for > maximum load, and needs to contain components, which tend not to be > environmentally friendly, to server short terms peaks (not everyone can > pump water uphill in low demand times, and even that has capital and > efficiency costs. > > Tactics for smoothing the load and achieving high productive utilisation > where common when capital cost was the main issue. > > > the duty cycle resulting from the heuristics used by the hardware or > > the OS to decide when to place the CPU in a deep C-state. > > > [A] I suspect it is actually single figure nano-seconds on modern machines.
I've been following this thread for a while and it is clear that many (most?) people are not aware of modern power management at the hardware level in modern systems. It has changes a LOT since the days of the simple HLT instruction. Most of this was originally developed for mobile systems, but now it has migrated to servers where power savings are increasingly important. In olden days, when the CPU had nothing to do, it was halted. This reduced the power required to around 10% (depending on details of the particular CPU design). This has been the case for years and continues to be the case. This is not the time or place for an ACPI tutorial, but ACPI allows for much finer grained power management that not only reduces the power required by the CPU, but by much of the system through the use of "power states". Now days, if the OS supports it, when a system is "halted" it does not simply "halt" the CPU. It initiates a series of power saving steps according to the rules set up by the OS. These are normally referred to as sleep states and has nothing to do with "suspend" operations such as "suspend to RAM" or "suspend to disk". On most newer systems, if the OS enables it, if the system remains halted for over one CPU clock cycle, it drops from C1 state "halted" into C2 "deeper sleep" and this further reduces power use. It just takes a bit longer to get going again. If the system remains "halted" for a longer time, it drops into C3 state which further reduces power use. On my laptop, this takes 85 clock cycles to recover and start processing instructions again. Some systems now support even more sleep states, some taking hundreds of clock cycles to fully wake up. My laptop running FreeBSD typically spends over 80% of the time in C3 or C4 and the power savings when these states are enabled is substantial. To enhance the effects of this capability, many OSes, notably Linux, have started making significant modifications to the kernel and especially the scheduler to allow the system to maximize the time spent in C3 and below by trying to schedule as many tasks as possible at the same time. The power savings can, again, be very significant and server owners are pushing to make this work as well as possible since power (both electrical and cooling) have become the primary expense in collocation facilities. Unfortunately, it looks like this will require some re-thinking of how ntp operates as keeping a server running at higher power levels to keep ntp happy will hit the owners of these systems right in the pocket books. I am not a ACPI guru by any means and I don't fully understand all of the details. I certainly don't understand all of the inner workings of ntp. I just hope this helps clarify what people are talking about. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
pgpc7gVIQJluo.pgp
Description: PGP signature
_______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
