Bandwidth Problem Update

With the release of the Havok 2012.1 update and Pathfinding came an increase in bandwidth used.  In the articles #SL News Week 33 and #SL News Update Week 33 I mention the problem. See JIRA: SVC-8124 – Excessive “ParcelOverlay reliable” messages sent by regions since last rolling restart (2012-08-08). Votes=124 – Watches=90 – 8/24. Resident interest in the JIRA shows it obviously not a big issue, unless you have a bandwidth capped/metered Internet service.

Networx Bandwidth Monitor

The fix for SVC-8124 was added to all 3 release channels to increase the probability that it can roll to the main grid next Tuesday.

I asked Oskar Linden if the Lab has seen an increase in bandwidth used since the PF release and 8124. He says not that he has heard. I suppose that means either it is a small enough problem, for the Lab, that they aren’t talking about it in house or Oskar has had his head down working and not noticed it.

Posts from the JIRA suggest that it makes no difference whether Pathfinding is enabled or not.

Island regions without a diagonal region to the SW do not suffer the problem.

Those testing the problem in the RC regions are seeing considerable improvement or no problem. So, it seems the problem is fixed.

Capped Services

I am surprised that people with capped or metered services don’t monitor their Internet use. Asking some old people about the good o’days of dialup, they remember watching the clock to keep their phone bills down. That seems reasonable to me and makes me wonder what has changed in this generation.

I’m already jaded enough to not trust any company with a blank check. I believe anyone billing me for hours or quantified services is going to be tempted to pad the bill. So, I keep track of what I’m using.


In Week 33’s update I listed a couple of Network Monitors. I’ve been using NetWorx’s monitor to monitor my use.

I’ve also been watching the use graphs as I fly around the grid. I have been to regions where my bandwidth use is high and stays there. But, I have not been able to duplicate the problem in the majority of regions I visited.

My home is on the very south edge of the region. I’m just east of center. The simulator version is Second Life 3.3.4 (262321) Jul 24 2012 04:02:05 (Second Life Release). My average BW in the area is 15 to 45 kbps. Even standing in the SW corner looking south and southwest it doesn’t change. So, from my perspective the problem has not been pervasive.

It helps that the region to the south of me is basically empty. I can TP from the south region into my home and hang the BW at about 600kbps. It will stay high until I start walking around then drop back to 15-45 kbps.


I find that Networx’s measurements and the viewer’s Viewer Statistics panel do not give me the same readings. When my Viewer Stats are showing bandwidth (BW) in the 600k/sec rate Networx is showing about 100k/sec.

The amount of difference varies, but Networx is always less by a significant amount, about 1/6th. When I asked Oskar about the difference he was not sure what it is the Viewer Stats BW is actually measuring.


The problem is getting resolved and the Lab has rushed the fix through QA, as much as possible, to get it out. In week 35 we should see the problem resolve.

4 thoughts on “Bandwidth Problem Update

  1. The difference you are seeing is undoubtedly 1/8 (or 8x). kilo bits (b) / second vs. kilo Bytes (B) / second. It got me too at first. I use BioMeterOS when I feel the need to monitor bandwidth.

    I would not go so far as to say fixed! There seems to be more than one problem.

    From Brocade, the problem in the SW corner (LeTigre diagonal), which was more dramatic and easier to define, is fixed. The similar problem in the SE corner (Magnum diagonal), which is harder to pin down, is not fixed.

    • That is a good point, bytes and bits. I did some checking to see if there is some consensus on whether kbps is bits or bytes. The majority of definitions I looked at are bits. So, the 8x or 12% factor is logical. But, usage is ambiguous.

      There is also a compression issue. The HTTP 1.1 (RFC 2616) protocol is capable of on-the-fly compression, which can affect the quantity of bits coming through the network card.

  2. The bandwidth shown in the viewer statistics floater is in fact the viewer messages bandwidth: it doesn’t include the HTTP services bandwidth (i.e. anything that is exchanged via “capabilities”, HTTP textures and inventory, etc). The ParcelOverlay message is an UDP viewer message and the spamming of such messages does show into the stats floater bandwidth.

    There are however other spamming issues (such as spurious and repetitive disconnection/reconnection of neighboring regions when flying/standing in a sky box and at certain draw distance level (I too reported this problem in a JIRA issue, but it seems to have been since moved to a MAINT issue that is no more public…); such spam won’t show in the viewer bandwidth indicator (but it shows in the viewer log).

  3. Keep in mind that using tools that monitor bandwidth use between your home and the Internet don’t show additional overhead that might be applied to your traffic once it leaves your modem and hits your ISP’s network. Once your IP traffic enters your ISP’s network, it can wind up encapsulated in other low level protocols or get massaged in other ways; in effect, each packet of information becomes a little fatter. On a single packet basis, this additional overhead is pretty small, but over the course of a month it can add up to unexpected megabytes of data.

    I really do recommend that people use these sorts of tools, especially if you have a usage cap. But be prepared to start limiting your use before you get too close to your cap. And don’t be surprised if your ISP says you used a little more than your tools say you did. Your ISP probably isn’t lieing to you… they can simply see things your tools cannot. On the other hand, if the discrepancy seems really, really large, you may have cause to complain, and your tools give you records on which to base your complaint.

Leave a Reply

Your email address will not be published. Required fields are marked *