wildblue rolling blackout theory

Melissa and I are currently using Wildblue satellite internet service. Overall, I find it to be a very good alternative to dialup. I get excellent bandwidth and about an 800ms average ping, with no special client-side hardware. Best of all, it’s no more expensive than DSL or Cable internet.

The bad side is that over the last month, I’ve been getting disconnected 1-3 times per night. It’s really kind of out of control. I have a theory about why it’s happening though. Obviously, skip this post if you’re not a geek.


  • Outages can occur with the connection light on the satellite modem (2nd LED from the top) either on or off. Usually the light is still on when an outage occurs, but both do occur.
  • Waiting sometimes restores service with no intervention from myself.
  • Resetting the modem *always* restores service, immediately. (thus, while it could be a problem with my modem, it is at least not a permanent hardware failure of any sort)
  • My router is not at fault. I have stopped resetting my router during outages and now only reset the modem. Resetting the modem itself (but not the router) fully restores service each time I have tried it that way (perhaps the last 8-10 outages).
  • Wildblue is reducing the bandwidth allowances in their FAP by 25% as of today. (the Fair Access Policy is the document that governs the amount of bandwidth you are allowed to consume per 30 day period, based on which tier of service you purchase)
  • Technical support is not at all helpful with these outages, but simply walks me through a modem/router reset. (ie, instead of addressing the cause of the outage, the symptoms are merely addressed) They always manage to spend 20-30 minutes of my time doing this, but never manage to realize that I’ve already been through this with them many times before.

Based on these observations, my conclusion is fairly obvious. The reduction of the FAP tells me that wildblue’s current infrastructure is not capable of managing the load that their customer base places upon it. Just as electricity providers do in the event of a shortage, they seem to have implemented “rolling blackouts” of a sort, disconnecting clients for random amounts of time to artificially reduce load on the system.

While this is just an educated guess on my part, I feel that it’s a reasonable conclusion to draw from the facts available to me. What do you think?

  1. I highly doubt they are doing anything as sophisticated as randomly disconnecting users.

    You get disconnected 1-3 times per “night”.
    The connection light is sometimes on or off.
    Waiting sometimes restored service.

    I think the most probably cause is that your reciever’s PLL is losing sync with the carrier as the atomospheric effects change during evening. Eventually it locks back in on the signal as it walks back, assuming it has the ability to do so. Resetting it of course forces the reciever back to the standard frequency and locks in fine.

    The symptoms you described are exactly the same as the ones I had with my cable modem, prior to the guy coming out and discovering they had an old rusty splitter in the wiring cabinet.

  2. Well, your theory holds water as well Bryan. Not nearly as conspiracy driven… But still makes sense. (:

  3. Ready for some wild speculation?

    I’d guess the atmosphere is partly responsible. Broadband satellites are placed in geostationary orbit around the equator, a couple of degrees apart. Your home dish is oriented towards one of those satellites when connected.

    Wildblue operates around 30 GHz (according to the trustworthy google search for wildblue frequency), and that frequency is quite subject to signal attenuation due to atmospheric conditions, as well as highly directional.

    If you happen to be the unfortunate recipient of some weather in between your home dish and the space dish, there’s 4 things that could happen to your signal. 1) Only the signal from your home to space (H2S) gets blocked, but the space to home (S2H) signal is clear, 2) vice versa, 3) both directions blocked, or 4) nothing.

    I would guess that the home dish’s “bootup” sequence goes something like this: First, calculate direction to nearest satellite. Then, attempt to handshake with this satellite. If that works, great, if not, calculate next nearest satellite and try again. The point it that during the bootup, it handshakes with the satellite to ensure a connection. While connected, there is no need to handshake because we already know we have a connection.

    In case 1, the connection is interrupted. The S2H signal comes through, and the home dish thinks it’s connected because it gets this signal. Since it thinks it’s connected, it keeps sending packets to the same satellite. Those packets never get there, but the modem is none the wiser. Constant checking would take effort (and nontrivial bandwidth), so it sure ain’t gonna do that. Connection light remains on. On modem reset, it goes through the initialization procedure and fails the handshake, then keeps picking new satellites until the handshake succeeds, and the connection is live again. It may pick a new satellite for the handshake or just boost its own broadcasting power until the handshake succeeds.

    In case 2, the connection is interrupted, but this time the home dish knows about it. If it’s not getting a signal from the satellite, the satellite has to boost its transmit power or the home dish has to point to a different satellite. It’s cheaper for the home dish to reorient, so it does. The connection drops long enough for the dish to handshake with a different satellite. Connection light is off. I suppose the other thing that could happen is your dish could ignore the connection drop and do nothing (hope the interruption goes away) until modem reset.

    In case 3, case 1 or 2 would happen first, and if not, the same action(s) would take place.

    In case 4 you’re a happy broadband subscriber.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>