So I had reason to transfer 350GB of data from a server hosted by Mythic Beasts to a USB drive in order to back up and ship the data to a bandwidth deprived customer. For reasons of my convenience I thought I’d do this from my home office where I have a 10Mbit ADSL connection provided by a small reputable and non bargain basement ISP and a 60Mbit connection provided with an entirely different technology. I split the source files roughly 2:1 between the connections and downloaded them with rsync tunnelled over ssh. Over the next 26 hours the download ran, 99.6GB over the DSL line (average speed 8Mbits),150GB over the cable (average speed 12Mbits).

I’ve taken the bandwidth graph from the server and included it above. The blue box is the DSL line data, the wavy line the cable. You’ll notice the DSL line runs flat out the whole time with it’s performance never wavering, the cable is clearly limited by congestion. This isn’t an issue on the server side – we’ve 100Mbits from the server up to to the router then 1Gbit out to the peering exchanges (LoNAP and Edge-IX) where we pick up the DSL and cable providers.

The main difference here is the incentive scheme. My DSL provider gives me a bandwidth cap and charges me for additional bandwidth over that limit. Consequently they have an incentive to make my line as fast as possible because that makes it easier for me to pay them more. It also means the only other users of the network who are using large quantities of traffic are paying their fair share which provides the money to upgrade the network. My cable connection is ‘unlimited’ which means performance is constrained by congestion caused by other users. The flat-lines are caused by the rate limiting confusing ssh and the connection essentially stopping until I had to intervene restart the transfer. I’ve included these because fast though 60Mbits may be, I’m not going to sit and babysit for the full 350GB download to complete.

This is why servers supplied by Mythic Beasts come with fast connections, bandwidth allowances and excess fees. We want to make your connection as fast as possible so you can easily spend more money with us.

Yesterday Mythic Beasts and selected friends went to the Cambridge beer festival. Whilst there we saw a poster put up by the Son Of Sid brewery for a beer called codebreaker with a mysterious set of non-sensical characters at the bottom.  It took about a minute of staring knowingly before one of us said ‘well it’s not a substitution cipher’, followed by ‘I wish I had a laptop with me’ and before we knew it we had a crack team trying to break the cipher.

If you’d like to have a go yourself we suggest you get down to the beer festival, the breweries twitter feed says you have until Saturday to work it out. At the end there’s going to be a draw from all the successful entries to win a polypin of beer.

I don’t think we managed to save the world from a Hollywood style alien invasion but we had fun and drank beer at the same time.

EDIT: The official brewery twitter feed says,

Bob Mitchell ‏@sonofsidbrewery

One entry so far in the codebreaker competition @cambeerfest
12:27 PM - 22 May 12 via web · Details 

that was team Mythic.

Matt Smith has very handily also written a guide for installing Debian on our VDS service, which is particularly helpful for end users running Windows on their local machine.

One of our braver customers who wishes to remain anonymous has been trying out NetBSD on our KVM based virtual server platform. This is unsupported but he’s written us the following advice that any future customers might appreciate.

Firstly, the default network device is not going to work under 
NetBSD, so running

    netdev rtl8139

before installing is needed. Because of the default realtek 
driver in NetBSD, the install will be a bit choppy - 
recommended pulling packages from CD instead of network.

After that recompiling the kernel is needed, with 2 
modifications.

I've based my config on GENERIC, so simply copying the 
GENERIC config file and commenting out the re* driver. 
This will make the kernel use the older rtk driver, which 
will work. Mind that /etc/ifconfig.re0 will need to be 
copied to /etc/ifconfig.rtk0 to make sure it comes up with
network enabled after boot. Just find the line starting with 
re* and comment it out.

Before recompiling, edit /usr/src/sys/netinet/if_arp.c and 
lookup the line matching "arp info overwritten". Simply 
delete the line (3 lines in total ending ";") as having this 
 being logged is a nuisance as your router IP keeps changing 
between interfaces (so arp table is constantly updating).

NetBSD isn’t an officially supported distribution as we have minimal direct experience with it, but if you’re happy to support yourself we hope this helps you get set up.

We’ve offered privacy on domain name registrations for some time, I’ve just deployed an update which makes it possible to enable or disable it for every supported domain through our control panel.

We’ve long been drinking partners of Eben & Liz who are building the Raspberry Pi ultra-cheap Linux machine which will hopefully breed the next generation of employees for Mythic Beasts. We’ve got secret plans for what we’re going to do with the one that’s on its way to us – to be revealed in a future blog post. Today, in addition to donating all the bandwidth for the main Raspberry Pi website, we’ve added a mirror for Raspberry Pi image downloads using one of our virtual servers. It’s got a full gigabit of IPv4 & IPv6, so download away.

Five years ago we lost a good friend and founder of Mythic Beasts, Chris Lightfoot. In addition to his many public achievements we remember some of the smaller and less well documented experiments. The fan assisted barbeque that had a cooking range of several metres. The hot air balloon that was equally effective at setting fire to fences. The never yet satisfactorily explained quantum effects in the Theory of Asymptotic Washing Up.

Spurring on that traditional english eccentricity and hopefully providing a little inspiration to the next generation of super villans we’ve just agreed to donate a little server to providing hosting for Cambridge University Spaceflight. We’d like to think that in a universe where Chris’ waveform had collapsed differently he’d watch a rocket launch and associated datastream with a hidden sense of excitement before correctly pointing out ‘Now you have Two problems’.

At about 6pm this evening I’d just finished loading up a car to take some more servers to the data centre and rescue a customer who’d broken their server. As I did so a person with a black hood pulled over their head opened the back door of my car, grabbed my laptop bag and made a run for it.

Unfortunately for the opportunist, I’m a passable distance runner and I happened to be wearing the new running shoes which I’m breaking in. So I chased him hoping my stamina would lead him to tire and eventually I’d catch him.

Despite his apparent age advantage and his head start, after 225m (I measured it afterwards) it was obvious I was going to catch him so he dropped my laptop and continued to run away. I took the bait and retrieved my laptop rather than catching him and beating him to a pulp which in many ways would have been more satisfying.

Reflecting on the experience I have to say that was a lousy performance on the thief’s part, it should have taken me at least a mile to catch him. Why would you go into the smash and grab robbery business without learning how to run quickly first? As a result I’ve made a small donation to the Cambridge Parkrun because it’s nice that someone is attempting to do something to improve youth fitness because it seems they bloody well need it.

Over the weekend of January the 7th and January the 8th we upgraded our core routers in Sovereign House and Harbour Exchange. Previously Sovereign House had a 2x1GE bonded uplink into each router, with each router having 1G of transit and 1G of peering (different peering exchange and transit provider on each router). Now we have a 10GE ring around the two routers and the core switches and lots of spare 1G and 10GE ports on the routers so we can bring additional transit and peers online easily in the future.

The router upgrade was completed almost without issue, there was a brief period in the early hours of Sunday morning with incorrect configuration for one /24 in Sovereign House and our IPv6 gateway in Sovereign House was offline for an extended period because we hadn’t configured it to advertise correctly. Aside from those issues we were able to replace each router in succession relying on the redundancy provided by the other router to seamlessly fail over between them as they were replaced.

We’re happy to report that Cambridge customers didn’t observe a 12 hour outage with our Cambridge to Sovereign House connection on Friday 6th, everything correct rerouted via Harbour Exchange resulting only in a momentary blip when the connection failed catastrophically mid afternoon. Normal redundancy was restored in the early hours of Saturday morning after a large section of fibre had been replaced.

We’ve now implemented IPv6 glue for .com / .net / .org domains through our control panel and other country codes that support glue records.