Introduction

WildBlue is a two-way satellite broadband internet service; an alternative to cable, cellular, DSL, or dial-up. Performance is considerably less than cable but significantly greater than dial-up. Bandwidth is approximately the same as DSL or Clearwire, but latency is much greater. Various performance packages are available; the Pro package gives 1.5 Mbit/s download and 250 kbit/s upload speeds.

The major disadvantage of WildBlue is that performance is not stellar. In particular, since every request and response involves a round-trip to a satellite some 35,000 km (about 22,000 miles) above the earth, those four trips add half a second of latency (simply due to the speed of light). The result is that interactive internet use, including most web browsing and telnet, requires patience.

Another concern is that because the satellite(s) are a shared resource, the total amount of data one can download and upload per month is metered and hard-limited.

The major advantage of WildBlue is that it is available over a wide geographical area, including locations that are not currently served by cable, DSL, or even dial-up. For these locations WildBlue is a tremendous gift.

Another feature is that because the WildBlue dish is powered only from the modem/router and communicates directly through a geosynchronous satellite, WildBlue-based internet access is totally immune from all forms of local or regional outage; including wind storms, fallen trees, power failures, Telco office shutdowns, earthquakes, backhoe operators, etc. The WildBlue modem requires only about 25 W of power so solar, generator, or UPS backup for the modem is simple.

Anyway, below are a set of live measurements I've been making: on bandwidth, and on capacity. The plots were last updated:

Monitoring WildBlue Performance

Receive (KB/s, download):

Transmit (KB/s, upload):

Notes:

• Performance for the most recent ten days is shown.
• Plot scale is KiloBytes/second (multiply by about 8 for kilobits/second).
• Measurements are made by timing an FTP upload, then download, of a single 1 MB binary file.
• A fresh measurement is made every few hours (e.g., one test every 2 hours gives 12 data points per day).
• The tests are automatically run from an idle Windows XP PC, hardwire connected to the router.
• The date/times on the plots are UTC (Pacific Standard local time is UTC-8h, PDT is UTC-7h).
• Missing data points occur if the PC crashes, the script fails, the connection hangs, etc.

The goals of this experiment are 1) to see if our WildBlue internet subscription is working correctly and 2) to get a feel for performance, reliability, and consistency. In particular, to see if there are significant variations by time-of-day, or to detect degradations due to weather.

Conclusions:

• The expected WildBlue Pro maximum speed is something like: 1.5 Mbit/sec (~180 KB/s) download; 250 kbit/sec (~30 KB/s) upload. And we do see this level of performance, so it looks like everything is OK with the installation.
• There does seem to be a periodic pattern of degraded performance: for an hour or two around 6 PM local time, download performance drops significantly, sometimes by as much as half. I suspect this reveals peak usage time by WildBlue customers sharing finite satellite bandwidth.
• Service has been continuous, with the exception of several hours one day in late March when a couple of inches of snow fell. I suspect it was accumulated snow on the dish that cause the problem, not the fact that it was raining or snowing. Next time, a webcam on the dish would confirm that hunch.
• FTP reliability has been poor. I can't figure this out yet, but several times a day recently the FTP session will terminate before or during the file transfers. It's not the PC (it happens on a laptop as well).

Monitoring WildBlue Usage

In addition to limiting transmit/receive bandwidth (speed), a WildBlue subscription also limits the total number of bytes (volume) -- averaged over a 30-day interval. There are separate limits for download and upload. It would be nice, then, if near real-time bandwidth and link usage data (packets and total bytes) were available from WildBlue.net or from inside the satellite modem itself; sort of like an electric watt (power) or the spinning kilowatthour (energy) utility meter on the side of the house.

This satellite internet link is a limited shared resource and the only way to conserve it, maximize its usage, and avoid accidental overuse is to be able to closely monitor and track its usage. It seems possible, for example, that a 1.5 Mbit/sec download left unchecked would consume an entire month's quota (17 GB) in just over a single day!

The WildBlue partnerpage.google.com/wildblue.net gadget gives only a rounded percent value averaged over 30 days and is not updated in realtime. By the time you find out there's a problem, it might be too late. Precise usage data on demand would be more helpful for monitoring or proactive throttling. If anyone has suggestions on implementing active WildBlue modem monitoring, or router monitoring (I have a SNMP-capable switch on order), please let me know.

Another solution is the usage_gadget_xml.jsp query which returns upload/download used/limit XML-formatted data in MB units. Although not updated in realtime, these usage numbers sometimes increment within 15 minutes, which is responsive enough that this could be the basis of active usage monitoring. The graphs below are updated about once an hour:

Download (megabytes, 30-day average):

Upload (megabytes, 30-day average):

Conclusions:

• We hope we don't prematurely run into the download/upload limits.
• After one month the above two usage plots will look more interesting.
• The ~500 MB per day limits seem adaquate given our current usage but we really have to be careful.