Bandwidth, and how to use it upOriginally published 2001,
in Atomic: Maximum Power Computing
Last modified 03-Dec-2011.
The first thought that goes through the mind of all right-thinking people when they get a broadband Internet connection is "How can I use all of this bandwidth, all day long?"
People who are still stuck with dial-up modem Internet access care deeply about bandwidth, too, for much the same reason that drowning people care deeply about air.
So how can broadband users stretch the limits of their high-speed link, and what's meanest to a modem? Read on.
Up versus down
When someone talks about a communications link with a given bandwidth - say, 128 kilobits per second - they're usually referring to a half duplex connection at that speed. Half duplex means that data can flow both ways, but not at the same time. In a full duplex connection, data can flow both ways at once, and the total available bandwidth is thus doubled if the upstream and downstream speeds are the same. When a connection's full duplex, though, that's usually mentioned right next to the bandwidth - "128 kilobits per second full duplex", or "full duplex, aggregate bandwidth 256 kilobits per second".
Note, here, that people often confuse bits and bytes when they're talking about connection speeds. Digital communication links are normally specified in bits per second - so a "56K" modem has a theoretical top speed of 56 kilobits per second, and "100BaseT" Ethernet has a bandwidth of 100 megabits per second.
There are a thousand bits in a kilobit, and a million bits in a megabit. And there are eight bits in a byte - well, in the kind of byte used by consumer computers, anyway. But, annoyingly, there are 1024 bytes in a kilobyte, and 1048576 bytes in a megabyte; people are trying to get different prefixes used for these powers-of-two numbers to distinguish them from the normal powers-of-ten SI prefixes, but it's just not happening.
So a 128 kilobit per second connection moves 16000 bytes per second, but that's only 15.625 kilobytes. When you see a connection speed specified as some number of "kbps" or "kBps" or "KBPS" or whatever, it probably means kilobits per second. But don't bet your life on it.
And now, back to duplex.
If you're only moving data one way, it doesn't matter whether the connection's half or full duplex. If your connection speed is 128 kilobits per second and you're downloading data from a server that can deliver bits faster than the link can pipe them to you, you'll only get that data at 128 kilobits per second, minus whatever overhead your communications protocols impose. Full duplex will be a little bit faster, because you'll be sending a small amount of acknowledgement data back to the server, and full duplex won't have to interrupt the download to do that. But the difference will be trivial.
For the same reason, if you're just uploading data to a similarly speedy server, you'll get the same speed from full or half duplex.
But if you upload and download at the same time, then half duplex will only give you 64 kilobits per second each way, at once.
The above examples are "symmetric" connections; they work at the same speed each way. But pretty much every consumer Internet access technology is "asymmetric" - the upstream (from you to the ISP) and downstream (from the ISP to you) links run at different speeds.
A "56K" V.90 dial-up modem, for instance, will probably actually connect at some speed between 44 and 52 kilobits per second, depending on line conditions. But that's only the downstream speed. Upstream, you get 33.6 kilobits per second at most - the same ceiling speed as the older V.34bis standard.
A humble modem link is, at least, full duplex. You can be downloading at 44 to 52 kilobits per second, and uploading at 33.6 kilobits per second, simultaneously. All of the popular broadband technologies are full duplex, as well.
Cable modem and Asymmetric Digital Subscriber Line (ADSL) are asymmetric; ADSL tells you that right there in its name. These services tend to be "throttled" by the ISPs, especially in the upstream direction; there's likely to be a hard upstream speed limit, and there may be a hard downstream limit as well, and/or "traffic shaping" that steadily reduces your downstream transfer rate if you've been downloading at full speed for a little while.
Even with no artificial bandwidth restrictions, though, ADSL and cable Internet connections still have more downstream speed than upstream. They're made that way.
This is fine, for most purposes. Most of the things that most people want to do on the Internet involve receiving a lot more data than you send.
This explains why people can tolerate asymmetric satellite Internet connections, which have a dial-up modem upstream link and a much faster satellite-dish downstream one.
How much bandwidth does Web browsing consume? Good question.
Browse with images turned off and all you'll download from an ordinary HTML page is that ordinary HTML. A few tens of kilobytes per page, at most, for the majority of sites.
Turn on images and start hitting multimedia-heavy sites and you can easily fill the pipe from you to the Web server. That might not be a very impressive achievement, though, as multi-hop connections to sites in faraway lands may not leave you with much of a pipe to fill.
Browse sites only a few hops away and connected to your ISP by big fat pipes - like http://mirror.aarnet.edu.au/ , for instance, for pretty much any Australian user - and you're likely to saturate your Internet connection's entire download bandwidth.
If you don't make a special effort, though, you're unlikely to consume much more than ten megabytes (Mb) per hour of ordinary Web surfing.
If you play action games over the Internet, a broadband connection like ADSL or cable will give you a much nicer play experience than will dial-up. But the difference is due to lower latency as much as it's due to higher bandwidth.
Latency, also referred to as "lag" or "ping time", is how long data takes to get from somewhere to somewhere else. Latency can just mean the time data takes to go from one point to another, but when the term's used by Net users are usually talking about round trip latency - how long it takes your input to reach a server, plus how long the server takes to think about it, plus how long it takes the server's response to come back to you. Ping time is always round trip latency, because that is the nature of ping.
For Web browsing, even several seconds of round trip latency isn't hugely annoying. But for action games, particularly First Person Shooter (FPS) games, every millisecond counts.
Games use all sorts of clever tricks to minimise the amount of data that has to be sent, and to minimise your gaming experience's dependency on other people's data. But when you shoot at someone, or just bump into them in a doorway, decisions must be made.
Some action games, like flight simulators, can get away with really crummy latency and bandwidth. The players don't interact with each other much in a game like this, compared with the face-to-face infighting of a FPS. Plus, everybody generally has limited manoeuvrability, so "client-side prediction" of other player's behaviour can do a very good job. A Spitfire can do several things, but it can't stop dead from full speed, or instantly spin 180 degrees, as an FPS player can. Most online multiplayer games don't have these sorts of loopholes.
Even big FPS games, though, need surprisingly little bandwidth. They have to keep their demands low, or they'll be completely unplayable over dial-up Internet connections. So that dial-up players can still play, many games are tuned to deliver a playable - for suitably small values of "playable" - experience with only about five kilobytes per second downstream, and about three kilobytes per second upstream, at best.
It's difficult to put an exact figure on the bandwidth a given action game needs for a really smooth experience, though. Practically all such games have user-tweakable connection settings, which allow you to tell the game how much bandwidth you reckon you've got. But the network code generally just uses that setting as a ceiling figure, and may actually shift a lot less data around.
If you're playing an FPS game hosted on a distant, high latency server, then even with lots of people playing, you may find you're moving little more than one kilobyte per second upstream, and little more than two downstream, on average, regardless of how fast your connection is. On a server run by your ISP with a minuscule ping time, on the other hand, you may average as much as five times that - and have a much less frustrating game. Generally, you're not likely to move a total of much more than eight kilobytes per second, on average.
Less twitchy games are even less demanding. Massively multiplayer games like Ultima Online and EverQuest average less than a kilobyte per second. Text based Multi User Dungeon (MUD) game clients have upstream bandwidth that's almost negligibly small, with downstream bandwidth generally well under half a kilobyte per second.
A game's bandwidth requirements may have a low average, but that doesn't mean the data flow is steady. There can be brief peaks in any real-time game's data flow, and that's when it's nice to have broadband. Modem connections can't "save up" unused bandwidth, and so they'll suffer lag when the peaks come along.
Which, of course, is usually when the pucker factor is high. Lag when you're just running down an uninhabited corridor isn't a problem, but that's not when it's going to happen.
Some multiplayer games - including most Real Time Strategy (RTS) games - use a peer-to-peer model, in which there's no particular server machine and every computer talks to every other one, with clever algorithms to make sure only data that a client needs to know gets sent to it. This model doesn't scale well, though. As the number of players rises, the complexity of the network rises exponentially.
If you want dozens of players in an action game, you have to have a central server instead. That's how all FPS games work.
Servers need enough bandwidth to deal with the data going to and from all of their clients. That can add up to a pretty serious pipe, if you want more than a few people to be able to play.
When you see a Counter-Strike server with 32 lunatics traffic-jamming their way around de_dust, or, better yet, a Tribes 2 server with 75 people all trying to cram themselves into the pergola-sized flag building on Quagmire, you are not viewing a server that's running on a dial-up link.
If you've got a budget broadband connection with only a 128 kilobit per second upload cap, for instance, that'll only be able to support three or four FPS players, at most. So it doesn't matter much that the Acceptable Use Policy contracts for such cut-rate broadband accounts often forbid you to run a game server; you couldn't run much of a one anyway.
Big fat reliable pipes that are suitable for one or more large game servers are quite expensive pretty much anywhere in the world, and can be quite amazingly expensive here in Australia.
The last time I checked - which, to be fair, was when this page first went up, way back in 2002 - Telstra would fix you up with one of their basic ten megabit per second "Wideband IP" lines for a bit more than $AU20,000 for setup, and more than $AU20,000 annually. A lot more, if you're not close enough to your nearest city. Nowadays many residential customers can get cable, optic fibre or "ADSL2+" broadband accounts with enough upstream speed to run a pretty decent game server, but consumer broadband use policies usually still explicitly or de facto (via bandwidth use restrictions) make it impossible to actually do it. You're usually allowed to run any kind of server you like on a "business" broadband account, and one of those with ADSL2+ speeds and enough bandwidth allowance to run a game server will cost you several hundred dollars a month. That certainly beats $20,000, but it also only buys you enough bandwidth for one mildly popular FPS server.
An alternative to these scarily expensive options for would-be game-hosters is to host the game server on your ISP's premises, and administer it remotely. The dedicated server executables for all of the popular FPSes can be run this way; they can be fiddled with from within the game, or via Telnet and FTP and even HTTP interfaces, like other kinds of Internet server.
Most ISPs are happy to host a few game servers, because they attract customers. A local server gives players the lowest ping times they're ever going to see. And because users playing on an ISP's own servers consume none of the ISP's bandwidth to the rest of the Internet, the cost to the ISP is minimal, and they usually don't count that bandwidth towards account limits.
(Here in Australia, ISP bandwidth limits are usually explicit; you get X many megabytes of download bandwidth per month, and after that you pay extra and/or get throttled to a lower connection speed. In many other countries "unlimited" accounts are more common, but anybody who tries sucking down the full link bandwidth for a month is likely to find that it's not as "unlimited" as it seemed. Personally, I prefer the up-front kind of bandwidth limit; at least then you know where you stand.)
Game modifications can take more bandwidth per player, or less, depending on whether they add more stuff for the servers and clients to keep track of or not.
The original version of Counter-Strike, for instance, used a bit less bandwidth per player than the plain Half-Life deathmatch it was built on, mainly because its "realistic" weapons don't shoot the streams of slow-moving projectiles that infest most FPSes.
On the other hand, mods created by l337 kiddies who think they're the first person to invent a rocket that explodes into 16 grenades that each explode into 24 glowing balls that each shoot out 128 nails that each leave a trail of smoke behind them can require a lot more bandwidth per client.
It's easy to figure out how much bandwidth streaming video takes up - just look at its bit rate. 64 kilobit video or audio has, wait for it, exactly a 64 kilobit per second data rate. That's a bit more than 28 megabytes an hour. 128 or 256 kilobit streams are proportionally more demanding. There may be a bit of transfer overhead, but there shouldn't be much.
Once again, bottlenecks between you and the video server can reduce the data per second you actually get. But if you don't have any such problems, the bandwidth arithmetic is very straightforward.
Voice over IP (VoIP) Internet-telephony software like Skype, including video-phone software, works the same way, but usually has a pretty low data rate. High-quality corporate videoconferencing systems can suck down two megabits per second, but that's for a serious boardroom installation, not a bunch of USB webcams connected to Windows boxes running NetMeeting.
In consumer-gear setups that run over the public Internet, you're likely to have bottleneck problems long before you hit the resolution and frame-rate limits of even an entry-level webcam.
Usenet and e-mail
When you connect to your ISP's Usenet or e-mail server, you're very likely to be able to send and receive data as fast as your connection can handle. With no network hops outside the ISP's own hardware, local servers like these are always very fast, assuming they're not loaded down by lots of users.
Not that this matters much, for e-mail servers at least, or for ordinary text postings to newsgroups. If you're not sending or receiving gigantic attachments, 56K modem bandwidth is fine for e-mail. And text newsgroup message downloads, even over a modem, will still be a very great deal faster than you can read. Text newsgroup bandwidth use is right down there with text chat, which is unlikely to consume more than half a megabyte per hour.
If you're hoovering up big binary postings from Usenet, though, bandwidth matters.
Your, um, copyright-free MP3s of uplifting religious songs and, ah, video clips of fully clothed upstanding citizens doing nothing even slightly naughty, will download spectacularly quickly from a local server, if you've got a good broadband connection.
The MIME64 encoding still used for practically all Usenet binary posts adds a 33% size overhead to everything. But even so, cable Internet users shouldn't have any trouble dumping more than 300 kilobytes per second of decoded data into their download directory.
By using a proxy server or Network Address Translation (NAT) box of some description, you can share one Internet connection across a Local Area Network (LAN). Windows has had its "Internet Connection Sharing" NAT software built in since Win98 SE came out, and there are many other options; I talk about a few of them in the somewhat outdated piece here. Generally speaking, even ISPs that still explicitly forbid Internet sharing by their customers don't care if you do it, as long as you don't end up violating any other data transfer limits they set, or asking them to help with setting up your router.
A shared Internet connection simply aggregates the bandwidth needs of all of the client machines. Some sharing software runs a local proxy that can reduce redundant requests from Web browsing clients, but proxies make no difference for games.
Several people playing games through the one connection create the same bandwidth aggregation problems as running a local server, only less so. If you've got a cheap broadband connection with roughly 16 kilobytes per second of upstream bandwidth, that's what'll limit you. But you still shouldn't have a problem with four or five people playing undemanding games at once.
The Australian Broadband FAQ, with information about the bandwidth available from different services here in Australia.
NetStat Live, which can provide more statistics about your Internet connection than you're likely to want to know.
Design and Implementation of Networked Games, a rather old but nonetheless interesting treatment of what programmers have to do to make multiplayer games work in the real world.