Block The Emergency Exit for Faster Evacuations

NewScientist reports that Japanese physicists timed a crowd of 50 women(?) as they exited as fast as possible through a door. They then repeated the experiment with a 20 cm (10 inch) wide pillar placed 65 cm (2 feet) in front of the exit to the left-hand side. The obstacle increased the exit throughput by an extra seven people per minute.

"Usually, the exit becomes clogged by people competing for the small space, and the crowd is slowed. The pillar blocks pedestrians arriving at the exit from the left so effectively that the number of people attempting to occupy the space just in front of the exit is reduced, says Yanagisawa. With reduced crowding there are fewer conflicts and the outflow rate increases."

How does this apply to computer performance? Think polling systems, where there are multiple waiting lines or buffers but only one service facility, like a grocery store with the usual checkout lanes but only one cashier running between them! Would you want to shop in that store? In the physics experiment, the exit is the single server and the lines are the streams of people (women?) approaching the exit from all angles. The asymmetric placement of the pillar effectively reduces the number of exit streams that can form (I'm guessing).

SPAD Quantum Camera: The Owner's Manual

For those of you following my travails in quantum information processing, our most recent work just appeared in the prestigious open-access journal Optics Express, published by the Optical Society of America, under the title: "On The Application Of A Monolithic Array For Detecting Intensity-Correlated Photons Emitted By Different Source Types." (PDF)

Bandwidth and Latency are Related Like Overclocked Chocolates

Prior to the appearance of special relativity theory (SRT) in 1905, physicists were under the impression that space and time are completely independent aspects of reality described by Newton's equations of motion. Einstein's great insight, that led to SRT, was that space and time are intimately related through the properties of light.

Space and time are related

Instead of objects simply being located at some arbitrary position x at some arbitrary time t, everything moves on a world-line given by the space-time pair (x, ct), where c is the universal speed of light. Notice that x has the engineering dimensions of length and so does the new variable ct: a speed multiplied by time. In Einstein's picture, everything is a length; there is no separate time metric. Time is now part of what has become known as space-time—because nobody came up with a better word.

Response Time Knees and Queues

How do you determine where the response-time "knee" occurs? This is a question one commonly hears with reference to characterizing the performance of an application. Calculating where the response time suddenly begins to climb dramatically is considered, by many, to be an important determinant for such things as load testing, scalability analysis, and setting application service targets.

In a previous blog post, I pointed out that such a "knee" is actually an optical illusion. Nonetheless, this same question arose in last month's CMG MeasureIT, as a kind of survey entitled "Does the Knee in a Queuing Curve Exist or is it just a Myth?" Although that author concludes (correctly) that the existence of a "knee" (as it is usually meant) is bogus, the panoply of responses was quite astounding—especially coming from professionals who ought to know better. In this month's MeasureIT, I examine the same question in a rigorous but unconventional way under the title "Mind Your Knees and Queues: Responding to Hyperbole with Hyperbolæ."

A Funny Thing Happened on the Way to the Priority Queue

Suppose two workloads $W_a$ and $W_b$ access a common resource, e.g., the CPU. They each have response times $R_a$ and $R_b$, respectively. The response time $R_a$ is longer than you would like. A common way to try and improve $R_a$ is to give $W_a$ a higher priority at the CPU. That's what the Unix nice command is all about. For example, if $W_a$ were a Unix process then: nice -15 Wa, would give a higher priority than the default already assigned by the Unix scheduler. But how much better will it's response time be? Nice can't tell you that.

Towards a Cloud Capacity-Cost Formula

One of the (unscheduled) plenary sessions at Velocity 2009, was entitled: “Why elasticity, performance, and analytics will change how Webops is judged" (PDF), given by Alistair Croll. An earlier version of Alistair's ideas can be read on his blog. As I understand it, he's attempting to tie together the capacity-on-demand concept of cloud computing with the way a user is charged for resource consumption and how the provider counts revenue; a kind of dynamic capacity planning and chargeback association. Currently, for example, Amazon EC2, Google App Engine and Salesforce, all do this differently. This looks like a very important point, which I would like to understand more thoroughly. By slide 3 in his presentation, he refers to a simple capacity formula and that's what I want to discuss here, because that's what suddenly locked up my attention.

Starbucks Discovers Performance Analysis!

According to the WSJ, Starbucks "vice president of lean" (and apparently mean), has discovered performance analysis.

Heeellooooo! That would be The Principles of Scientific Management, developed by Frederick Winslow Taylor almost a century ago. Of course, it's uncool to be a prophet in your own land, so more notice was eventually taken in Japan then the USA, after WW-II. Baristas will probably be less than bullish on it, but they can take heart that this genius idea by the VP of Lean is totally pre-Toyota.