Folsom: Not Just a Prison But A Cache

A nice update to my previous posts about the Intel Penryn microprocessor:

1. Moore at 45 nm
   
2. More on Penryn
   
3. More on Moore
   

appears on a Dutch blog (in English---damn good English, BTW). The blogger was apparently invited to Intel's geographical home for the development of Penryn; not HQ in Santa Clara, California but Folsom (pronounced: 'full sum'), California. Consistent with Intel's January 2007 announcement, he notes that November looks to be show time for their 45 nm technology.

Since the author was a visitor, he failed to appreciate certain local ironies in his report. He missed was the fact that Penryn is a small town due north of Folsom, just off Interstate 80 on the way to Lake Tahoe. He refers to the huge Intel campus at the edge of the town. At the other end of town is an even better known campus; one of the state's major prisons immortalized in this Johnny Cash (not Cache) song. So, not only are criminals cached there but so also are some of Intel's best microprocessor designers (not as an intended punishment for the latter, presumably). OK, I'll stop there because I'm having way too much fun with this. Read the blog.

Erlang's Collected Papers

In 1948, the collected papers of Agner Erlang (AKA the father of queueing theory) were translated from the original Danish and published in the Transactions of the Danish Academy of Technical Sciences. They were reissued as a book by Acta Polytechnica Scandinavica in 1960, but due its underwhelming popularity, that book is now out of print. However, I just discovered that the chapters of the book are now available on the web. Kudos to the Academy!

Streeeeeeetch!

The October 2007 Linux Magazine (no. 10, issue 83, p. 62) is carrying the English version of my original German article about converting load averages to stretch factors. Unfortunately, there is no direct URL (Sun Oct 28, 2007: As Metapost commented below, it is now available for viewing) but the cute visual hook has a picture of a stretch limo ... stretched across two pages.

I wish I'd thought of that.

SOA Scalability and Steady-State

Guerrilla alumnus Peter Lauterbach just brought to my attention an article in SOA World entitled "Load Testing Web Services". I have to commend these authors for performing their SOA load tests in steady state. Elsewhere, I've discussed how wrong things can go when you don't adhere to this procedure. In their online article, these authors show the response time (R) as a time-series plot, more or less as it would appear in a measurement tool like say, LoadRunner. Although they don't show it, the throughput measurements would also look similar when plotted as a function of time (t).

Best Practices Are An Admission of Failure

Six Sigma: Quite a list.

ITIL: Best Practice is defined as "good working practice developed through consensus that helps organizations to achieve better performance.”

Sounds good, but ...

Ludwig Wittgenstein: "Just because we all agree on something, doesn't make it true."

Therefore ...

Guerrilla Manual 1.21: Best Practice is tantamount to not trying to understand the problem. Merely copying someone else's apparent success is like cheating on a test. You might make the grade, but how far is the bluff going to take you?

So ...

Thomas Edison: "There's a better way. Find it!"

Black Swans, Instantons, Hedge Funds and Network Collapse

On my flight to Europe last July, I read The Black Swan: The Impact of the Highly Improbable by N. Taleb. Unfortunately, I found the book irksome for several reasons:

• I already knew the mathematical underpinnings of the metaphors used in the book (more on that below).
  
• Taleb's writing style is unnecessarily condescending toward others mentioned in the book and to the reader.
  
• Some rather obvious points are labored. The weirdest of these comes in the form of a entirely fictitious character to which an entire chapter is devoted.
  
• Many of his often poor and sometimes inaccurate examples kept reminding me of something a Stanford mathematician once told me: "Economists are mathematically unsophisticated."
  
• He describes a general problem or syndrome related to how people assess risk incorrectly, but he doesn't really offer any solutions (or maybe I missed it in the chapter entitled, "How to Look for Bird Poop" ... seriously).
  

I must say this book was a disappointment because it was a stark contrast to seeing him interviewed months earlier on PBS, where he came across as more thoughtful and measured. My opinion notwithstanding, you might find the book worth reading because it's an easy read, it covers many topics (mostly with a financial slant—the author's background), and he's also warning the reader about the dangers of things like high-risk hedge funds. Moreover, as I shall try to demonstrate here, these same concepts also impinge on performance analysis (not that Taleb is aware of that) and whereas they might otherwise be impenetrable to the non-mathematician, possibly they are made a little more accessible in a book like this. In a nutshell, I believe he is saying: Think wild, not mild; easy to say, hard to do, as I shall try to explain.

Virtualization Rootkit Wars

VMM malware is another side-effect of creating illusions (See my previous blog entry on the danger of illusions). It turns out that still waters run very deep. Here's a potted summary of some recent events in the world of stealth that have impinged on both VMM security issues and performance analysis. (The following contains a lot of acronyms, for which I've provided a glossary at the end).

Last year at BlackHat, some Polish security experts announced a proof-of-concept for a VME rootkit called "Blue Pill " (BP) that they claimed was undetectable. For BlackHat 2007, some U.S. security experts challenged the Polish team to a Detect-A-Thon (my term). This caused the Polish team to go into defensive posture and make a list of run-rules (my term) for how the Detect-A-Thon was to be carried out. Since BP is only a virtual rootkit (if I can use that term), one of the proposed run-rules was payment (up front?) of almost $500,000 for development costs to make a real implementation of BP battle ready. Nice work if you can get it.

Quite apart from all these claim-counter-claim machinations, what got my attention was one of the ways by which the U.S. team claimed that BP would be detectable (there are plausibly many) viz., counting execution cycles. The CPUID instruction, in particular, is supposed to only take 200 cycles (as root), not 5000 cycles (non-root). I saw a certain irony in the fact that, although I've been complaining about VMM illusions masking correct performance analysis, performance analysis is one method for detecting HVM malware. The procedure is analogous to the analysis in Section 3.2.2. of my CMG 2006 paper "The Virtualization Spectrum from Hyperthreads to GRIDs" where I showed that the increase in thread execution time is due mostly to an inflation of the thread service time on a dual-core. There, I had to infer the effect from system-level measurements whereas here, they are talking about reading the actual cycle counter/register directly. It turns out that this technique is not totally foolproof either, because the timings can be masked with the appropriate trap. Looking for changes in the TLB is another method that has been proposed. Naturally, in this kind of game, the beat goes on and although rootkit detectors are already available, there will be many more as VMM stealth techniques evolve.

Glossary

• BP: "Blue Pill". An HVM rootkit.
  
• CPUID: x86 instruction to identify the CPU type.
  
• Guest: VMWare lingo for a native O/S that runs on a VMM.
  
• HVM: Hardware-Assisted Virtual Machine.
  
• Hyperjacker: Hypervisor hijacking.
  
• Hypervisor: See VMM.
  
• Malware: Malicious software. A stealthy rootkit in this context.
  
• Rootkit: A set/kit of tools/executibles with root access (highest privilege).
  
• TLB: Translation Look-aside Buffer.
  
• VME: Virtual Machine Emulators e.g, "Blue Pill", "Vitriol".
  
• VMM: Virtual Machine Monitor e.g., VMWare, Xen.