[sldev] Cache politics: performance vs obfuscation

Matthew Underwood sakkaku at gmail.com
Tue Jun 10 18:05:12 PDT 2008


On Tue, Jun 10, 2008 at 7:55 PM, Loom <loom at loomiverse.net> wrote:
>
>
> On 11/06/2008, Ann Otoole <missannotoole at yahoo.com> wrote:
>>
>> Let us ensure we have the priorities straight.
>> With Time Warner and other cable modem service providers preparing to
>> implement bytes transferred caps it is imperative that the cache operation
>> overall be improved to ensure there is no repetitive downloading of bytes.
>>
>> It simply will not matter if the bytes are obfuscated if the population of
>> Secondlife is gutted by a large scale *perceived inability* to afford to
>> participate.
>>
>> Save SL first. Then worry about the rest.
>> If SL dies because of consumers *not being aware of their choices in
>> service providers* then nothing really matters does it?
>
> I realise that you have used the word "perceived" in there but I would like
> to suggest that usage caps are not going to kill secondlife.
>
> Personally, I don't agree with the idea of usage caps, however in Australia
> we have lived with them for quite a while.
>
> From the march 2008 economic stats, there were 12,245 active Australian
> users or about 0.057% of the population, who clocked up an average of 47
> hours each - using usage capped internet connections.
>
> Compare that with the US where 194,899 active users (0.064% of the
> population) clocked up an average of 59 hours each.
>
> At worst, SL may take a hit in usage, but suggesting that it will die is
> imho an extreme view which is more in the line of fearmongering than
> rational analysis.
>
> Loom

The idea is to plan ahead to avoid running full on into a wall.  There
is no point in bickering over weather or not people are able to play
SL, it is to realize that people ARE capped and MAY be impaired by SL.
 Why not improve the caching such that the asset servers are hammered
less, people have to use less bandwidth and therefor have a more
enjoyable experience.


More information about the SLDev mailing list