memories

For some reason, all copies of an early variant of RTLinux called “myrtlinux” by its Italian “author” have disappeared from the web, but thanks to some archives we can find some fragments from old days.  For example, within a year or two of this email, the story had changed rather  dramatically. To me, there were important lessons about the memories of academics who could get grants by not remembering and the principles of  “free software” advocates who could get  paid by being indignant in the right direction. (sorry if this is too cryptic, but I want to get some of this material back on line for a variety of reasons).

From:       mante () aero ! polimi ! it (Paolo Mantegazza)
Date:       1998-03-16 15:52:14
[Download message RAW]

Hello, fresh news on using the FPU within RTLinux.
I've been able to convince a collegue, performing active vibration control
of plates to decrease the transmitted noise, to use RTLinux with the FPU
support of my variant. (I was smart in having the other take the risk,
wasn't I?). Please note that is the same technique I posted some time ago
for an rt_prio_sched of the standard release.
They are sampling the response of three piezosensors, carry out some signal
conditioning and simple compensation and evaluate a direct proportional
feedback to actuate three piezoactuators. They use a 200 Mhz plain Pentium
and  conditioning and feedback are performed by using the FPU without any
problem, with X running and with the system lively, at 18 Khz. The signal
are checked on a scope.
For those interested the piezo sensors and actuators are three ceramic disks
bonded to the panel. The DA acquisition are carried out with a DAS1600 card
along with two DA conversions, the third DA output with some other card
whose brand I forgot.
This is a preliminary activity in view of the implementation of a neural
controller. The only way they found to crash the system was to unplug the
computer by stepping onto a flying socket.
After these simple tests their doubts on using RTLinux are fading away and
I am happy that they can trust me somewhat more now.
I have not checked the system personally yet, but this is just a
confirmation of my testings.
Having understood that "fixed FPU support" meant "sound and working" I'm
eagerly waiting for the new 2.2.xx related RTLinux release with a native
improved FPU support.
Ciao, Paolo.

Virtualization and power use and spreadsheet games (updated)

Here’s a thought experiment. Suppose each server uses X watts idle and X+Y watts busy. If you have N programs that
currently run on N servers that are Z% idle then in the best case you really only need D= (100-Z)/100*N servers. So in a perfect world you have D machines busy all the time for D*(X+Y) power use instead of N*(Z/100)*X + N*(100-Z)/100 *(X+Y).


Something like this

N servers= 200
Z idle rate= 70
D need= 60
X idle watts= 150
X+Y busy watts= 800
Power use= 69000
Consolidated Power use= 48000 Savings= 21000

Ok that rocks, 21KW/hour. But can you really get that savings?  If program 1 and program 2 need to run at the same times: you can’t save anything on them[1] and then the virtualization itself adds cycles for purely overhead and increases memory which burns more power. Suppose we now add K% as the overhead measure – real need R= D+D*K/100. If  K=20, we cut savings in half. But 20 seems wildly overoptimistic to me, so put it at 50.  We’re still only needing 72 servers instead of 200, but they are running flat out so we actually increase power use.

K overhead= 50
R need with overhead= 90
Consolidated Power use with overhead= 72000 Savings= -3000

That does not rock.   But here’s the kicker – if we reduce idle power to 25Watts, maybe by turning off idle machines, a 50% overhead rate for virtualization means virtualization increases power use by 20KW. If we can reduce idle power to 1 watt, even at 10% overhead, virtualization increases power use.  So what are the real numbers? I have not seen any published studies (of actual data centers) – maybe there are some.

If you want a copy of the xls, send me an email. Maybe I set it up wrong.

http://www.hpl.hp.com/personal/Lucy_Cherkasova/papers/final-perf-study-usenix.pdf

This claims lower levels of overhead

http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/

but I’m unconvinced. In particular, I’m curious about memory usage.

This is funny.

The benchmark itself reported its elapsed time by calling a function to find the system time at both the beginning and end of the benchmark.  The elapsed time reported by the benchmark was less than the wall-clock elapsed time.  What we hypothesize is that, due to the unrelenting CPU consumption by the benchmarks, the virtualization layer was unable to update its clock with the virtual CPU clock ticks.  This phenomenon is mentioned in [10] and [11] but we feel that this type of CPU workload severely exaggerates the situation.

http://www.cmg.org/measureit/issues/mit39/m_39_1.html

See the last letter in this

http://serverfault.com/questions/135431/is-virtual-machine-slower-than-the-underlying-physical-machine

While it is obvious that load is critical in any analysis, it may not be obvious how for example memory usage can depend on scheduling. If VM1 and VM2 run serially, memory usage is the max of the two, if they overlap it is the sum – unless it’s ok to slow them both down with more VM operations – which will, of course, increase the time to complete which uses capacity since that time is now not available for a third VM etc.

It’s also important to understand whether overhead is per VM. Suppose that we have 2% overhead per VM, all roughly the same size and 10 VMs. Is this overhead additive? Clearly cpu time is additive and so is I/O time, memory pressure is fuzzier and depends on how many VMs we run at any one time.

Notes

[1] If you have multiple cores, which you do, then if there are enough cores to run VM1 and VM2 in parallel, no problem. And this brings up the question of the relative power use, say of 2 dual core machines versus one 4 core machine or other multiples. Note that it’s hard to get power savings by turning off 4 of the 8 cores of a 8 core machine, but possibly easy to power down the one 4 core machine.

Microsoft by the numbers

From correspondent AY:

150,000,000
Number of Windows 7 licenses sold, making Windows 7 by far the fastest growing operating system in history.
<10
Percentage of US netbooks running Windows in 2008.
96
Percentage of US netbooks running Windows in 2009.
9,000,000
Number of customer downloads of the Office 2010 beta prior to launch, the largest Microsoft beta program in history. [source]
24%
Linux Server market share in 2005.
33%
Predicted Linux Server market share for 2007 (made in 2005).
21.2%
Actual Linux Server market share, Q4 2009.

http://blogs.technet.com/b/microsoft_blog/archive/2010/06/25/microsoft-by-the-numbers.aspx

Those last numbers are especially damning since Linux started with superior technology, has an easier business model if your only goal is market share, and did not have a legacy ball-and-chain anywhere near the size MS has to drag along. But years of directionless bloat have taken a toll and the sponsor driven decisions to go for traditional “server/OS” technology methods in place of trying to find solutions to current customer problems has been very damaging.

Even discounting the obvious PR froth of this article: http://www.eweek.com/c/a/Linux-and-Open-Source/Linux-Losing-Market-Share-to-Windows-Server it is an interesting trend.

and just for kicks from April 2000

“During his presentation on scaling Linux to the enterprise, BitMover, Inc. CEO Larry McVoy raised a few furrowed eyebrows at the recently-held Colorado Linux Info Quest (CLIQ). His message: Symetric multiprocessing (SMP) scaling may be hazardous to your operating system (OS) health.”

“McVoy said that the level of harm is “directly proportional” to the amount of scaling and is “worse than linear” in the number of processors. Converting a uniprocessor OS to a four-way SMP OS introduces a “small amount of damage.” Converting the four-way SMP OS to a 32-way SMP OS does even more damage, he told the crowd. McVoy calls this phenomenon “the locking cliff.”"

“The bottom line, said McVoy, is that: “Linux needs to have bragging rights on ‘big iron’ to be taken seriously in the enterprise. But the traditional way of getting those rights involves a series of changes which do a lot of damage to the source base. So the problems are that Linux needs to scale, and traditional scaling is a bad idea. Linux will use traditional scaling if nothing else shows up,” he said, “but SMP clusters is a better way to do it. I’m the driving force behind that and I’m not driving because I’m wrapped up in BitKeeper.”"

http://www.linuxtoday.com/news_story.php3?ltsn=2000-04-13-010-06-NW&tbovrmode=3