Small Pipes and High Bills: Keeping Bandwidth Use in Check

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.

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 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.

The $34.95 traffic monitoring utility Little Snitch, 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.

The best solution to this problem that we’ve found so far is Conceited Software’s Rubbernet, 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.

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.)

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:

• Cloud-based synchronization services like Box, Dropbox, Google Drive, SkyDrive, and many others run in the background and constantly keep files up to date. If you’re sharing folders with collaborators, any changes they make will be pushed to your computer directly as well, which means that you could be bringing in significant quantities of data even when you’re not sitting at your Mac.

• Internet backup services like Backblaze, Carbonite, CloudPull, CrashPlan, Dolly Drive, Mozy, SpiderOak, and many others also run in the background, copying your changed files out to the cloud. Backup services may run on a schedule rather than continuously, making them a bit more predictable than synchronization services, but if you’ve made substantial changes, downloaded large files, imported photos or videos from a camera, or anything else that creates or changes lots of data, you will likely see spikes in usage.

• Apple software updates can be an unpredictable source of significant data transfers. In the Software Update pane of System Preferences, you can set your system to download updates automatically whenever they’re available. While many of these updates are small, updates to Mac OS X and some of Apple’s applications can be in the 500 MB to 1 GB range. Software Update provides no indication that these downloads are happening until the Software Update application notifies you that updates are ready to be installed.

• Various uses of iCloud can consume significant Internet bandwidth, perhaps without you realizing. For instance, Photo Stream in iPhoto could start downloading newly taken photos at any time. If you use iTunes Match and you play a song that isn’t stored locally, iTunes will stream it from iCloud in the background. Or, if you purchase content from the iTunes Store or the Mac App Store, that content may be downloaded automatically to multiple devices without any further interaction from you. As more programs start relying on iCloud for synchronization of files, we could start seeing non-trivial bandwidth usage occurring in the background as iCloud keeps all our devices in sync.

• Google, because the company thinks in terms of Web-based applications, has set most, if not all, of its desktop applications to update automatically in the background. This prevents the user from having to think about updates, and protects users against bugs and security holes, but could prove troublesome if an update starts downloading while you’re in a low-bandwidth situation. Controlling when — and how often — Google Software Update checks for and downloads updates requires working in Terminal.

• Some applications, such as Google Chrome and Firefox, can update themselves automatically, downloading a new version when you launch the app.

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.

• Dropbox: From the Dropbox menu, choose Preferences, click Network, and then click the Change Settings button for Bandwidth. You can limit upload and download rates separately.




• CrashPlan: In the CrashPlan app’s Settings screen, click the Network button. You can set rates in the Limit Sending Rate pop-up menus for the WAN (the remote connection to your own or peer backups or to CrashPlan Central). There’s little reason to limit LAN rates on most modern Wi-Fi or Ethernet networks.

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:

• Dropbox: From the Dropbox menu, choose Pause Syncing. You’ll notice that the little green badge that indicates that Dropbox is fully synced disappears. To start syncing again later, choose Resume Syncing.




• CrashPlan: To pause CrashPlan, you must enable the system-wide CrashPlan menu bar icon (click Launch in the CrashPlan app’s Settings screen) and then choose an amount of time to pause from the Pause submenu. If you want to start backing up again before the time elapses, choose Resume from the same menu. You can also run the CrashPlan app, double-click the house icon in the upper right corner to show CrashPlan’s Command window, and then type pause; entering resume restarts backups.

  
  

  CrashPlan can also be set to work only on selected Wi-Fi networks, pausing otherwise: in the Settings screen, click the Network button, then the Configure button to the right of Wireless Networks. Select the checkbox next to the networks over which you want CrashPlan to work. Every new network to which you connect is automatically enabled, so you’ll want to come in here to disable low-bandwidth networks.




• Email programs: Many email programs let you go offline or disable automatic checking through a menu item or a checkbox. You can opt for that, or, as is also common in many programs, set a maximum download file size threshold beyond which only the first part of a message is retrieved as a preview (an option with POP accounts) or just the message part without attachments (with IMAP accounts).

• iCloud: For iCloud, Apple offers only a binary control with a major flaw that we hoped would be rectified in Mountain Lion (it’s not). You can disable iCloud services, like Photo Stream, Documents & Data, and Contacts, but Mac OS X will (with a warning before you proceed to turn the service off) delete the local copy of everything. For Photo Stream, it deletes all the photos in iPhoto that weren’t imported. For the others, your data is washed clean from the Mac, but can be synced again if you re-enable. Logging out of iCloud is even worse: it deletes all synced content on your computer.

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:

• A lot of applications that work primarily in the background provide a system-wide menu in the menu bar. Most such applications offer a Quit command, but it’s worth verifying in Activity Monitor that you can actually quit the background process that’s transferring data, and not just a companion application that provides the menu. If you don’t see a Quit command, try holding down Option before clicking the app’s menu bar icon to see if the menu reveals one.

• Check System Preferences for a preference pane for the app that might contain otherwise non-obvious controls to stop, pause, or quit the service. Some applications may also install companion apps in the Applications folder for such purposes.

• For Apple’s Software Update, open the System Preferences pane and uncheck the option to Download Updates Automatically.




• Keep browsers from updating. Google Chrome will try to update itself in the background unless you restrict it via Google Software Update. Firefox may be set to auto-update as well; you can turn off its automatic updates in Firefox > Preferences > Advanced > Update.

• Twitter clients now typically use Twitter’s streaming feed, which continuously polls and updates content. Although the overall bandwidth burden may be low, it could add up over time. Quit your Twitter client to ensure that it’s not consuming bandwidth.

• As a last-ditch effort, look at the processes in Activity Monitor and quit any that you think might be transferring a lot of data. This is a brute force approach, and shouldn’t be used routinely because it could corrupt data, produce unexpected behaviors, or cause general instability. Plus, such daemons tend to restart themselves automatically, so quitting them manually is seldom successful for long.

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:

• Track bandwidth usage by protocol and application to help you discover which programs are transferring significant quantities of data.

• Provide warnings when data transfers approach or exceed preset values, either via alert dialogs, Growl, or Mountain Lion’s notifications.

• Offer bandwidth throttling controls that could apply globally, or just to specific applications.

• Let you create and switch between profiles that either automatically (as with Sidekick and Control Plane) or manually (as with Little Snitch 3, noted above) change the throttling controls to match a location, or any time you’re not in a particular location.

• Provide a central kill switch for blocking all incoming and outgoing network connections without having to resort to the Network preference pane or turning off the AirPort adapter.

• Automatically test the current connection to be able to report on the available bandwidth and potentially throttle apps dynamically in response to network conditions. (This is a more advanced feature, but would be welcome.)

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.