Technical ecstasy

railWarning: High geek factor alert!

There are some things that you imagine are simply beyond the bounds of possibility, for example, little did i think that i’d ever see the day that i’d be saying it might be time for us to stop disparaging Linden Lab for their failure to address the technical issues that we associate with sl, because – let’s face it – in order for that to happen the Labbies would have to produce some particularly juicy rabbits from the corporate magic hat, and our past experience is, that simply never happens.

However, all the evidence is beginning to point to the Lab doing just that – in rapid succession we’ve seen mesh, Project Sunshine including the latest Interest List changes, materials, and now we’re finally seeing the work on Fitted Mesh, addressing the most pressing issues that have been bugging the sl fashion community.

Now, today, we have proof positive that the Lab is investing heavily in improving the sl experience for the end user by way of the HTTP project, which will not only result in faster rendering of textures and mesh, but will probably result in fewer problems for users outside the USA and will go some way towards addressing router-related problems that can occur when using sl. It’s also a strong indicator, in my opinion, that LL has no plans to retire, deprecate or consign sl to oblivion any time soon – on the contrary, they are making all the right moves to bring sl kicking and screaming into the 21st century.

So, what are the changes and how will they make a difference? To be frank, it’s all pretty technical stuff, but i’ll try to keep it simple…

train3_001Imagine, if you will, that sl is an old-fashioned steam engine, fuelled by coal, which is supplied to the furnace by a team of sweating boilermen. If it’s to run smoothly and at a decent pace, those boilermen need to ensure that a constant supply of coal is supplied from the wagons the engine is hauling to the boiler on the footplate. Every time the driver shouts for coal, a boilerman is expected to report for duty, have his timecard stamped and then deliver a shovelful in good time – however, our driver is a hard taskmaster and expects the coal to be delivered within a set time, if it doesn’t arrive on time, the driver throws a wobbly and sends another boilerman off to get it – this is a time-consuming process, since the driver has to sort out the new boilerman’s time card before he can set off for the same batch of coal the first boilerman went for. In the meantime, our first boilerman turns up – but our engine driver, being a stickler for procedure isn’t interested and waits, instead for the second chap to return. The end result is that the supply of coal can slow down to a crawl, with lots of wasted trips to the wagons and checking of timecards: ultimately, the train slows down.

This is how sl has worked up until now – the ‘coal’ that fuels it is packets of data, (why packets, and not a continuous stream? Because we’re digital, innit! – Only music is better in analogue!), and every time a packet is requested, the viewer and server have to have a little chat – known as handshaking – similar to our boilermen having their timecard updated. Until now, sl has been pretty demanding about how long it’s prepared to wait for each packet and any slowcoaches are killed off, with a brand new request for the same packet then being issued, together with all the associated handshaking – end result, poor responsiveness, dropped packets and slow rendering. To tackle this, the Lab is updating it’s software libraries, (sort of standard procedures for handling routine tasks – those magical .DLL files you find all over the place on computers), and instead of killing off slow packets prematurely, sl will wait longer for them to turn up – waiting may seem counter-intuitive, but it’s likely to be speedier than making multiple requests.

train1_001Back to our steam train:

Inevitably, with our driver sending off boilermen willy-nilly – sometimes half a dozen of them to fetch the same shovelful of coal – there are going to be occasions when the footplate becomes a seething mass of boilermen, all anxious to have their timecards stamped, dump their coal or run back to get a fresh load. Tempers will become frayed, fights will occur and there’ll be such a crush that there will be times when no-one can move, with predictable results.

Most of us, who are not gamers, will have crappy modems and routers that were supplied free by our ISP and can only handle maybe 32 simultaneous connections at a time, rather than the 30,000+ connections that a decent router will handle. Asking a cheap router to cope with sl, is a bit like asking a single bar keeper to handle the drinks orders for the half-time crowd at the Millennium Stadium. How often do you have to re-boot your router outside of sl? Reducing the number of packet requests is also going to relieve congestion at our routers – less shovels of coal require fewer boilermen clogging up the footplate – and this too should reduce problems and improve the way sl works.

train7_001There’s a further area that LL are considering for the future, which bears the snappy title of ‘pipelining’. To return to our train analogy, imagine that this is a mammoth journey – all the way around the world, in fact. That’s going to take a lot of coal, more than can be stored in one wagon, so our train has lots of wagons, stretching out far behind the engine. The longer the journey, the further the boilermen have to go to get the coal, and the longer their round trip to the footplate takes. Techie people call this round trip the ping rate.

When it comes to sl, those of us blessed to live vast distances from the LL server farms are suffering because of this – if you don’t live in the States, the time taken for the viewer and server to communicate is significantly increased. Remember handshaking? Now imagine this typical scenario:

My viewer, here in the sunny UK, requests a packet from a datacentre in gloomy Texas, and it takes 200ms for my request to make the journey;
Texas sends a response, “No problem, pardner!”, which i get 200ms later;
i reply, “Cheers! Please send it!” – another 200ms;
Texas sends the packet, 200ms;
“Thanks!”, i say;
“No problem”, says Texas, “did it arrive ok?”;
“Yep, all in one piece”,
 i respond;
“Cool… pleasure doing business with you. Ready for the next one?”
“Yep, fire away, my good Texan buddy…”

That’s almost a whopping two seconds, just for one packet of data to be transacted, which is just too long. So, the Lab are proposing to get a little gung ho with their packets – rather than go through the whole process of checking that every packet arrives as it should, before sending off the next one, the plan is to send them in a steady stream and assume they are arriving ok unless our viewer sends a message that a bad one has been received. In theory, this could halve the amount of time that users across the world are made to wait for the virtual world to resolve itself.

i’ll shut up at this point, other than to say that i’m certain we’re in for interesting times ahead and some pretty significant improvements in the way we experience sl.

s. x

I crashed again last night
I was on there surfin out of my mind
The system shutted down
M.I.A. – Internet Connection

This entry was posted in Linden Love, RL, SL, Techietalk. Bookmark the permalink.

What do you say?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.