themonkeysdidit

Everyone should backup their data. We all know it, but how many of us actually do it? Well until today, I didn’t. But I knew I should so I began looking into various solutions.

First off , you need a lot of space for backups, and however much space you have now, won’t be enough a few years down the line. So all the free online services were out as space is pretty dismal.

Secondly, it had to be cheap. It is for home use only after all so fire proof data centres are hardly required.

Thirdly, it has to be automatic, otherwise you just don’t bother or forget to run your backup and that’s when disaster strikes.

So what did I decide? As of early this year I use a mac book pro as my primary home computer, which means it comes with the excellent Time Machine software, perfect for my needs. Next problem was where to tell Time Machine to store the data. I could use the server in our house but this doesn’t guard against fire, theft etc as presumably both laptop and server would suffer the same fate. So I bought a 1TB USB drive from amazon and back up to this. The clever(?) bit is the disk is actually kept in the office at work and I only bring it home once a week (ish) to run a back up before taking it back to work the next day. Thus I have 1TB of off site backup storage - awesome.

And how did I get a network speed of 1456MB/s? Well, it takes about 12 minutes to get from home to work on my bike, so with the disk in my bag, that’s 1TB of data transfer in 12 minutes, which equates to about 1456MB/s bandwidth (all be it with horrible latency ;-))

The eagle eyed among you may be wondering what happened to part two of the shed build. Well, as part one wasn’t really part one, and I didn’t document part two, we’ll just move straight on to part three and say no more about it. So, with out further a do, ta daaaaaaa:

It took two days, a new power tool and a good bottle of red but the shed is done*! And it actually looks pretty good! I even managed to stay within the instructions for at least the first half before deciding I knew better than the bods** at B&Q and improving the shed build and design on the fly.

To celebrate we BBQ’d another chicken according to the now legendary beer can (although this time it was cider) method. Good times!

*OK, it’s not 100% done as an X brace across the back wall and some garden shrubbery type stuff in front are still required, but that’s only a small matter.

**For those in the know, the pun was fully intended.

OK, it’s not really part 1 as we’ve already bought the shed from B&Q, had it delivered (yes, amazingly they actually turned up this time) and worked out where it’s going to go (in the garden - a bit of a no brainer really). This is the first real work though, digging out the garden where the base is going to go.

We’re going for a concrete base as a fit and forget solution, which means a lot of hard work now, but no work later which sounds pretty good to me. So here it is, one hole (complete with shuttering timber frame in place - thank god it fits!) where some rather pleasant turf used to be.

In fact, I’m so impressed with my digging, here’s another shot from a slightly different angle:

And while we’re at it, check out all the turf I carefully removed:

As you may have guessed, I’m quite impressed with my handy work here! The next step is to compact the ground down, ready for the base layer of stones, it’s exciting this suburban living!

Of course, being slightly geeky, I couldn’t just spend an afternoon digging a hole with no technology to keep me motivated so I set up my camera on the tripod, teathered it to Aperture and created a small automator script to take a picture every 30s. These pictures were then imported into imovie and I created a small time lapse movie and uploaded it to you tube. Isn’t technology great!

They say a picture is worth a thousand words, so there you go. Yes, you are looking at a chicken with a can of Heineken where a can of Heineken shouldn’t be! Before you all think I’ve been surfing the wrong side of the internet, let me assure you I followed the instructions I found on youtube to the letter.

OK, so that doesn’t sound much better… The whole beer can chicken thing came from a friend at work who’d seen it done last year. The basic idea is, you stand the chicken up on a half full can of beer and then BBQ it. The results are clearly visible in the picture (although it’s lying down in the picture).

BBQ-ing a whole chicken at first filled me with thoughts of food poisoning, but the instructions said to BBQ it for about 2 hours, with the lid on the BBQ. So that’s what I did. I thought the coals might go out, but no, they remained red hot throughout the cooking time and you could visibly see the heat shimmer coming off the lid so it must have been hot enough.

Finally the taste. Now, I’ll be the first to admit, a lager steamed chicken does not sound the most appealing meal on a menu, but it was actually fantastic! Next up, beer keg turkey!

Following on from the design issues in XMediaStream, the plan of implementing a queue to hold the SimpleMessageObjects received over multicast has been implemented.

This was done with three new classes, and a modification to MulticastShoutcastServer.java.

SimpleQueue.java

This class holds the queue implementation. In a bid for code re-use, the underlying data structure is a simple array of Objects. A read pointer and write pointer point to the next read and write position (wrapping back to zero when they reach array.length). When an object is read, that position in the array is set to null. Therefore whenever a write is taking place, the position in the array is checked to make sure it is null. If it isn’t null, the write pointer has caught up to the read pointer and we’re about to overwrite an object that hasn’t yet been read. If this happens, the queue will re-size and copy the unread objects into the new queue, setting the read and write pointers appropriately.

MulticastPacketListener.java

This is pretty simple, it continuously listens for new multicast packets and for each one receives, check’s it’s for this configured source and if so, add it to the SimpleQueue.

QueueShoutcastServerStreamer.java

This continuously reads from the queue and sends the mp3 bytes to the listening squeezebox.

The only problem encountered was if the squeezebox disconnected (or was started and stopped). Both MulticastPacketListener’s and QueueShoutcastServerStreamer’s are Threads, so if the squeezebox disconnected, the QueueShoutcastServerStreamer stopped reading from the queue but the MulticastPacketListener kept writing new packets to the queue. The queue therefore continuously re-sized until the JVM ran out of memory.

To get round this problem, the SimpleQueue keeps a timestamp every time an object is added to or read from the queue. The MulticastPacketListener then checks each time it writes a new object when the last read took place, if it was more than 30s ago, it deems the reading client is dead and ends.

This implementation has been running successfully for a couple of days now with no glitches in the music, no dropped multicast packets and only a few queue resizes.

A leisurely start time today as both Warren and I wanted to catch the end of the Grand Prix before heading out to the trails. By the time we parked up it was probably gone 11 but this just meant the sun was out in all its glory and we had high hopes of dry and dusty trails.

We started out blasting down BKB and Reservoir Dogs. This is where our hopes and dreams of dust were dashed; anywhere under the tree canopy was littered with surprisingly deep puddles, ready to catch you out if you weren’t careful. After we were spat out back on to the road we began the climb up to the start of Christmas pudding. This was much drier (once you got past the first section) and by now we were flowing nicely. After eating the spray off Warrens back wheel as he ploughed through a particularly murky puddle we were back in Peaslake and I was picking lumps of - what I hoped were - mud out of my teeth.

Here we climbed back up to the top of Holmbury Hill and munched on some home made (cheers Gem!) breakfast bars* while we decided where to head next. As we still had plenty of time we decided to head out and pick a trail we hadn’t ridden before. This turned out to be a great plan as we found a nice new single track route that obviously hadn’t been ridden for a while as there were several points along it where you had to really crouch down the side of the bike to avoid the low tree branches. Following on from this we found another new track (to us anyway) that flowed incredibly well and ended in a nice and fast downhill section. I’ll try and find the name of this one as it looked quite popular. These new routes were so good, we climbed back to the top of Holmbury and did them again, this time we weren’t so reserved as we knew where we going and what lay ahead so could blast along much more. At the start of the second the trail we came across a fellow group of riders about to embark on the same route. They looked far more competent than us than us so we let them go first, and then had no trouble keeping up with them!

After a final climb back to the top of Holmbury we took the new Doc trail and finished down Telegraph road. This almost went to plan! The first minor problem was landing a jump at speed. We were flying pretty quickly towards the jump and I made a fantastic take off. However, the landing was more than my bike was designed for and I not only bottomed out the rear (oo-err obviously) but also the front. The rear wasn’t too much of a surprise as I ride a hardtail and the tyre preasures were low for traction. However, the front had (admittedly only) 100mm of suspension to go through before the rimms come into play and I used it all up! The obvious answer to both these problems is a new bike! Hopefully this year I’ll make the leap to dual suspension.

The final problem was caused by the colossal, herculean strength in my legs**. Powering up the slight slope at the start of telegraph road I ripped the chain in two, sheering one of the rivets. Luckily, I had a chain tool so we were able to make a quick repair and we raced off down the final trail back to the car.

*We use a recipe from Nigella’s Express book which are really tasty and give you the required energy kick, despite not being swimming in golden syrup.

**Obviously!

http://www.santacruzbikes.com/blurlt_carbon/

I want one. I know it’s way more bike than I’ll ever need but it looks awesome and I think it’s a certainty carbon fiber is the way forward, it’s just a matter of getting the technology right, and then make it affordable. With this, Santa Cruz look to have got the former, just not the latter.

Rather than just regurgitate the same limited information, the sites below have some more info:

• http://www.bikeradar.com/mtb/news/article/santa-cruz-unveils-the-carbon-blur-lt-21198
• http://www.singletrackworld.com/2009/04/new-blur-lt-carbon/
• http://reviews.mtbr.com/blog/santa-cruz-bicycles-blur-lt-carbon/
• http://www.bikemagic.com/news/article/mps/uan/6935

Did I mention I want one. There must be some stuff I can sell, how much do kidneys go for on ebay these days?

I finally decided to take the plunge and test whether or not XMediaStream  is dropping packets or not. Every so often when listening to the shoutcast stream, there’s a glitch in the music so I was pretty confident something wasn’t quite right.

First thing was to prove whether or not packets were getting dropped. This was quite simple, every SimpleMessageObject sent as a multicast packet now has a sequence number added to it. The receiver of these packets then checks the sequence number to make sure it is what it is expecting and spits a warning out to the log if it misses one.

I connected a listener to the feed over night and checked the log file, low and behold, a packet was getting dropped about once every two and a half minutes. At this point I was faced with 4 options:

1. Do nothing, one dropped packet every 2 minutes 30 seconds isn’t so bad and results in only a slight audio glitch.
2. Implement a recovery mechanism to allow the recovery of missed packets.
3. Find out where in the network the packet was being dropped and fix it.
4. Do something else.

After a while, the audio glitches are a bit annoying and it’s not a particularly intelligent solution so that was 1 out of the window. A recovery mechanism would mean the receiver would have to request a particular packet, that’s OK, we now have a sequence number we can use. But the sender has no packet history so implementing a recovery mechanism would involve storing history in some sort of data structure. This sounds like a fair amount of work so I won’t be doing 2. Both sender and receiver run on the same server so there’s no routers/switches etc in the way that could be dropping packets so no point doing anything for 3. Interestingly, this also means that we must be filling a Solaris TCP/IP buffer somewhere…

This leaves 4 (did you see that coming?). The way the MulticastShoutcastServerStreamer works (that’s the object that the squeezebox connects to and receives the shoutcast stream from) is that it grabs a SimpleMessageObject off the multicast stream (blocking), extracts the raw mp3 data and then sends it to the squeezebox using the OutputStream from the Socket. Once this write() completes, it then grabs the next SimpleMessageObject from the multicast stream. Here’s where the problem lies. I think the socket writes can block if the send buffer is full, meaning the receiving multicast buffer is filling up while we’re waiting to write to the squeezebox.

As a quick side note, there is some flow control here. The multicast sender sends data pretty much at the bit rate of the mp3, so it won’t swamp the network with packets. However, this simple method isn’t quite enough.

My current way of thinking is to split the MulticastShoutcastServerStreamer further. We’ll grab a load of the multicast SimpleMessageObject off the network and write them to an internal queue. The shoutcast streaming part will then read these from the queue and send the data to the squeeze box. So as long as our queue is big enough, we shouldn’t drop any more packets…

Moosecycles demo day

Last Sunday was the date for Moosecycles Spring demo day, and with it, the opportunity to test some more bikes to help decide which full suspension bike to plump for - more on this in a future post.

Rather than review each one in turn (and face the backlash that caused last time!) I’ll just give my impressions of the three I tried. First up, some crazy adjustable German monster!

Bionicon Supershuttle

Bionicon spershuttle

The Bionicon bikes have a unique feature. They are full suspension bikes with on the fly, adjustable geometry. A button on the handle bars allows air to flow from the front forks, to the rear shock and back again. Meaning you can lengthen the front forks to give the laid back geometry of a down hill bike or the more XC orientated short fork and steeper head angle.

The system actually worked surprisingly well but to be honest, it was just too much bike for what I was after. Pedalling up both road and fire road made this very clear. The bike was heavy and just felt too big and burly for what I want. In the words of some other review I read somewhere, it was more “whallop it” than “whippet”! It was a blast on the down hill though, although (for my skill) it needed to be the all out steep downhill, not the tight and twisty single track we have in abundance here.

Marin Mountvision 5.8

Marin Mountvision

I’ve always been undecided about the look of these - but that opinion was based on pictures alone. Seeing it in the flesh, the big quad suspension lump in the middle of the frame actually looks gnarly and you can convince yourself all those extra pivots and linkages vastly improve the track of the swing arm

Swinging a leg over and the setup immediately felt right. My position in the cockpit, the reach to the handle bars - everything just felt spot on. Decent kit as well for the price; a bolt through Fox fork and XT parts throughout. Climbing back to the top of the hill on the fire roads was without issue, the pro-pedal working a treat. I’ve read other reviews that say this bike is heavy but I didn’t get that impression, although this was coming straight off the Bionicon which (I think) was much heavier.

Now came the fun part, blasting down BKB and Reservoir Dogs. It was, in a word freaking awesome*! The geometry was spot on for the single track and seemed to suit my style of riding (what ever that may be!) perfectly. All in all, this bike was a blast! Even the final descent down the waterfall section was taken with much more confidence than I usually have - pretty good for a bike I’d been on for less than 30 minutes I thought! I arrived back to the demo guys with a huge mud splattered grin, asking questions about price, availability etc… It was a dangerous ten minutes before the final test of the day!

Intense Tracer VP

Intense Tracer VP

Now this bad boy is at the high end of the price range (in fact, it’s higher than the high end of the pretend budget I don’t even have yet!). Still, it looks good and has a very similar VPP system to the excellent Blur LT so I had high hopes for it.

My legs were starting to give in a bit by now (yeah yeah, OK, I’m a wimp) but I got back to the top of BKB and blasted down. This bike was faster than the Marin! The only downside with it was they had the large frame in a single track set up, and the medium in a down hill set up. Typically, I need a medium frame and wanted to test the single track set up. Ah well, I took the large as the geometry would have been closer to what I’d ended up with if I won the lottery but it did impact the flickability of the bike through the twisty and technical single track.

Anyway, the final descent down the waterfalls was, to be honest, brown trousers time. And it was entirely the bike’s fault. It was the bike’s fault for being too damn good, being better the harder you rode it, and for providing you with way more confidence than was humanly safe! So I thundered down the waterfalls and almost hit a couple of trees at the bottom; I was going way too fast. Still, I think the sound of my heart trying to break through my chest and the “joker” grin I had (complete with mud flecks on the teeth) would give the impression of how good I thought this bike was.

Conclusion

The Bionicon wasn’t for me, wrong type of bike for right (well wrong really) type of rider. Now comes the tricky part, the Intense was supreme, but that does come at a price. The Marin was really good and costs a good deal less than the Intense so overall, this was probably the best of the day!

* OK that’s two but it was a bit like New York!

Do you see what I did there!

Spring has definately started to, well spring! I left work before 6 today and it was still daylight. Not only that but it was almost warm - still wearing a jacket but the <insert manly word  for leggings here> are long gone.

So I set off home in good spirits, roared through the lights opposite the station and down to the big cross roads next to the fire station. I pootled (pootled, really - where has my male vocabulary gone?) up the front of the queue of traffic waiting for the lights. This put me along side a taxi, which was OK, because I was going straight on and he wasn’t indicating left. He did inch forward slightly which through me a bit but I again checked he wasn’t indicating so thought nothing of it.

The lights turned green and the taxi of death floored it, to turn left right in front of me! Now I don’t think I’m a slouch off the starting blocks but being fuelled by macaroni cheese isn’t really a match for C₁₂H₂₃! Luckily I’d seen his attempt on my life coming so just let him go (with a few frantic hand gestures - you know what I mean!