Month: December 2011

Vehicle Excise Duty and Cyclists

Posted on by pica

I admit, this is a bit off topic given the theme of my other posts, but I got to thinking about this and had to scratch the itch.

Cars and lorries in the UK have to pay a duty called the Vehicle Excise Duty (often erroneously called Road Tax). The cost of the duty is a function of the amount of carbon your vehicle emits up to a maximum of 225g/km. The graph below shows the cost for the thirteen bands:

The Vehicle Excise Duty as a function of the carbon emissions for petrol and diesel vehicles.

It’s interesting to note that there’s not a linear relationship between the carbon emissions and the cost, which is odd. Who decided these bands and the associated cost, and how did they choose them?

I cycle to work daily, and wondered where on that chart a cyclist might fall. Some brief searching gave me this Guardian article with some analysis of the carbon output from cycling. The article states the very existence of a bike means it’s encumbered with a 50g/mile carbon footprint (which in sensible units is 31.07g/km). Since all motion requires a force (and thus energy — see Newton’s Laws of Motion), then making a bike move increases the carbon footprint. The Guardian article uses five different energy sources for the person powering the bike (bananas, cereal with milk, bacon, cheeseburgers and air-freighted asparagus) giving a range of energy consumption rates of 65g/mile, 90g/mile, 200g/mile, 260g/mile and 2800g/mile, which is sensible units is 40.4g/km, 55.9g/km, 124.3g/km, 161.6g/km and 1739.9g/km.

This gives us a range of values for the cyclist which we can compare with the car emissions, however, the range of values used in the calculation of the Vehicle Excise Duty only goes as low as 100g/km, for the banana powered cyclist, we need a lower value. Since the Vehicle Excise Duty appears to be roughly linearly correlated with the carbon emission, let’s extrapolate backwards. The graph below shows the same values as in the first graph, but with a linear regression backwards to zero carbon emission.

vehicle_excise_duty_analysis_linear
Carbon emissions versus Vehicle Excise Duty cost for petrol and diesel vehicles in the UK (solid line). The dashed line shows a linear regression through the Vehicle Excise Duty data points.

Using the linear regression, we can now calculate the Vehicle Excise Duty for any carbon emission rate. So, for the five cycling carbon emission rates calculated by the Guardian, we get Vehicle Excise Duty rates for cyclists of:

  • Banana (40.4g/km)
    • -£229.45
  • Cereal with milk (55.9g/km)
    • -£177.31
  • Bacon (124.3g/km)
    • £52.77
  • Cheeseburger (161.6g/km)
    • £178.24
  • Air-freighted asparagus (1739.9g/km)
    • £5487.33

If the Vehicle Excise Duty tax weren’t set with a minimum (for all vehicles whose emissions are below 100g/km), then using this approach, a banana-fuelled cyclist should receive a £229.45 annual rebate. A more commonly cereal-with-milk-fuelled cyclist ought to receive a £177.31 rebate whilst those cyclists feasting on less healthy fare (bacon and cheeseburgers) would have to pay £52.77 and £178.24 respectively. Anyone who manages to sustain themselves on asparagus alone deserves everything they get, including a £5487.33 Vehicle Excise Duty bill.

Automatic upload speed throttling

Posted on by pica

As I’ve discussed before, the broadband service we receive from Virgin is subject to caps on the traffic on the line during certain times of day (see this post I wrote). Virgin have a relatively complex system for throttling your speed based on the amount you download and upload within certain times. I have a script which performs a backup of my data from my server at home to my work computer using rsync over SSH. This means that I sometimes have a large amount of data to upload during the day. Since Virgin’s upload restrictions apply between 1500 and 2000 during which time you are permitted to upload a maximum of 1.5GB. What this means is that for five hours, the average transfer rate must not exceed 300MB per hour, which equates to a transfer speed of 83.3 kB/s. I searched for a way to limit my server’s upload speed and came across tc (which is a kernel extension which must be enabled in your .config). Slackware’s kernel config includes the necessary parts as modules, so when you use the tc command, they are automatically loaded.

I found a good example which described what I wanted to achieve (limit my uploads to 83.3 kB/s) here. Using the examples on that page, I wrote a little script to allow me to start and stop the limited uploads easily:

#!/bin/bash

# Script to throttle uploads during the times when Virgin
# won’t allow unlimited uploads.
#
# Those times are between 1500 and 2000 no more than
# 1.5GB must be uploaded, so the upload speed needs to be
# capped at 83.3kB/s.

maxRate=83.3kbps
burstRate=100000kbps
interface=eth0

clearRule(){
        # First things first, clear the old rule
        tc qdisc del dev eth0 root
}

makeRule(){
        # Now add the throttling rule
        tc qdisc add dev $interface root handle 1:0 htb default 10
        tc class add dev $interface parent 1:0 classid 1:10 htb rate $maxRate ceil $burstRate prio 0
}

listRules(){
        tc -s qdisc ls dev $interface
}

case “$1” in
        ‘start’)
                clearRule
                makeRule
        ;;
        ‘stop’)
                clearRule
        ;;
        ‘status’)
                listRules
        ;;
        *)
                echo “Usage: $0 {start|stop|status}”
        ;;
esac

You’ll note I’ve set a $burstRate value of 100MB/s. This is probably not necessary, but with the same $burstRate value as used in $maxRate, I was seeing significant slowdown in the responsiveness of the remote session; I hope this high burst rate will alleviate that slowdown.

I saved this script somewhere where root only could get it and then added the following cronjobs to root’s crontab:

# Add networking throttling between 1500 and 2000
00 15 * * * /root/throttle_uploads.sh start
00 20 * * * /root/throttle_uploads.sh stop

So far, the process appears to be working, insofar as my daily uploads from home to work have slowed to approximately 80kB/s during the times when Virgin monitor uploads.

Hosting your own calendar server

Posted on by pica

I recently came across an interesting story by Cory Doctorow entitled ‘Scroogled‘ in which Google becomes a malevolent force with its comprehensive archive for each user. With that in mind, I began to consider the information I put into Google’s server (the irony of writing this post on Google-owned blogger.com is not lost on me). I use a lot of their services, and thought about which one I could most easily replace. Google’s calendar offering seemed a good place to start since I didn’t really interact with it through Gmail, but accessed it through my phone and through Thunderbird on my other computers.

Some brief searches found a list of potential calendar servers, but the one which stood out to me was radicale. This CalDAV server is a nice simple Python server, with no dependencies besides Python itself. The default configuration is pretty well set up, with a few changes needed before you can start accessing your server.

The default port from which the CalDAV calendars are served is 5232, so I opened up that port on my router so that I could access the calendars from anywhere. I had to install a CalDAV app called CalDAV-sync-beta on my phone to be able to view my calendars on the native calendar widgets. The Lightning plugin for Thunderbird can load the radicale calendars by default. Adding them is a simple walk through the wizard, selecting the option to add a new calendar “On the network:”, then choosing CalDAV as the type of calendar. The syntax for the calendar location is

http://your-home-server.com:5232/username/calendarname

replacing your-home-server.com with either your server’s IP address or its URI. Likewise, username should be the user who’s launched the radicale daemon (I suggest this is not root). The calendarname value can be anything you like, but it’s probably best to make it something memorable, or at least descriptive.  For the CalDAV-sync-beta app on Android, the process is similar (Settings > Accounts & sync > Add account and select CalDAV. I found it easier to select “Manual mode” for configuring the calendar. The syntax for the calendar address is similar to the Lightning example above:

http://your-home-server.com:5232/username/

except you’ll notice I’ve omitted the calendarname value at the end. This is because CalDAV-sync-beta will search for all the calendars you have at that location and offer you the option of syncing them all or just certain ones. You can specify the full path as in the Lightning example if you know you will only want to connect to a single calendar on this server. The username value needs to contain a value, but you can omit the password (we have not set up a password protected calendar).

I have yet to manage to get radicale to accept a username and password, so the calendars are open to the public, which is probably something of which you should be aware.

Overall, it’s been working well, and disentangling myself from at least one Google service is a start.