sun, 15-feb-2015, 09:20

Abstract (tl;dr)

We’re getting some bad home Internet service from Alaska Communications, and it’s getting worse. There are clear patterns indicating lower quality service in the evening, and very poor download rates over the past couple days. Scroll down to check out the plots.

Introduction

Over the past year we’ve started having trouble watching streaming video over our Internet connection. We’re paying around $100/month for phone, long distance and a 4 Mbps DSL Internet connection, which is a lot of money if we’re not getting a quality product. The connection was pretty great when we first signed up (and frankly, it’s better than a lot of people in Fairbanks), but over time, the quality has degraded and despite having a technician out to take a look, it hasn’t gotten better.

Methods

In September last year I started monitoring our bandwidth, once every two hours, using the Python speedtest-cli tool, which uses speedtest.net to get the data.

To use it, install the package:

$ pip install speedtest-cli

Then set up a cron job on your server to run this once every two hours. I have it running on the raspberry pi that collects our weather data. I use this script, which appends data to a file each time it is run. You’ll want to change the server to whichever is closest and most reliable at your location.

#! /bin/bash
results_dir="/path/to/results"
date >> ${results_dir}/speedtest_results
speedtest --server 3191 --simple >> ${results_dir}/speedtest_results

The raw output file just keeps growing, and looks like this:

Mon Sep  1 09:20:08 AKDT 2014
Ping: 199.155 ms
Download: 2.51 Mbits/s
Upload: 0.60 Mbits/s
Mon Sep  1 10:26:01 AKDT 2014
Ping: 158.118 ms
Download: 3.73 Mbits/s
Upload: 0.60 Mbits/s
...

This isn’t a very good format for analysis, so I wrote a Python script to process the data into a tidy data set with one row per observation, and columns for ping time, download and upload rates as numbers.

From here, we can look at the data in R. First, let’s see how our rates change during the day. One thing we’ve noticed is that our Internet will be fine until around seven or eight in the evening, at which point we can no longer stream video successfully. Hulu is particularly bad at handling a lower quality connection.

Code to get the data and add some columns to group the data appropriately for plotting:

#! /usr/bin/env Rscript
# Prep:
# parse_speedtest_results.py speedtest_results speedtest_results.csv

library(lubridate)
library(ggplot2)
library(dplyr)
speed <- read.csv('speedtest_results.csv', header=TRUE) %>%
   tbl_df() %>%
   mutate(date=ymd_hms(as.character(date)),
         yyyymm=paste(year(date), sprintf("%02d", month(date)), sep='-'),
         month=month(date),
         hour=hour(date))

Plot it:

q <- ggplot(data=speed, aes(x=factor(hour), y=download)) +
   geom_boxplot() +
   scale_x_discrete(name="Hour of the day") +
   scale_y_continuous(name="Download speed (Mbps)") +
   ggtitle(paste("Speedtest results (",
                  min(floor_date(speed$date, "day")), " - " ,
                  max(floor_date(speed$date, "day")), ")", sep="")) +
   theme_bw() +
   facet_wrap(~ yyyymm)

Results and Discussion

Here’s the result:

Box and whisker plots (boxplots) show how data is distributed. The box represents the range where half the data lies (from the 25th to the 75th percentile) and the line through the box represents the median value. The vertical lines extending above and below the box (the whiskers), show where most of the rest of the observations are, and the dots are extreme values. The figure above has a single boxplot for each two hour period, and the plots are split into month-long periods so we can see if there are any trends over time.

There are some clear patterns across all months: our bandwidth is pretty close to what we’re paying for for most of the day. The boxes are all up near 4 Mbps and they’re skinny, indicating that most of the observations are close to 4 Mbps. Starting in the early evening, the boxes start getting larger, demonstrating that we’re not always getting our expected rate. The boxes are very large between eight and ten, which means we’re as likely to get 2 Mbps as the 4 we pay for.

Patterns over time are also showing up. Starting in January, there’s another drop in our bandwidth around noon and by February it’s rare that we’re getting the full speed of our connection at any time of day.

One note: it is possible that some of the decline in our bandwidth during the evening is because the download script is competing with the other things we are doing on the Internet when we are home from work. This doesn’t explain the drop around noon, however, and when I look at the actual Internet usage diagrams collected from our router using SMTP / MRTG, it doesn’t appear that we are really using enough bandwidth to explain the dramatic and consistent drops seen in the plot above.

February is starting to look different from the other months, I took a closer look at the data for that month. I’m filtering the data to just February, and based on a look at the initial version of this plot, I added trend lines for the period before and after noon on the 12th of February.

library(dplyr)
library(lubridate)
library(ggplot2)
library(scales)
speeds <- tbl_df(read.csv('speedtest_results.csv', header=TRUE))
speed_plot <-
   speeds %>%
      mutate(date=ymd_hms(date),
            grp=ifelse(date<'2015-02-12 12:00:00', 'before', 'after')) %>%
      filter(date > '2015-01-31 23:59:59') %>%
      ggplot(aes(x=date, y=download)) +
            geom_point() +
            theme_bw() +
            geom_smooth(aes(group=grp), method="lm", se=FALSE) +
            scale_y_continuous(limits=c(0,4.5),
                           breaks=c(0,1,2,3,4),
                           name="Download speed (Mbps)") +
            theme(axis.title.x=element_blank())

The result:

Ouch. Throughout the month our bandwidth has been going down, but you can also see that after noon on the 12th, we’re no longer getting 4 Mpbs no matter what time of day it is. The trend line probably isn’t statistically significant for this period, but it’s clear that our Internet service, for which we pay a lot of money for, is getting worse and worse, now averaging less than 2 Mbps.

Conclusion

I think there’s enough evidence here that we aren’t getting what we are paying for from our ISP. Time to contact Alaska Communications and get them to either reduce our rates based on the poor quality of service they are providing, or upgrade their equipment to handle the traffic on our line. I suspect they probably oversold the connection and the equipment can’t handle all the users trying to get their full bandwidth at the same time.

wed, 08-oct-2008, 17:51

ipfw

os x firewall tool

One of the more annoying things about Apple’s wireless routers is that there’s no way to shape the bandwidth. With two of us in the house, commonly using the Internet at the same time, and a limited 43 KB/s bandwidth, we wind up stepping on each other’s use fairly often. One bandwidth limiting tool is the Unix command trickle which allows you to control bandwidth on individual, command line programs. Something like:

    trickle -u 20 -d 20 wget http://bigfiles.com/bigfile.mp3
would limit the file download to 20 KB/second, about half our our bandwidth. Many commands like wget and rsync have bandwidth limiting built in, making trickle unnecessary for those programs.

These techniques don’t work when the programs don’t include limiting internally, and when you can’t run them from the command line. The program I use to download music from eMusic (eMusicJ) is an example. With my downloads refreshing in a couple days, I wanted to find a way to get my downloads in, without ruining the network for the next day and a half.

Since OS X is built on BSD, it comes with a super-sophisticated firewall, ipfw, that has traffic shaping built in. So here’s how I was able to consume only half of our bandwidth downloading music:

Start the download and use netstat -an to find the IP address of the download site (or do netstat -an before and after you’ve started the download to identify the new download IP Address):

    $ netstat -an | less
    Active Internet connections (including servers)
    Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
    tcp4       0      0  10.0.1.198.54176       38.98.87.100.80        ESTABLISHED
    tcp4       0      0  10.0.1.198.54175       38.98.87.100.80        ESTABLISHED
    tcp4       0      0  10.0.1.198.54142       38.98.87.100.80        ESTABLISHED
    tcp4       0      0  10.0.1.198.54136       38.98.87.100.80        ESTABLISHED

Set up a pipe for data coming from that site:

    $ sudo ipfw add pipe 10 ip from 38.98.87.100 to any
    00100 pipe 10 ip from 38.98.87.100 to any

Configure the pipe to limit bandwidth:

    $ sudo ipfw pipe 10 config bw 20KBytes/s queue 10KBytes

After you're done, delete the pipe:

    $ sudo ipfw list
    00100 pipe 10 ip from 38.98.87.100 to any
    65535 allow ip from any to any

    $ sudo ipfw del 00100
Meta Photolog Archives