Whenever something - and this can be something non-physical like a stream of bytes or a huge chunk of extremely physical rocks - needs to move, you can choose between a set of different alternatives in the way you transport it: You can transfer as much as possible in one go, or alternatively, you could take multiple round trips with smaller amounts of your payload. When you're a teenager moving out of your parent's house, you will quite likely just pack your stuff into your and your friend's cars and just hit the road, going back and forth a few times just to get out as quickly as possible. Years later, after you bought and sold the right stock at the right time, you might instead hire someone to move everything from your 8 bedroom home in one state to your new mansion in a different state using just one big truck and trailer. (Unless of course, you had special help with your choice of stocks, in which case somebody will move you with a rather small car to a rather small room in your final roundtrip for the next 15 years.)
Is Bigger Better?
Despite the fact that reducing the number of roundtrips usually decreases the complete processing time, the usage of smaller units of transportation also has a few advantages: you can for example unpack the first boxes and start using their contents while the rest of your flat is still being sent in smaller packages. That’s what we ended up calling streaming. (My wife would now point out the fact that somebody in our family always managed to be out of the country whenever the two of us moved. That’s what we ended up calling slipping away. Unless you are my wife, in which case you would have use a slightly more explicit term.)
You also get the benefit of being able to use the smaller self-contained packages which might arrive out of sequence. In computer systems, this is sometimes implemented by only returning a small response (let’s say only the header information) as the answer of a synchronous request while returning the detailed information asynchronously using a message queuing system. In real life, I tend to implement this during my regular commuter flights: no matter whether or not my checked bags are delayed or re-routed, I will always have my computer, a power adapter, a toothbrush, and clothes for the next day in my carry on luggage. Especially when traveling via CDG or LHR.
The Speed Of Light – Or: In Doubt, Assume Bandwidth
But in any case: the general recommendation is that chunky interfaces are better than chatty ones. This suggestion is based on the belief that, in doubt, you should assume high bandwidth but not low latency. And this belief in turn is grounded in one ultimate fact: the former can be bought with money – the latter can’t.
I’ve been online since 94. At that time I used a 1200 baud modem to connect to the Internet via terminal dial-in to a Unix box. For me the WWW was Lynx, but that’s a completely different story. At that time, I could send a ping from Europe to the US in about 1200 milliseconds. Today, I can roundtrip the same ping in about 120 milliseconds. But today, I can download the full 3629.6 MB of Visual Studio 2005 Team Suite in approximately 6 hours from a random hotel room. This is coincidentally what I’m doing right now which triggered the writing of this article.
The Long Walk
If I would have done the same thing back in ’94, it would have taken roughly 367 days to transfer the 3,805,911,450 bytes with approximately 120 bytes per second, including start/stop bits and hardware compression. Just to put this into perspective: let’s assume that your hotel room is at the point on this earth which is the farthest away from Redmond. (The fact that penguins will be the only neighbors on this small island might make you think again about the likely roots of the Linux mascot.) If you would have received divine help to walk over water towards the Microsoft HQ, something interesting would have happened: With a swift pace of 5 kilometers (3.1 miles) per hour for 12 hours a day, you would have finished the roughly 20,000 kilometers (12,427 miles) on the earth’s surface in 333 days (23.7 fortnights) which means that you would have had your hands on Visual Studio about a month earlier than your friend who started the download at the same time when you left the island.
Now, of course, this would not have helped you too much as you would have had to wait two more years for a DVD player to become available 1997.
But I think that it’s really interesting to see that the end-to-end bandwidth increased by 1468 times within the last 11 years while the latency (the time a single ping takes) has only been improved tenfold. If this wouldn’t be enough, there is even a natural cap on latency. The minimum round-trip time between two points of this earth is determined by the maximum speed of information transmission: the speed of light. At roughly 300,000 kilometers per second (3.6 * 10E12 teraangstrom per fortnight), it will always take at least 30 milliseconds to send a ping from Europe to the US and back, even if the processing would be done in real time.
That’s why most people recommend chunky interfaces instead of chatty ones to optimize for higher latency instead of smaller bandwidths: The latter will be solved automatically; the former only if you prove Einstein wrong.
Ingo, you do mean to optimize for **lower** latency, not higher, right? In other words, your are trying to say architect for low latency, because if you don't, there is no bandwidth in the world that will save you then. :) Especially with chatty interfaces... Miha
Posted by: Miha Valencic | 11/11/2005 at 10:35 PM
The key takeaway here is that web sites will load insanely faster on some links if page and all its sub pages would be compressed and sent in one go. Properly designed WPF/XAML will no doubt load a ton faster than a traditional web page trying to approximate a cool look with a ton of small images. I've seen a 500-1000 KB .pdf load faster than the web page it was on..
Posted by: ac | 11/21/2005 at 02:05 PM