Virgin Broadband Update

Following on from my last post about Virgin Broadband and their traffic management, I came to a realisation. I phoned them up and asked about the current usage for our account over the last few weeks or so. They gave me this data:

Daily Downstream Total:
Period Total (GB)
26/03/2011 0.432 GB
27/03/2011 0.362 GB
28/03/2011 0.748 GB

17/04/2011 0.591 GB
18/04/2011 0.863 GB
20/04/2011 9.496 GB
21/04/2011 9.912 GB

What is apparent is that around about the 18th of April, our usage dramatically increased. I couldn’t account for this usage in general browsing terms, especially as we were away for a few days over that period. Thinking back, I looked over the iperf commands I was using to measure the bandwidth. On the client side, I was running this command every ten minutes:

iperf -c www.example.com -P 4 -f k -w 256k -t 60

This was using a TCP window of 256k, a transmit window of 60 seconds and four threads in parallel (-P 4). The net result of this is that I was sending 70MB of data from the client to the server six times an hour. Multiply this by 24, and you get a number very close to 10GB (which is what Virgin indicated we were downloading). So, after a bit of reading, I changed the client iperf options:

iperf -c www.example.com -P 1 -f k -t 5 -x CMSV

Now, I only have one thread running for five seconds with a default TCP window length and a single thread. The addition of -x CMSV reduces the output from iperf and means I don’t have to grep SUM to get the relevant line. Furthermore, I think a 10 minute sampling frequency is a little on the high side, so I changed the cronjob to only run the iperf script every half an hour, which should still give the granularity I wanted.

Of note is that with a smaller TCP window and a shorter transmit time, the results are slightly more erratic. They are, however, still showing the same pattern as before.

So, it seems Virgin were correctly measuring our downloads and managing our traffic accordingly. What caused the initial slow-down that prompted me to measure the bandwidth remains a mystery.

Bandwidth with Virgin Cable Broadband

We recently switched from o2’s ADSL to Virgin’s cable broadband. I knew that Virgin did traffic management, but I hadn’t really paid it much attention. However, after one evening of particularly slow (think 56k modem-slow) internet, I decided to look into it a bit more.

Stumbling my way through the internet, I came across a tool called iperf. Given two Linux computers, it would tell you the network speed between those two computers. I installed iperf on my Slackware server from SlackBuilds.org and compiled a copy at work on a Red Hat 5 machine. I know that the connection at work is much much faster than my home one, so I was confident I’d be measuring the bandwidth as limited by my home connection rather than by work’s connection.

On the server, I launched the following command:

iperf -s -f k

By default, iperf runs on port 5001, so I opened the appropriate port on the Virgin Media Hub (a NETGEAR VMDG280 Wireless ‘N’ Cable Gateway modem and wireless router combo).

This starts the server (-s) and outputs results in kilobits per second (-f k). On the client at work, I wrote a little bash script (beware line-wrapping):

#!/bin/bash
OUT=$(iperf -c www.example.com -P 4 -f k -w 256k -t 60 | grep SUM)

DATE=$(date +%Y%m%dT%H%M%S)

printf “$DATE ” >> $HOME/logs/bw.log

echo “$OUT” >> $HOME/logs/bw.log

(I’ve replaced my home IP with www.example.com, obviously).This little script saves the output of iperf in $OUT. The switches do the following:
-c – client mode
-P 4 – runs four parallel client threads
-f k – outputs in kilobits per second
-w 256kย – sets the TCP window size to 256k
-t 60ย – sets a sixty second transmit window
The line of interest for the iperf output is the SUM line, so I grep for that to save the results in $OUT.ย The rest of the script just saves the result with a timestamp to a log file.
I run this in cron every ten minutes on the client:

*/10 * * * * $HOME/scripts/bw.sh

To graph the results, I use the Generic Mapping Tools (GMT) package (SlackBuild available here) to plot the results. Figure 1 shows the analysis for the last two days or so:
bw
Figure 1: Bandwidth at home for a 40 hour period. Visible is the 75% bandwidth reduction from 1900 to 0000 on the 19th April.
Since I can now see exactly what the bandwidth at home is every 10 minutes, I decided to try and find out how exactly Virgin were limiting the speed. Some deft searching revealed this page, which outlines their traffic management policy. N.B. this is for areas which have received the upstream upgrade, for those that haven’t, this is the appropriate page.
Although the table is a bit opaque, it can be summarised as follows for the Large bundle:
  • Between 1000 and 1500, downloads must not exceed 3GB (600MB/hr)
  • Between 1600 and 2100, downloads must not exceed 1.5GB (300MB/hr)
  • Between 1500 and 2000, uploads must not exceed 1.5GB (300MB/hr)
The rest of the time, any amount of traffic is permitted, and no traffic management will be imposed. Traffic management is a 75% reduction in connection speed (from 10 megabits per second to 2.5 megabits per second in our case) for 5 hours. Interestingly, from 1500 every day, you get one hour to download as much as you like, and it won’t count towards your total for traffic management.

Comparing the bandwidth in Figure 1 and this traffic management information, we were traffic managed on the 19th April between 1900 and midnight. However, I have to say, you get what you pay for the rest of the time: Virgin’s Large bundle (10 megabit line) really is very close to 10 megabits per second most of the time (generally around 9.8 megbits per second).

I do have a script running which backs up my server to my computer at work (when it’s on), but it does incremental backups, and those are scheduled to run at 0440 i.e. in the middle of the night, when there’s no limit on traffic.

Between 1500 and 2100 I don’t consider us to be a particularly vociferous household when it comes to consumption of material online, yet we still fall into the “very small proportion of customers who are downloading and/or uploading an unusually high amount“. There’s only two of us, and we don’t watch iPlayer very often. We might watch a video every now and then online, but we’re certainly not downloading 600MB of content every hour for five hours straight.