Archive for the ‘trains’ Category

So how do you get from Shoreditch to the South Bank? Well, as Tom from Boris Watch pointed out, you take a number 243 bus. Or you wait 15 years – one way or another. Or you practice, baby. Or you get a haircut. Anyway, so much for taking the opportunity to reuse what I thought was quite a good joke. If journalism is the first draft of history – an ill-thought out exercise in speed-typing riddled with basic factual errors that aspires one day to be edited into ideological propaganda – and blogging is the first draft of journalism, then Twitter is evidently a lot of old cock.

I wanted to flag this article on how the tube map is a lie. Apparently, people tend to underestimate how long their routes will take when using the Beck map, not just tourists but natives (or as we call ’em round here, slightly less recent immigrants) too.

I think the explanation, and the fix, are as follows. Beck’s key insight was to analogise the system to an electrical circuit and draw a schematic diagram of it, showing the key components (stations) and how they interconnect. However, the problem is that we expect a map to show geographical information whereas the Beck map shows logical information.

The fix is, I think, to adopt cold potato routing. The Internet normally uses hot-potato routing – networks hand over traffic to each other at the first possible interconnection point, trying to get rid of it as soon as possible. This has some advantages – it avoids the situation where traffic for Network B is routed into Network A, carried across it, and then carried back towards its source because the furthest interconnect point has failed.

Occasionally this causes a pathological equilibrium – consider a network with customers on both coasts of the US and interconnections with another similar network. Under hot-potato routing, traffic from a customer of A on the East Coast to a customer of B on the West Coast could get routed into B on the East Coast, back out to A, and eventually into B on the West Coast.

Cold-potato routing is the opposite. You carry the traffic as far towards its destination as you can yourself, then hand it off. Roughly, cold is more efficient but hot is more robust. Basically, the recommendation from this would be to avoid changes as far as possible, including changing between modes of transport – which includes, of course, getting onto the tube in the first place. When everything breaks down – every five minutes – of course you can revert to hot potato to route around the break.

You’ll note that Tom’s solution gets it in a one-r.

So, those Oystercard outages. I wrote a sizable post on this immediately before going on holiday, but something odd happened with WordPress’s clever ajaxy bits and it vanished. Computers…anyway, we can work out various things about the problem from the few details supplied.

In the first incident, around 1% of the cards somehow became nonfunctional. We don’t know how; we do know, however, that it was indeed the cards, because the fix was to bring them in and issue new ones. This raises an interesting question; why did new physical cards have to be issued? The process of issuing a card involves writing the data TfL holds on you to the blank card; there isn’t much difference between this and overwriting whatever is on the card with the details held in the database. This suggests either that the affected cards suffered actual physical damage – unlikely, unless someone’s running about with a really powerful RF source and a bad sense of humour – or else that TfL can’t trust the information on file, and therefore needs to erase the affected records and set up new user accounts.

So, how could it happen? Card systems can work in various ways; you can do a pure online authorisation system, like debit or credit cards, where information on the card is read off and presented to a remote computer, which matches it against a look-up table and sends back a response, or you can do a pure card system, where your credit balance is recorded on the card and debited when you use it, then credited when you pay up. Or you can have a hybrid of the two. Oyster is such a hybrid. TfL obviously maintains a database of Oyster user accounts, because it’s possible to restore lost cards from backup, to top-up through their Web site without needing a card reader, and to top-up automatically. But it’s also clear that the card is more than just a token; you can top up at shops off-line, and the transaction between the card and the ticket barrier is quick enough that you don’t need to break stride (consider how long it takes to interact with a Web site or use a bank card terminal).

Clearly, the actual authorisation is local (the barrier talks to the card), as is offline top-up, but the state of the card is backed up to the database asynchronously, and changes to your record in the database are reflected on the card, presumably as soon as it passes through a card reader. To achieve this without stopping the flow of passengers, I assume that when a card is read, the barrier also keeps the information from it in a cache and periodically updates the database. Similarly, in order to get online top-ups credited to the cards, the stations probably receive and cache recent updates from the database; if the card number is in the list, it gets an “increment £x” command.

We can probably rule out, then, that 1% of the Oyster card fleet were somehow dodgy when they started to flow through the gatelines that morning, and that the uploaded data from them caused the matching records to become untrustworthy. It’s possible – just – that some shops somehow sporked them. It’s also vaguely possible that bad data from some subgroup of cards propagated to the others. But I think these are unlikely. It’s more likely that the batch process that primes the station system with the last lot of online and automatic top-ups went wrong, and the barriers dutifully wrote the dodgy data to the cards.

This is also what TfL says:

We believe that this problem, like the last one resulted from incorrect data tables being sent out by our contractor, Transys.

People of course think this was somehow connected with the NXP MiFare class break, but it’s not necessary.

In this scenario, some sort of check incorporated in the database was intended to detect people using the MiFare exploit (probably looking for multiple instances of the same card, cards that didn’t appear in the database, or an excess of credit over the cash coming in), but a catastrophic false positive occurred. This is a serious lesson about the MiFare hack, and about this sort of public-space system in general; the effects of the security response may well be worse than those of the attack. Someone using a cloned, or fraudulently refilled, card could at best steal a few pounds in free rides. But the security response, if that was what it was, first threatened a massive denial-of-service attack on the whole public transport system, and then caused TfL to lose a whole day’s revenue.

Rob Farley has reviewed a book I’ve just been rereading, Marc Levinson’s The Box. It’s a history of containerisation and how it had a massive impact on the economy – Levinson argues that port and cargo handling costs were so great pre-containers that containerisation itself was enough to bring about a huge reorganisation of world trade. I think he makes a strong case, although it’s hard to judge as (as he points out) historical data on shipping costs is surprisingly troublesome.

What interests me, though, is the when. When Sea-Land’s first container ship, SS Ideal-X, sailed from Newark, New Jersey, for Houston in 1956, containers weren’t new. There had been a trade association promoting them for twenty years, issuing possibly the dullest periodical in the history of journalism (Containers). It had been formed by a consortium of European railways. In the late 20s, the London, Midland, and Scottish Railway had a fleet of three thousand boxes in use.

Postwar, other shipping lines and railways were at it too. There was no particular technical change that either required, or made possible, inter-modal container shipping. Levinson offers a lot of the credit to Malcolm McLean, the founder of Sea-Land, for envisaging it as a whole system. (So does everyone else – when he died, container ships around the world sounded their sirens to mark the moment.) But it’s also very interesting that, well, Sea-Land and later US Lines went bust. The world’s biggest container line is AP Möller-Maersk, owners of M/V Emma Maersk, which missed the boat on containers and didn’t own a single box or ship until 1973. First mover advantage? Don’t make me laugh.

The only people who did indeed experience an advantage from moving first were ports, rather than shipping lines. Because the relative location of the port and the final customer was less important, the ships tended to go where the cargo was, and where the cranes were. Hence, unless you got started and began handling boxes, the ships would go elsewhere; and there wouldn’t be the cash to build a container terminal later to win them back. No scope to wait and see. The shipping lines, though, were considerably more able to adapt. This remains a serious problem for most of Africa – without a reasonable promise of a load, nobody will build a terminal, and if you do, they won’t call. And without good shipping, there is unlikely to be much to ship..

Containers have been likened to packets in telecommunications. Certainly, containerisation has similarities with IP networking; the point of IP is that you only need to agree that you are going to exchange data in a particular way in order to internetwork. If you agree that you’re going to handle boxes of sizes 10/20/30/40″ by 8″ by 8″ with ISO standard twist locks, it doesn’t matter how they are transported or by what route, as long as they are. (This doesn’t mean, however, that standardising them was easy. Pas du tout.) Equally, it makes no sense to charge differential rates according to the contents of a container, and it didn’t take off until the shipping lines stopped trying to do this and just charged per box.

The Net Neutrality analogy is pretty obvious. Like the US telcos, they also fought bitterly about it, and lost out to those carriers who didn’t pry in the boxes.

McLean is also an interesting character. A classic example of those canny, obnoxious people from obscure bits of America who the mid-century boom and the great compression unleashed – like Richard Feynman, John Paul Vann, Steve Cropper, and more according to taste – he started off in trucking, and considered Ro-Ro shipping as a way of gaming the regulations, before realising it would be better to ship just the box body of the truck, not the chassis. Having made it with Sea-Land and a variety of distinctly funny financing, he decided to buy a huge swath of the North Carolina backwoods where he grew up and create a vast agricultural development, including a monster, super-industrialised pig farm and a scheme to strip the peat and process it to methanol.

Fortunately for all, he ran into a new trend on its way up – environmentalism, which forced him to leave the peat unstripped. Not long after that, US Lines went bankrupt after betting the company on one of McLean’s big ideas for a second time. The first time, in the late 60s, Sea-Land had ordered a new class of unprecedentedly huge container ships, the SL-7s. These were built to make 33 knots on passage, positively blistering speed for a freighter (not bad for a modern destroyer, in fact), and to provide a round-the-world service that would provide a daily sailing from each major port.

Naturally, making a giant container ship do 33 knots takes a shitload of bunker fuel, and the ships were ready just in time for the ’73 oil shock. Whoops. He was back, though, with another class of even bigger slow ships intended to save fuel – but he was still obsessed with the idea of a round-the-world service. Its failure brought US Lines low, and tripped him into a depression he only left by starting yet a third shipping line at the age of 72. It’s interesting that, having launched a brilliant piece of evolutionary technology, he was always unable to get away from the technocratic vision of an endless belt of ships circling the planet.

OK. Remember a few months ago, the Sundays were briefed about one of Tony’s eye-catching initiatives – to launch a magnetic levitation high-speed rail link from London up to Scotland?

Well, if it ever had any substance, it’s now a dead parrot. And so are all maglev projects, which should bring a hearty cheer from everyone who cares about good technology. Wanna know why? Get your looking gear round this Eurotrib thread. Not only did the new TGV rip through its own record by cranking up to 356 mph, it got within 6 mph of the record for a maglev vehicle. That’s seriously fast for something running across the lumps and bumps. That’s as fast as an early-model Spitfire.

And it kills off the only real argument for maglev – speed. So why do I hate maglev?

It’s a classic case of bad technology, for the same reasons the NHS NPfIT is, and for the same reasons Tony Blair fell for it. John Waclawsky said that there are two kinds of technology, the kind that provides a direct benefit to the end user, and the kind that’s designed by people who think they can see the future. These, he said, are also known as success and failure.

The only way you can start doing maglev is to take a Big Tough Decision to spend kajillions and tear up the whole rail infrastructure. Anything short of that is still going to cost a fortune, but won’t make a profit or give any realistic feedback on whether or not to go ahead. Further, you can’t get any benefit from doing some of it – it has to be all or nothing, because it doesn’t integrate at all with the existing system.

For example, if you put in an upgraded, LGV-standard line from London to Doncaster, even without building it any further, you’ve already hugely increased the speed of the service, and freed up the old main line for freight. And if that worked, you can just keep building. But if you start a maglev project – you’ve got to go all the way before you get any benefit whatsoever, you can’t run services on from the end of the line over conventional tracks or the other way round, and you can only upgrade by pouring another zillion tonnes of concrete.

Given that it involves a completely new alignment, you will probably also need to terminate it out of town (airports were suggested for the ECI mentioned above), which means you’ve got to deal with hordes of passengers getting from where they live or work to the terminal. Do something sensible, and you can run the trains right into London.

But the good news is that it’s New, it’s Expensive, and it’s Centralised. Like second-generation nuclear power and monster government databases. And there is something about this stuff that managerialists can’t resist – it takes a lot of managing, after all.

Thinking about it, I’m struck by an analogy with the creationist quackery of “irreducible complexity”. You can’t have a little nuclear industry, or a modular national identity register, or a progressive roll-out of maglev. They have to spring into being, complete in themselves, fresh from the Designer’s drawing board.

But it doesn’t happen like that. If it can’t evolve, it’s probably useless. Think process.

OK. Remember a few months ago, the Sundays were briefed about one of Tony’s eye-catching initiatives – to launch a magnetic levitation high-speed rail link from London up to Scotland?

Well, if it ever had any substance, it’s now a dead parrot. And so are all maglev projects, which should bring a hearty cheer from everyone who cares about good technology. Wanna know why? Get your looking gear round this Eurotrib thread. Not only did the new TGV rip through its own record by cranking up to 356 mph, it got within 6 mph of the record for a maglev vehicle. That’s seriously fast for something running across the lumps and bumps. That’s as fast as an early-model Spitfire.

And it kills off the only real argument for maglev – speed. So why do I hate maglev?

It’s a classic case of bad technology, for the same reasons the NHS NPfIT is, and for the same reasons Tony Blair fell for it. John Waclawsky said that there are two kinds of technology, the kind that provides a direct benefit to the end user, and the kind that’s designed by people who think they can see the future. These, he said, are also known as success and failure.

The only way you can start doing maglev is to take a Big Tough Decision to spend kajillions and tear up the whole rail infrastructure. Anything short of that is still going to cost a fortune, but won’t make a profit or give any realistic feedback on whether or not to go ahead. Further, you can’t get any benefit from doing some of it – it has to be all or nothing, because it doesn’t integrate at all with the existing system.

For example, if you put in an upgraded, LGV-standard line from London to Doncaster, even without building it any further, you’ve already hugely increased the speed of the service, and freed up the old main line for freight. And if that worked, you can just keep building. But if you start a maglev project – you’ve got to go all the way before you get any benefit whatsoever, you can’t run services on from the end of the line over conventional tracks or the other way round, and you can only upgrade by pouring another zillion tonnes of concrete.

Given that it involves a completely new alignment, you will probably also need to terminate it out of town (airports were suggested for the ECI mentioned above), which means you’ve got to deal with hordes of passengers getting from where they live or work to the terminal. Do something sensible, and you can run the trains right into London.

But the good news is that it’s New, it’s Expensive, and it’s Centralised. Like second-generation nuclear power and monster government databases. And there is something about this stuff that managerialists can’t resist – it takes a lot of managing, after all.

Thinking about it, I’m struck by an analogy with the creationist quackery of “irreducible complexity”. You can’t have a little nuclear industry, or a modular national identity register, or a progressive roll-out of maglev. They have to spring into being, complete in themselves, fresh from the Designer’s drawing board.

But it doesn’t happen like that. If it can’t evolve, it’s probably useless. Think process.