Tag Archives: infrastructure

Queueing

A lot of people use queueing for handling data streams and managing how it gets worked on. Whether that’s in routing (here, here, and here for some examples), messaging, traffic etc, it’s a fairly ubiquitous concept. What I haven’t seen elsewhere before, though, is our local ticketing company’s approach to the problem:

Linkin Park – JHB ONLY
You are now in the pre-queue area for Linkin Park – JHB ONLY tickets. When the official queue opens – all customers in the pre-queue area will be given a random place in the queue. Thereafter all queuing becomes sequential.

Citation: here.

To map real-world queues down to making people wait for the chance to buy their (because the system can’t cope with the load) ticket is, well, hilarious. You’re taking the problem from a physical space, to an online one: after the move, you still have the same problem. The reality is that people just can’t wait around in queues all day. But that said, the move is not really unsurprising, especially if we look at this company’s history/skillset/view on fixing this. A quote from one of the concert organizers’, citing what Computicket (our local ticket crowd) said, from the time when the U2 concert ragekilled the ticketing platform

We were very comfortable with what Computicket advised us but there were about 30 000 people on the website at the same time buying the same class of ticket. No system in the world can cope with that. We anticipated huge demand, but it’s about 10% higher than we estimated.

Citation: here.

And yet other people in the world seem perfectly capable of doing this (some are even good at fixing it when they were victim to the issues of not having it right). It’s been happening so often that, many years ago, it was even given a name: The Slashdot Effect. Hell, there’s a bunch of advice collected by people who have fallen victim to this, offered for free. All you have to do is search for it. Not that I’m surprised or anything (at people getting it right). Merely surprised that some people in South Africa still (seem to) stubbornly refuse to believe that anything better than Their Glorious Thing might be possible.

The thought of whether I should launch a ticketing startup has crossed my mind a few times. Perhaps it’s time someone actually did that.

Update: the funny part I only just realized is that they seem to have half learned about the fact that their own stuff sucks, and they outsourced to these people. Who appear to fail just as hard.
Update on the update: it appears these people might not fail hard, but just handle the “making you wait” portion of the problem. It’s still up to Computicket to give you a valid basket interface, tickets, checkout, etc.

South African IPv6 Usage

Over the past while Simeon’s blog has had a few posts concerning IPv6, and this alongside a few other posts that I’ve come across essentially indicate a very sad state of IPv6 in South Africa.

A quick check on Sixxs shows that while there’s a whole lot of allocations, many aren’t seen on the internet at all. We (AS37105) have had our network fully IPv6-capable for quite some time and we’ve even tested native IPv6 connectivity (dual-stack and IPv6-only) delivered to the customer over iBurst‘s network on a PPPoE session, so with all this IPv6 and no-one to send packets to we started looking at who we could get online. We’ve had a pretty good relationship with JAWUG over the years, and as of last night we’re transiting a bit of best-effort IPv6 for them. One of our customers, SA Digital Villages, has also had an IPv6 allocation for some time and their transit is now IPv6-enabled as well.

Here’s to hoping for more IPv6 in SA soon!

 

P.S. In another post I’ll explain why it’s hard to get IPv6 to a Telkom DSL customer in South Africa natively.

Time, NTP and Shiny Things

I see that Regardt beat me to the punch on this one, but we recently got a Meinberg timeserver going. It’s stratum1, publicly accessible and speaks IPv6 fluently! We’ve added it to the pools, so if you use the poolservers you’re quite likely to end up on it sometime.