Sleep for Servers

Sleep for Servers

zogger

Wed, 07 May 2008 21:23:00 PDT

Computers

Networking researchers are saying that little slowdowns to servers and routers can improve efficiency and electric consumption to a large degree. Allowing the devices to pass traffic in small bursts or pass it off to servers already under near full load could allow big savings.
..""In an extreme case, a single connection can keep a server on," says study leader Jie Liu. "Studies have shown that a server can consume 60% of its peak power even when it is idle," he adds."

ed.z.: learn new stuff everyday, I had just assumed they were already doing things along these lines. Hmm, maybe they should take a clue from that megacomputer project and design servers with a lot more processors of much smaller size that could be used or not used depending on true demand? Maybe we just don't really need all those high powered CPUs running things all the time. And if you had hundreds of little processors running instead of like a dozen big ones, it wouldn't matter if a few went bad on you now and then, massive redundancy. Bad car analogy time, what we used to do with huge displacement v8s running twin four barrels can now be done using a much smaller 4 or 6 using multivalves with variable timing and intelligent fuel injection and super and turbo charging and etc. Same big horsepower, but much less fuel consumption. Work smarter, not harder, is the old saying.

Sleepy Linux

phred14

Thu, 08 May 2008 06:14:27 PDT

Late last year there was some activity on LKML about "Sleepy Linux", as an offshoot of the tickless kernel work. The idea was that once you've crossed the bridge of making the kernel tickless, it's really idle when there's nothing to do, as opposed to keeping itself busy servicing the timer ticks. If it's really idle, you can think more aggressively about moving it into lower power states. The subject seems to have been dropped, so I have no idea where it went.

I generally try to do all of these power-saving things on my machines. My servers run gentoo-hardened, so their kernel level is a few behind the regular kernel. But on every machine where the options are available and working, I'm running tickless kernels and "ondemand" CPU frequency modulation. (I tried it on my nForce2 machine, but it was flaky there, and I haven't had time to do any tuning, but that machine's usually off, anyway.)

I would like to do more to get my power down, across the board.

Sleepy Linux

Harry the Bastard

Thu, 08 May 2008 18:15:19 PDT

I would have expected that if the machine was only servicing timer ticks, that the rest would have been simple ... two successive timer ticks without being pre-empted by other tasks in between should make it easy to reduce the uP clock, and perhaps even the uP's voltage.

Cannot see why virtualisation is being picked on though ... often virtualisation is used to combine several services on one box ... a saving of several hundred watts is then on the cards. (assuming the other boxes dont get used for some other task)

Cant see where LISP comes in either ... Software writers can write bad code in any language. I am afraid that people seem to have lost sight of the KISS principle (Keep It Simple, Stupid).

I have watched a few teams of software writers bloat code. Examination often reveals the same task could have been computed in vastly less lines of source. Problem is the writers (often) dont really understand what they are supposed to achieve. (or the writers are either stupid, lazy, or both!)

Then comes some of the stupid coding rules that upper management require. IE: No functions to be any more than 25 lines is just one I have seen used that cause useless (or even harmful) bloat. So, to get around company coding rules the programmers end up having several functions which are called in a loop ... adding all that stack overhead, and uselessly slowing down the code. (Ah, but, say the halfwit managers, THIS code is maintainable. (Pity its way too slow!) (And, IMHO, the "maintainable" code is often more obscure than the direct form would have been.

Sleepy Linux

phred14

Fri, 09 May 2008 05:58:55 PDT

About Technocrat.net

I would have expected that if the machine was only servicing timer ticks, that the rest would have been simple ... two successive timer ticks without being pre-empted by other tasks in between should make it easy to reduce the uP clock, and perhaps even the uP's voltage.

The problem is with the hardware and BIOS support in the machine. Sure, it's easy to figure out what you'd like to do, and in fact my laptop is capable of doing everything you say, maybe more.
```
           PowerTOP version 1.9       (C) 2007 Intel Corporation
          
```
```
          Cn                Avg residency       P-states (frequencies)
          
```
```
          C0 (cpu running)        ( 4.3%)         1200 Mhz     0.0%
          
```
```
          C1                0.0ms ( 0.0%)         1000 Mhz     0.0%
          
```
```
          C2               52.9ms (34.4%)          800 Mhz     0.0%
          
```
```
          C3               10.0ms (61.4%)          600 Mhz   100.0%
          
```
Unfortunately even though it's docked, they keyboard/mouse subsystem seems to be generating about 70 wakups/second, limiting my time in C3. But notice that it is "working hard" at saving power.

Cannot see why virtualisation is being picked on though...

I agree with you on this one. Server consolidation through virtualization is a big win, especially if the new server is power conscious.

Can't see where LISP comes in either...

As an example of impractical stupidity, of which there appears to be no shortage in the industry. You furnished a few more examples.

re "ed.z"

Thomas Lord

Wed, 07 May 2008 23:13:36 PDT

learn new stuff everyday, I had just assumed they were already doing things along these lines.

Oh my goodness. You are so out of touch. Geezum, you should be a CTO of a fortune 500 intersected with the top software tech leaders. You've got the ... um .. qualifications. :-) "Maybe" we don't need? Dude, we crossed that line about a decade ago. And even back then there was room for magnitudes of improvement.

The software and hardware stacks we use today are pig manure with a tiny fraction of diamonds embedded. The money is going into organizing the manure. None to extracting the diamonds ("systems programming is irrelevant").

I don't think I can convey the whole picture in a single comment. Honestly I've been thinking for weeks about where to start explaining it, perhaps in some fancy Technocrat articles about software and hardware tricks and I keep getting stuck because I don't see how to start it other than with a refresher course on Shannon and communication theory -- already way too long for the format.

Executive summary: f- "virtualization" as it stands today. F- the power management features in kernel-du-jour. No, no, those are tiny fractions of what is needed and what is in reach.

What we really need? HA HA HA! Freakin' lisp machines. We need very high-level languages for apps (not just for power, also for correctness, improvisational capacity, maintainability, etc). We need language based protection and memory management as a substitute for all those gates doing virtual memory. And, ok, not classical lisp machines exactly but FPGA beasts that dynamically adapt to load in ways transparent to high level code.

"Everything you know is wrong." from hardware up to apps. The wastage is ridiculous. The fragility is ridiculous. And yet prominant computer science researchers^tm just keep selling the capitalists on doubling down on piggish crap.

Analogies... analogies... where did I put my analogy.... let's see.... hmmm:

This is probably too abstract but here's one:

Suppose the goal was to create a technology that could be used to play a perfect game of tic-tac-toe. Got the engineering goal? Ok, so, Guy Fawkes provides the perfect answer which has the form of a single sheet of paper. The industry, on the other hand, is busy cranking out relay-switch tic-tac-toe machines. In fact, a growth market comes in the form of manufacturing the wire to be wound around coils for these relay switches for if the diameter of the wires can be reduced by 15% then there will be 20% savings in power consumption.

-t

re "ed.z"

Petr Mareš

Thu, 08 May 2008 13:43:30 PDT

Alcohol and wittiness don't mix too much...

re "ed.z"

Thomas Lord

Thu, 08 May 2008 14:07:01 PDT

That is certainly false. Drunkenness and wit are poor companions, to be sure, but mere alcohol and wit are, for all of recorded history, more or less the best of chums.

More to the point, what is your point?

My point was not to be simply "witty" but to draw a line in the sand. I claim that today's stacks are bass-ackwards. I claim that today's approach to virtualization and power management return only thin margins while a revisiting of older ideas rooted in high-level-language thinking can produce serious returns. I claim that the economic justifications for today's dominant hardware architectures are nonsense -- irrational investment.

And, I mention that this thread is not where I expect to support or prove these claims. I mention that, in fact, it's freakin' hard to condense their support into simple, small bites.

So my claims are a bookmark. They introduce a new theme -- something to be referred to, elaborated upon, and supported in future contributions. It is the blogging equivalent of an abstract. The beginning (or at least jacket blurb) of a new "book".

-t

Sleep for Servers

Richard Sexton

Thu, 08 May 2008 08:59:41 PDT

I've noticed this too. I went off-grid last months and I have a 1Kw/(2Kw surge) inverter on my desk with a pair of Exide E3600 barrieries built into my desk run by solar and wind. They run a powerbook and a Hughes sat. I notice that if I also plug in a 9W CFL bulb (which draws 23 watts btw as measured) the inverter fan comes on as it's chugginng out more power now, knows it and trieds to compensate for any extra heat from the increased load. So screw the light, I went LED. Normally that fan never comes on, ever. But If I'm doing a lot of things, especially transmitting, the fan comes on when it's real busy. So yeah, busy conmputers draw a lot more power than their quiescent state. But that's kinda obvious, jah?

Sleep for Servers

Thomas Lord

Thu, 08 May 2008 14:15:54 PDT

So, an obvious question is then "What makes this computer 'busy'?"

Huge swaths of it (orders of magnitude) are computations that you don't need, but that saved the developers a couple of bucks. They saved a couple of bucks but then their many, many users pay that back again, and again, and again.

-t

Tags: efficiency, servers, "sleep function"