Thursday, December 20, 2007
Wednesday, December 19, 2007
Tuesday, December 11, 2007
CMG was a bit of a blur for me because I ended up doing 10 hours of presentations, including an interview for a future podcast. Our performance visualization ("PerfViz") session was very well attended and the demos went better than expected due to Mario finally getting his Java act together about 2 hours before we went live. Nothing like JIT capacity planning!
We also had the biggest BOF session attendence of CMG 2007. Stay tuned for more details about the significance of this turnout for CMG 2008, including a new online "PerfViz" forum.
As promised to the attendees of my various CMG sessions, you will find all the supporting materials posted on my web site at the CMG Materials page.
Friday, November 30, 2007
- Sunday Workshop
"How to Move Beyond Monitoring, Pretty Damn Quick!"
Sunday 1:00 PM - 4:30 PM
Room: Elizabeth D/E
"Capacity Planning Boot Camp"
Three Sessions 431
Wednesday 1:15 PM - 2:15 PM
Wednesday 2:45 PM - 3:45 PM
Wednesday 4:00 PM - 5:00 PM
Room: Elizabeth D/E
Introductory CaP class for newbies.
- Apdex Alliance Meeting
"Triangulating the Apdex Index with Barry-3"
Wednesday 4:00 PM - 5:00 PM
This talk is part of the Apdex mini-conference at CMG and will be presented by Mario Jauvin, since it overlaps with my CMG-T classes.
- Hot Topics Paper 7050
"Seeing It All at Once with Barry"
Session 511 (Advanced)
Monday 4 pm - 5 pm
Room: Elizabeth D/E
Dr. Neil J. Gunther, Performance Dynamics
Mario Jauvin, MFJ Associates
Complete abstracts were blogged previously.
Wednesday, November 28, 2007
- Satisfied (0 < S < τ)
- Tolerating (τ < T < 4τ)
- Frustrated (F > 4τ)
Thursday, November 1, 2007
Monday, October 29, 2007
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.
Sunday, October 28, 2007
Monday, October 22, 2007
I wish I'd thought of that.
Friday, September 28, 2007
Tuesday, September 25, 2007
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."
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?
Thomas Edison: "There's a better way. Find it!"
Sunday, September 23, 2007
- 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).
Tuesday, September 18, 2007
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.
- 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.
Monday, September 17, 2007
"I'm trying to understand concepts behind performance modeling (analytical modeling) based on MVA algorithm. ...I'm also trying to understand WHAT IF scenarios such as: What if I increase my CPU speed or upgrade Disk I/O subsystem? What impact will the increase in CPU speed have on throughput, response time and more variables? What if I increase number of users. I have couple of questions to get a better picture of MVA algorithm:
- How to find visit ratios for CPU?
- Can I vary service time (S) for a resource (CPU or disk) if I increase/decrease the processor/disk speed to answer WHAT IF scenarios?"
Sunday, September 16, 2007
"All observation must be for or against some view if it is to be of any service." (Source: Scientific American magazine, April 2001)
All performance monitoring must either agree or disagree with some performance model* if it is to be of any use.
* A performance model could be any or all of a SWAG, a back-of-the-envelope calculation, an Excel spreadsheet, a Mathematica notebook, an S-plus script, a PDQ model, a SAS model, a SimPy simulation, a LoadRunner script, etc.
I'll have a lot more to say about this during my CMG Sunday Workshop entitled Moving Beyond Monitoring, Pretty Damn Quick! (December 2, 2007).
Billionaire activist investor Carl Icahn (Wasn't he in the movie "Corporate Raiders of the Last Deutschmark"?) has called for the sale of BEA Systems Inc., whose stock price has sagged with the growth in open-source software and under pressure from larger competitors such as IBM Corp. and Oracle Corp. Analysts said BEA has failed to stir enthusiasm among investors. For example, Rob Enderle, principal analyst with Enderle Group, a technology consulting firm in San Jose, Calif. stated, "This class of software, because of open source, it's much harder to get people interested in it unless you're doing phenomenally well in sales...which BEA has not been."
Also on Friday, BEA said it has received an additional notice from the Nasdaq that it remains out of compliance because of the delayed filings and its shares remain in danger of being delisted.
Thursday, August 30, 2007
Wednesday, August 29, 2007
Postscript: Todd Coram responded via email and stated that his attempt had gone into limbo some time ago. So, it looks like open season for anyone interested in doing a Tcl port of PDQ (or any other language for that matter).
Initially, the agreement will involve only IBM's (AIX) mid-range servers, which can also run the Windows and Linux operating systems, but eventually, so the report says, IBM hopes to bring Solaris to the mainframe. I assume this means it will run in a z/OS LPAR, like they do with Linux. If I take the view (and I do) that the mainframe is not a "dinosaur" but just another (excellent data processing) server on the network, one wonders where this leaves future Sun hardware platforms.
Add to this the growing emphasis by Sun to deploy Intel and AMD microprocessors for cost reasons and, as Jonathan Schwartz says, it "represents a tectonic shift in the market landscape." No kidding! I just wonder whether Schwartz will be riding the plate that stays on top or the plate that goes under.
Section 2.1 even has some words about the CFS scheduler. I would still like to see a more detailed comparison of CFS with the well-known TSS (time share) scheduler and lesser-known FSS (fair share) scheduler.
Wednesday, July 11, 2007
Shellkommandos wie »uptime« werfen stets drei Zahlen als Load Average aus. Allerdings wissen nur wenige, wie sie zustande kommen und was genau sie bedeuten. Dieser Beitrag klärt darüber auf und stellt zugleich mit dem Stretchfaktor eine Erweiterung vor.
The main theme is about how to extend absolute load averages to relative stretch factor values.
which contains quite a good summary of books, papers, and tools on queueing networks. Tbe German word "Warteschlangen" translates literally as "waiting snake."
Thursday, June 28, 2007
#!/usr/bin/python import random r = random.randrange(100,1000,2) print r while True: r /= 2 print r if r % 2 != 0: break
Run it several times and you will see that the sequence, although generally not long, contains an unpredictable number of iterates. This is easily understood by noting that division by 2 is equivalent to a bitwise right-shift (i.e., >> operator in C, Python and Perl), so each successive division simply marches the bit-pattern to the right until a '1' appears in the unit column. That defines an odd number and another right-shift produces '1' as a remainder, which I can either ignore as with integer division or carry as a fraction. It also means that you can predict when you will hit an odd number by first representing the starting number as binary digits, then counting the number of zeros from the rightmost position to the first occurrence of a 1-digit.
In the manufacture of microprocessors and memory chips, the increase in speed follows Moore's law, which is also a halving sequence like the above. Therefore, we see natural numbers like 90 nanometer (nm), 45 nm, and so on. For reference, the diameter of the HIV virus (a molecular machine) is about 100 nm. As I've discussed elsewhere, 45 nm is the next-generation technology that IBM, Intel and AMD will be using to fabricate their microprocessors. But the current smallest technology being used by AMD and Intel is not 90 nm, it's 65 nm. And the next generation after 45 nm will be 32 nm, not 20-something. So, where do these 'unnatural' numbers come from?
Each progression in shrinking the silicon-based photolithographic process is identified by a waypoint or node on a roadmap defined by the Semiconductor Industry Association or SIA. The current SIA roadmap looks like this:
Year 2004 2007 2010 2013 2016 2020 nm 90 65 45 32 22 14
A technology node is defined primarily by the minimum metal pitch used on any product. Here, pitch refers to the spacing between the metal "wires" or interconnects. In a microprocessor, for example, the minimum metal pitch is the half-pitch of the first layer of metal used to connect the actual terminals of one transistor to another. Notice that IBM and Intel technology is moving faster than SIA expectations, so the roadmap already needs to be updated again.
Wednesday, June 20, 2007
Friday, June 15, 2007
This statement would be laughable, if he weren't serious. Consider the following:
- How can current Linux instrumentation be sufficient when older UNIX performance instrumentation is still not sufficient?
- UNIX instrumentation was not introduced to solve real-world performance problems. It was a hack by and for kernel developers to monitor the performance impact of code changes in a light-weight O/S. We're still living with that legacy. It might've been necessary, but that doesn't make it sufficient.
- The level of instrumentation in Linux (and UNIX-es) is not greatly different from what it was 30 years ago. As I discuss in Chap. 4 of my Perl::PDQ book, the idea of instrumenting an O/S goes back (at least) to c.1965 at MIT.
- Last time I checked, this was the 21st century. By now, I would have expected (foolishly, it seems) to have at my fingertips, a common set of useful performance metrics, together with a common means for accessing them across all variants of UNIX and Linux.
- Several attempts have been made to standardize UNIX performance instrumentation. One was called the Universal Measurement Architecture (UMA), and another was presented at CMG in 1999.
- The UMA spec arrived DOA because the UNIX vendors, although they helped to design it, didn't see any ROI where there was no apparent demand from users/analysts. Analysts, on the other hand, didn't demand what they had not conceived was missing. Such a Mexican standoff was cheaper for the UNIX vendors. (How conveeeeenient!) This remains a potential opportunity for Linux, in my view.
- Rich Pettit wrote a very thoughtful paper entitled "Formalizing Performance Metrics in Linux", which was resoundingly ignored by Linux developers, as far as I know.
Wednesday, June 13, 2007
Friday, May 25, 2007
Constructing illusions by hiding physical information from users is one thing, propagating that illusion to the performance analyst or capacity planner is quite another, and considered harmful.
Presumably, it's also potentially bad for business, in the long run. This unfortunate situation has arisen for one of the following reasons:
- The performance data that is available is incorrect.
Example: Enabling hyperthreading on a Xeon processor misleads the operating system, and thereby performance tools, into treating the single core as 2 virtual processors. This means that many performance management tools will conclude and report that your system has 200% processor capacity available. But, this is an illusion, so you will never see 200% processor capacity.
- The correct performance data is not made available.
Example: With hyperthreading enabled, there should be a separate register or port that allows performance management tools to sample the actual utilization of the single physical core (AKA the execution unit). The IBM Power-5 has something called the PURR register that performs this role.
There are many examples of this kind of mangled performance shenanigans in the virtualized world, especially in what I call the meso-VM (PDF) level such as VMware and XenSource. The good news there is, since it's software, it's easier to modify and therefore more likely that actual performance data will become exposed to the analyst.
In other words:
Fewer bells, more whistles
should be the watchword for virtualization vendors.
Wednesday, May 23, 2007
Some related blog entries are:
Tuesday, May 22, 2007
Saturday, May 5, 2007
Tuesday, May 1, 2007
In single core systems, software code basically runs sequentially, with each task occurring one after another, but in multicore systems tasks get split up among the cores and when different tasks need to access the same piece of memory and fail to properly synchronize the data can become corrupted and cause the program to crash. MIT has designed StreamIt, a computer language and a compiler that basically hides parallel-programming challenges but also allows for full use of multicore processors.
Friday, April 20, 2007
The online PDQ Manual is also being revised to include PyDQ functions and code examples.
Wednesday, April 18, 2007
Tuesday, April 17, 2007
Intel said that early Penryn performance tests show a 15 percent increase in imaging related applications, a 25 percent performance increase for 3D rendering, and more than 40 percent performance increase for gaming. The tests, according to Maloney, were based on pre-production 45nm Intel quad core processors running at 3.33 GHz with a 1333 front side bus and 12 MB cache versus a 2.93 GHz Intel Core 2 Extreme (QX6800) processor, just announced last week . Intel said that for high-performance computing, users can expect gains of up to 45 percent for bandwidth intensive applications, and a 25 percent increase for servers using Java. Those tests were based on 45nm Xeon processors with 1,600-MHz front side buses for workstations and HPCs, and a 1,333 MHz front side bus for servers - versus current quad-core X5355 processors, the company said.
During the call, Intel execs also took the opportunity to reveal a few more details on Project Larrabee, a new "highly parallel, IA-based programmable" architecture that the company says it is now designing products around. While details were scant, Maloney did say that the architecture is designed to scale to trillions of floating point operations per second (teraflops) of performance and will include enhancements to accelerate applications such as scientific computing, recognition mining, synthesis, visualization, financial analytics, and health applications.
Monday, April 16, 2007
"Speckled Computing offers a radically new concept in information technology that has the potential to revolutionise the way we communicate and exchange information. Specks will be around 1 mm3 semiconductor grains; that's about the size of a matchhead, that can sense and compute locally and communicate wirelessly. Each speck will be autonomous, with its own captive, renewable energy source. Thousands of specks, scattered or sprayed on the person or surfaces, will collaborate as programmable computational networks called Specknets.
Computing with Specknets will enable linkages between the material and digital worlds with a finer degree of spatial and temporal resolution than hitherto possible; this will be both fundamental and enabling to the goal of truly ubiquitous computing.
Speckled Computing is the culmination of a greater trend. As the once-separate worlds of computing and wireless communications collide, a new class of information appliances will emerge. Where once they stood proud – the PDA bulging in the pocket, or the mobile phone nestling in one’s palm, the post-modern equivalent might not be explicit after all. Rather, data sensing and information processing capabilities will fragment and disappear into everyday objects and the living environment. At present there are sharp dislocations in information processing capability – the computer on a desk, the PDA/laptop, mobile phone, smart cards and smart appliances. In our vision of Speckled Computing, the sensing and processing of information will be highly diffused – the person, the artefacts and the surrounding space, become, at the same time, computational resources and interfaces to those resources. Surfaces, walls, floors, ceilings, articles, and clothes, when sprayed or “speckled” with specks will be invested with a “computational aura” and sensitised post hoc as props for rich interactions with the computational resources."
I have absolutely no idea what that last sentence means in English, but it sounds like an interesting research goal.
Saturday, April 14, 2007
You can interpret "computer system analyst" (an accurate but slightly archaic term in row 4) as performance analyst or capacity planner.
Links to his report, as well as another by the ACM, are available at the Pulse.
Tuesday, March 20, 2007
- Visualizing Virtualization
- It May Be Virtual - But the Overhead is Not
- A Realistic Assessment of the Performance of Windows Guest Virtual Machines
- Measuring CPU Time from Hyper-Threading Enabled Intel Processors
- Hyperthreading - Two for the Price of One?
- To V or Not to V: A Practical Guide To Virtualization
- The Virtualization Spectrum from Hyperthreads to GRIDs
This issue of MeasureIT is unique in my mind because it is rare to find, in one place, such a broad collection of performance perspectives centered on the intensely hot topic of virtualization.
Friday, March 16, 2007
The performance of the production process trumps the performance of the product it produces.
If you don't read and heed this concept, you are going to find yourself perpetually frustrated. What I mean by this is, that we (performance weenies) are focused on the speeds and feeds of the bits and bytes associated with the technology being produced, whereas most companies these days are forced by Wall Street to be more focused on the performance and cost of their internal management processes.
I said the same thing on page XX of the Preface to my 1998 book, The Practical Performance Analysts:
"Management no longer focuses on the speed of the product as much as the speed of producing the product. Nowadays, production performance matters more than product performance."
I believe this is truer today than it was 10 years ago. Here are some reasons why:
- Many hi-tech companies have offshored their engineering while keeping middle and upper management local. Latest example: Google goes to Poland
- There are substantial tax incentives for USA companies to go offshore, and then ask Congress for more H-1B visas
- There is a financial incentive to charge the customer (possibly you) for performance upgrades
- The Dilbertization of the IT workplace
Is it any wonder then, that you don't get a warm reception from upper management? The odds are stacked against you, and the stack goes all the way back to Wall St. Don't even think about fighting that war. The only battles worth fighting, in my view, are the ones that employ guerrilla-style tactics.
Ironically, as I explain in my classes, this is where performance analysis really started, viz., with Frederic Winslow Taylor, the original performance analyst (anal-ist?) who introduced "time and motion" studies on human production in assembly lines and office environments of the early 1920s.
Oh, in case you're wondering about the title, it's an Aussie-ism. There is no good or smooth end of a pineapple.
Tuesday, March 13, 2007
The article is entitled "Berechenbare Performance" and the Abstract says: Wo man mit Statistik allein nicht weiterkommt, erlaubt es die Performance-Simulation beliebige Was-wäre-wenn-Szenarien durchzuspielen. Ein Perl-Modul hält den Aufwand in Grenzen.
How's your German? Kaput? Maybe Google can help? The appearance of the word 'simulation' in the Abstract is inaccurate, but maybe something got lost in translation.
The main features of PDQ 4.2 are:
- Java version of PDQ contributed by Peter Harding in Australia
- PHP version of PDQ contributed by Italian student Samuel Zallocco
- Threaded-server model and errata corrections contributed by Neil Gunther
- Better organization of the Perl and Python models
- The Java and PHP packages are released stand-alone at this time
Complete installation instructions are available on the download page. Make sure you also read the various README files. Tom Becker (USA) and Christof Schmalenbach (Germany) have kindly provided separate installation notes for ActivePerl on Windows. This also indicates how international PDQ has become.
If you would like to be notified by email about future releases, please fill out this form or subscribe to this blog.
Tuesday, March 6, 2007
Just returned from Dallas where I was an invited speaker at the Hotsos 2007 Symposium on ORACLE performance. This symposium was a class operation: great hotel, great people, great food, great presentations, etc. and, as a newbie, I was treated very well. It seems that Cary Milsap (the energy behind the symposium) had already greased the runway for me, so I found myself to be a known quantity to many of the attendees, even though I had never met them before. This was way cool (Thanks, Cary).
Although ostensibly a group of very enthusiastic ORACLE performance people (about 450 attendees), they are not bigots, so they are interested in all aspects of performance. Moreover, Oracle performance gets critiqued. Capacity planning is one aspect that is new for many of them and I was a member of a panel session on that topic. During the 24 hours I was there, I attended a very interesting session on the measured limitations of RAC 10g scalability for parallel loads (ETL) and queries against a large-scale data warehouse (DWH), and a talk on how data skew can impact the kind of performance conclusions you tend to draw. But perhaps the most interesting things that I learnt came out of several spontaneous discussions I had with various folks, including some conversations that went into the wee hours of Monday morning. My only regret was that I couldn't stay longer. I definitely plan to attend Hotsos 2008.
Saturday, March 3, 2007
Thursday, March 1, 2007
- Disk drives have a field failure rate 2 to 4 times greater than shown in vendors specs.
- Reliability of both cheap and expensive drives is comparable.
- Disk drive failures are highly correlated, thus violating one of the assumptions behind RAID Level-5.
- Disk drive failure rates rise steadily with age rather than following the so-called bathtub function.
Storage vendors such as NetApp and EMC have responded. David Morgenstern asks in eWeek, why would anyone have trusted the MTBFs that appear in vendor glossies in the first place?
Background on failure rate analysis can be found in Chapter 1 of my Perl::PDQ book entitled: Time - The Zeroth Performance Metric.
Tuesday, February 27, 2007
We fell off the Moore's law curve, not because photolithography collided with limitations due to quantum physics or anything else exotic, but more mudanely because it ran into a largely unanticipated thermodynamic barrier. In other words, Moore's law was stopped dead in its tracks by old-fashioned 19th century physics.
If you have a hot topic you'd like to present or know of someone else that might, please let me know about it either by posting here or contacting me via email. Thank you.
Monday, February 26, 2007
I spent several hours on Sunday, Feb 4th, using Amazon's Mechanical Turk to help look for Gray's yacht. The images above (here about one quarter the size displayed by the Turk) show one example where I thought there might have been an interesting object; possibly a yacht. Image A is captured by the satellite at a short time before image B (t1 < t2). You can think of the satellite as sweeping down this page. Things like whitecaps on the ocean surface are going to tend dissipate and thus change pixels between successive frames, whereas a solid object like a ship will tend to remain invariant. The red circle (which I added) marks such a stable set of pixels which also have approximately the correct dimensions for a yacht i.e., about 10 pixels long (as explained by Amazon). Unfortunately, what appears to be an interesting object here has not led to the discovery of Gray's whereabouts.
Use of the Turk satellite images was hampered by a lack of any way to reference the images (about 5 per web page) by number, and there was no coordinate system within each image to express the location of any interesting objects. These limitations could have led to ambiguities in the follow up human expert search of flagged images. However, given that time was of the essence for any possible rescue effort, omitting these niceties was a completely understandable decision.
Sunday, February 25, 2007
I am thinking about presenting a new Guerrilla class on this topic for 2008, which would go well beyond the material in chapter 2 to compare what ITIL offers with what is actually needed to provide proper IT service and capacity planning. I'm working with Steve Jenkin, an IT consultant in Australia, who is currently being ITIL certified. Check out his blog ITIL Utopia - Or Not? as he develops his own unique perspective on ITIL.
Please post your comments and suggestions here so we can get some idea of the level of interest in this topic (possible title: Going Guerrilla on ITIL). Assuming there is interest, I will provide more information about the course content and requirements, as things progress.
If you would like to be notified by email, please fill out this form.
There are some possible complicating factors that could creep in. Questions that immediately spring to mind are:
- Would the Guerrilla levels just be an internal ranking provided by Performance Dynamics?
- Is there any need to have such levels certified by an outside institution e.g., a university?
- Is there a need to have such levels associated with continuing education (CEU) credits?
I would be interested to hear from both managers and Guerrilla alumni on this idea.
My CMG 2006 paper on virtualization was recently blogged at HP Labs in the context of hyperthreading being considered harmful to processor performance. The paper actually provides a general unified framework in which to understand hyperthreading, hypervisors (e.g., VMware, and Xen), and hyperservices (e.g., P2P virtual networks like
BitTorrent); the latter being an outgrowth of something I wrote in response to an online analysis of Gnutella.
The VM-spectrum concept is based on my observations that: (i) disparate types of virtual machines lie on a discrete spectrum bounded by hyperthreading at one extreme and hyperservices at the other, and (ii) poll-based scheduling is the common architectural element in most VM implementations. The associated polling frequency (from GHz to μHz) positions each VM into a region of the VM-spectrum. Several case studies are analyzed to illustrate how this framework could make VMs more visible to performance management tools.
Perf viz for computers (PVC) is both an abiding interest and a pet peeve of mine. I first wrote about this topic in a 1992 paper entitled: "On the Application of Barycentric Coordinates to the Prompt and Visually Efficient Display of Multiprocessor Performance Data." Along with that paper, I also produced what IMHO is an interesting example of an efficient performance tool for the visualization of mulitprocessor CPU utilization called barry (for barycentric or triangular coordinates---get it?), written in C using the ncurses library.
RESEARCH: My role models for PVC are scientific visualization and statistical data visualization. But why should physicists and statisticians have all the fun!? I maintain that similar CHI techniques could be applied to help people do a better job of performancs analysis and capacity planning. I consider a central goal to be to find visual paradigms that offer the best impedance match b/w the digital-electronic computer under test and the cognitive computer doing the analysis (aka your brain). This is a very deep problem because we have a relatively poor understanding of how our visual system works (both the optical and the neural circuits), although this is improving all the time. So it's very difficult to quantify "best match" in general, and even more difficult to quantify it for individuals. One thing we do know is, that vision is based on neural computation; which also explains why the moon looks bigger on the horizion than when you when take a photograph of it in that same location. (How then was the following shot taken?)
developed in Section 4.4 of the Guerrilla Capacity Planning book.
Basically, Denny observes that 2 parameters (a and b) are needed to define an extremum in a quadratic function (e.g., a parabola passing through the origin with c = 0), so a similar constraint should hold (somehow) for a rational function with a quadratic denominator. This is both plausible and cool. I don't know why I didn't think of it myself.