"It's the Latency, Stupid" by StuartCheshire?
, May 1996.
A paper which argues that latency, rather than bandwidth, is the most important parameter for networking performance. (Of course, bandwidth is important too.)
The stated topic seemed irritatingly obvious, until I clicked through and saw this:
Ah, that's different.
- Years ago David Cheriton at Stanford taught me something that seemed very obvious at the time...It's now many years later, and this obvious fact seems lost on the most companies making networking hardware and software for the home. I think it's time it was explained again in writing."
- One interesting observation, hinted at in the paper but not stated explicitly (and perhaps a bit moot in these days of cheap broadband to the home): Modem manufacturers, by virtue of the increasingly complex (and DigitalSignalProcessing-intensive) modulation and compression schemes, have been actively trading away latency for bandwidth. It doesn't take 100ms of latency to convert a bit into an audio tone; it does when you have a nest of adaptive filters trying to compensate for the characteristics of the phone line in order to get as much usable bandwidth as possible.
You know, reading Stuart's paper, I couldn't help noticing that there are parallels in software. The most dramatic instance that comes to mind is database usage.
I've written serious EnterpriseScale?
software using a database language & engine that has a lower theoretical capacity
engines, but achieved results that were more usable at the desktop -- because I was able to reduce the latency to nearly nothing (from the user's perspective).
They don't want to "ClickAndWait?
" they want to see something right now. The majority of the queries done from the desktop were single or double record requests, with spikes of a few dozen, but in general the user was not interested in browsing 10,000 records at once. Yes, I still had to do magic to do summary reports in a timely fashion, but the majority of the people using the system had a "wow, that's fast" experience most of the time.
Not to mention the parallels in pr0n. What good is it to wait a while to see if the first few frames of a video are of somebody hot enough to continue watching? Much better to see them asap. . .
120x120 pixel thumbnails.
See also: RemoteGuiProtocols