{"id":19,"date":"2011-04-20T13:28:00","date_gmt":"2011-04-20T13:28:00","guid":{"rendered":"http:\/\/cazenave.co.uk\/wp\/?p=19"},"modified":"2014-04-30T17:22:11","modified_gmt":"2014-04-30T17:22:11","slug":"bandwidth-with-virgin-cable-broadband","status":"publish","type":"post","link":"https:\/\/cazenave.co.uk\/bandwidth-with-virgin-cable-broadband\/","title":{"rendered":"Bandwidth with Virgin Cable Broadband"},"content":{"rendered":"

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.<\/p>\n

Stumbling my way through the internet, I came across a tool called iperf<\/a>. 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.<\/p>\n

On the server, I launched the following command:<\/p>\n

iperf -s -f k<\/span><\/p><\/blockquote>\n

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

This starts the server (<\/span>-s<\/span>) and outputs results in kilobits per second (<\/span>-f k<\/span>). On the client at work, I wro<\/span>te a little bash script (beware line-wrapping):<\/p>\n

#!\/bin\/bash
\nOUT=$(iperf -c www.example.com -P 4 -f k -w 256k -t 60 | grep SUM)<\/p>\n

DATE=$(date +%Y%m%dT%H%M%S)<\/p>\n

printf “$DATE ” >> $HOME\/logs\/bw.log<\/p>\n

echo “$OUT” >> $HOME\/logs\/bw.log<\/p><\/blockquote>\n

(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:<\/div>\n
<\/div>\n
\n
-c<\/span> – client mode<\/div>\n
-P 4<\/span> – runs four parallel client threads<\/div>\n
-f k<\/span> – outputs in kilobits per second<\/div>\n
-w 256k<\/span>\u00a0– sets the TCP window size to 256k<\/div>\n
-t 60<\/span>\u00a0– sets a sixty second transmit window<\/div>\n
<\/div>\n
The line of interest for the iperf output is the SUM line, so I grep for that to save the results in $OUT.\u00a0The rest of the script just saves the result with a timestamp to a log file.<\/div>\n
<\/div>\n
I run this in cron every ten minutes on the client:<\/div>\n

*\/10 * * * * $HOME\/scripts\/bw.sh<\/span><\/p><\/blockquote>\n

To graph the results, I use the Generic Mapping Tools<\/a> (GMT) package (SlackBuild available here<\/a>) to plot the results. Figure 1 shows the analysis for the last two days or so:<\/div>\n
\n
\"bw\"<\/a>
Figure 1: Bandwidth at home for a 40 hour period. Visible is the 75% bandwidth reduction from 1900 to 0000 on the 19th April.<\/figcaption><\/figure>\n<\/div>\n
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<\/a>, 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<\/a>.<\/div>\n
<\/div>\n
Although the table is a bit opaque, it can be summarised as follows for the Large bundle:<\/div>\n
<\/div>\n