This article originally appeared in TidBITS on 2012-07-23 at 2:54 p.m.
The permanent URL for this article is: http://tidbits.com/article/13089
Include images: Off

Small Pipes and High Bills: Keeping Bandwidth Use in Check

by Glenn Fleishman

Our computers chat all day long with Internet servers near and far, and we can usually remain blissfully unaware of how much data they send and receive, so long as we’re using a high-speed Internet connection. This is a relatively recent development — it wasn’t all that long ago that we relied on 56 Kbps (or slower!) modems for our Internet connectivity, meaning our computers had to assume that Internet connectivity was both intermittent and constrained. With broadband Internet connections, computer makers first made the transition to assuming always-on connectivity, and in the past decade those assumptions have evolved into software and services expecting an always-big bandwidth pipe.

But those assumptions aren’t always true even now, because the more mobile we become, the more likely we find are to ourselves in places in which we either have too little bandwidth available or are paying too much for the bandwidth our computers want to consume. An automated backup agent, a sync service program, background email checking, and even Apple’s automatic software updates could leave us frustrated by network performance or shocked by a too-large bill.

Limited bandwidth situations are also becoming a tragedy of the commons, where a small number of people can ruin it for everyone else. Public Wi-Fi networks, whether in hotels, at conference centers, in coffee shops, or on an airplane or cruise ship, are increasingly becoming less reliable to use, thanks in part to heavier use of video and the large number of smartphones and iPads. Amtrak even warns users of this problem with their “continuous” Wi-Fi service, as I found while working on this article during a train trip between Seattle and Portland.

[image link] [1]

But our computers are also to blame, due to software assuming it has an always-available, high-speed Internet connection. The hotel Wi-Fi that used to be sufficient for checking email and editing files in Google Docs now struggles with even such low-bandwidth tasks, thanks to all the other people watching Netflix, backing up via CrashPlan, and synchronizing files via Dropbox. These scenarios aren’t hypothetical — Adam Engst found his hotel Internet connectivity too slow to use at times during Macworld | iWorld in January 2012, and Joe Kissell experienced huge frustration when sharing on-ship Wi-Fi during a recent MacMania river cruise (the Internet connection in the latter case came from multiple bonded 3G cellular data connections). The CSS guru Eric Meyer told me about a 50 Mbps connection used at his An Event Apart design conference being accidentally hogged [2] by a speaker’s corporate backup software kicking in.

And while you can sometimes carve out sufficient bandwidth for your needs by switching to a mobile broadband connection and tethering your computer, usage limits on mobile broadband mean that you have to start counting bytes. In the United States, cellular providers now typically levy surcharges when you exceed a fixed amount of data in a plan, whether 300 MB, 2 GB or 10 GB. In many other countries, instead of charging overage fees, mobile carriers throttle accounts to between 64 and 256 Kbps after a threshold is reached.

(I won’t be discussing a related situation, which is how to deal with permanently low-bandwidth scenarios, whether in the American hinterlands where dial-up modem or low-speed satellite are the only options, or in developing nations in which expensive low-speed cellular connections or dial-up modems over pricey landlines are all that are available. If there’s interest, we’ll look into a separate article about that topic in the future.)

In the rest of this article, I’ll explain how, when you find yourself in one of these low-bandwidth or high-price situations, you can figure out which applications are blindly consuming bandwidth and then throttle, pause, or quit them. Then I’ll share some thoughts about a proposed utility that could help us automatically reduce our bandwidth use when desired.

Find and Track the Talkers -- The main obstacle I ran across in researching this topic was determining how best to figure out which of the many daemons, background applications, and Apple components transfer more than a handful of kilobytes per day. The obvious culprits were easily found, but a real-world Mac OS X system is full of software that fires up as needed in the background, and that’s easily overlooked. Tools for ferreting out such software abound, but none is perfect.

You can use Mac OS X’s Activity Monitor (found in /Applications/Utilities) to see bandwidth consumption as it happens. After launching, click the Network button at bottom right and watch the red and green lines on the graph. But the graph doesn’t tell you what program is burning up the wire, just that transfers are happening.

[image link] [3]

The $34.95 traffic monitoring utility Little Snitch [4], which I advise the use of later as one way to catch and halt unwanted usage, has an attractive network monitoring display that shows consumed bandwidth over time and lets you drill down to usage by program and domains accessed by that program. But there’s no additional information you can extract. You can watch the tool to see which apps are being chatty (for the previous 60 minutes only) or review the overall usage later, but not get details that might help shape the rules you set in it.

[image link] [5]

The best solution to this problem that we’ve found so far is Conceited Software’s Rubbernet [6], a €29.99 (roughly US$37) Mac OS X program with a 15-day free trial.

While Rubbernet is running, it summarizes all the traffic (sent and received) by every application, showing you the app name, whether or not it’s active, which user the app belongs to, the download and upload rates, the total data in and out, and the time of the last activity. Double-clicking an active app (or clicking it in the sidebar), shows you the remote host names, port used, user, download and upload rate, and last activity.

[image link] [7]

The Summary window is useful for identifying when significant amounts of data are being transferred, and then you can go to an app’s detail view to try to figure out what’s happening (by examining the remote host and port columns). This works well for bandwidth-intensive apps that are relatively obvious, like SkyDrive or Transmit. (A tip: Rubbernet’s “System” category includes a whole bunch of unrelated things — we found that it even included RSS checking in Safari, which explained some otherwise inscrutable domains that were being pinged regularly.)

[image link] [8]

What Rubbernet doesn’t offer, though, is a historical view of this data, which disappears when the Mac sleeps or is restarted. That can make it tricky to understand certain events if you were otherwise occupied at the time. Rubbernet also omits past data consumption for inactive programs, making detailed analysis even harder. We’d like to see a future version of Rubbernet add the capability to maintain data for longer, and alert the user when certain transfer rates are exceeded, so you could investigate bandwidth use while it’s happening, rather than just seeing later that it did happen.

If running a network monitoring utility is more effort than you’re willing to invest, you can still make some suppositions about what types of software will transfer non-trivial amounts of data. Once you’ve identified possible culprits, you can then throttle, pause, or quit them, as described later. The main types of software to watch out for are:

Once you’ve identified the software on your Mac that’s likely to transfer significant amounts of data, you can figure out some ways that you can limit bandwidth usage whenever you’re in a situation where unbridled transfers would be inappropriate.

Throttle, Pause, or Quit -- Some applications that use data continuously may be throttled to reduce bandwidth usage, paused for a period of time or until you resume manually, or simply quit to prevent their activity entirely.

Throttling is the least extreme of the bandwidth-limiting solutions — when an app allows throttling, it lets you restrict its bandwidth usage. Throttling is best when you have an app that can do some useful work with limited bandwidth but which might try to consume significant bandwidth if not throttled. We’re aware of only two popular apps that offer throttling: Dropbox and CrashPlan.

[image link] [11]

Some less-common applications include such a feature as well. SpiderOak lets you limit the upload rate to a user-defined number of kilobytes per second; Dolly Drive lets you set a slider that represents a percentage of available bandwidth; and SugarSync offers a similar slider labeled Low, Medium, and High. (The new Google Drive and updated Microsoft SkyDrive lack throttling.)

If throttling isn’t available, you might be able to pause the application’s data transfer activities entirely. Pausing is often more useful than throttling because then you know the app won’t be using any bandwidth at all. Be careful, though, since it’s easy to pause software while travelling, for instance, and then forget to re-enable it once you’re back home. (Adam caused some version control confusion by pausing Dropbox during January’s trip to Macworld | iWorld and forgetting to turn it back on later, thus working on what turned out to be an older version of a shared file.) Many network-intensive applications include a pause feature as a menu item or button in the interface; here’s how to pause Dropbox and CrashPlan and various other types of programs:

[image link] [15]

Finally, for a good deal of software, quitting or disabling its network functionality is the only way to stop it from chattering incessantly. That can be tricky if the software doesn’t have standard menus with a Quit command, or at least an icon that appears in the Dock. If that’s not the case, try these approaches:

As an alternative to quitting a particular program, you could also consider using Little Snitch to block its capability to communicate with the Internet. Starting with version 3 (available now in a preview release), Little Snitch lets you create and switch between profiles. You could, therefore, create a low-bandwidth profile in which no network traffic is allowed except for a few things you define, such as Web browsing via port 80 for http or 443 for https.

While using Little Snitch to block network traffic in a low-bandwidth situation isn’t the best use of an application firewall, it can be effective. Be aware that hobbling some applications in this way may cause them to throw up alerts repeatedly to tell you they can’t connect to the Internet.

Wishing for a Data Transfer Management Utility -- It wouldn’t be that hard for a developer to write software to help users manage their bandwidth usage. (Apple could do so as well, but the fact that we don’t see such capabilities built into Mac OS X suggests that Apple isn’t interested.) What we need is a piece of software that combines monitoring, notification, and firewall capabilities. Such software should:

We’re happy to talk more with anyone who’s interested in writing such a utility, but in the meantime, developers of network-intensive applications should give more thought to notifying users of significant bandwidth use, providing throttling capabilities, and — at minimum — making it easy to pause and resume the software. Without such awareness and control, it’s all too easy for a small number of users to ruin shared public bandwidth for many others, and even for individuals with tethered computers on mobile broadband to suffer from lousy network performance.

[1]: http://tidbits.com/resources/2012-07/low-bw-amtrak-message.png
[2]: http://economist.com/blogs/babbage/2012/04/bandwidth-use
[3]: http://tidbits.com/resources/2012-07/Activity-Monitor-Network-tab.png
[4]: http://www.obdev.at/products/littlesnitch/
[5]: http://tidbits.com/resources/2012-07/Little-Snitch-Network-Monitor.png
[6]: http://rubbernetapp.com/
[7]: http://tidbits.com/resources/2012-07/Rubbernet-Summary.png
[8]: http://tidbits.com/resources/2012-07/Rubbernet-Google-Chrome.png
[9]: http://support.google.com/installer/bin/answer.py?hl=en&ctx=go&answer=147176
[10]: http://tidbits.com/resources/2012-07/Dropbox-throttle-settings.png
[11]: http://tidbits.com/resources/2012-07/CrashPlan-throttle-settings.png
[12]: http://tidbits.com/resources/2012-07/Dropbox-Pause.png
[13]: http://tidbits.com/resources/2012-07/CrashPlan-Pause.png
[14]: http://tidbits.com/resources/2012-07/CrashPlan-Network-limits.png
[15]: http://tidbits.com/resources/2012-07/low-bw-photostream-off.png
[16]: http://tidbits.com/resources/2012-07/Software-Update-check-automatically.png
[17]: http://support.google.com/installer/bin/answer.py?hl=en&ctx=go&answer=147176
[18]: http://oomphalot.com/sidekick/
[19]: http://www.controlplaneapp.com/about/