[sldev] Cache speed experiment & results...

[Ann Otoole]

Time Warner is going to try forcing metered bandwith on the cable modem community they serve. 
So the ugly head of the end of unlimited bandwith use raises it's head once again. 
(Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...)

Has anyone measured actual bandwith utilization to the point people can predict their usage per month before they get slapped with killer bills?

The reason I mention this is because, although I am also a fan of reduced compression overhead, there will no doubt be trade offs required. Perhaps there is a way to make compression/decompression more efficient?



----- Original Message ----
From: Tateru Nino <tateru.nino at gmail.com>
To: Dante Tucker <danteferret at gmail.com>
Cc: Second Life Developer Mailing List <sldev at lists.secondlife.com>
Sent: Tuesday, June 3, 2008 1:08:43 PM
Subject: Re: [sldev] Cache speed experiment & results...

Compromise? A lighterweight compressed cache format? Admittedly, yes, 
the textures would still be coming down as jpeg2000 - which means they 
would have to be decoded and recompressed before they went in the cache 
- which is wasteful. But it's wasteful once per texture transfer, not 
once per texture fetched from the cache.

Use a PNG or vanilla jpg compressor to save space on disk (and let the 
user set the compression quality with a slider to let them decide how 
much bang-for-the-buck they want out of their chosen megabytes of 
storage), then you've got far less work to do decoding than the jpeg2000 
decompressor -- or so I presume. If I got all that fatally wrong, just 
whack me with a rolled up man page.

Dante Tucker wrote:
> I definatly second this as an option. Provided there is no technical 
> reason this can't be done :)
>
> On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu <sldev at bitparts.org 
> <mailto:sldev at bitparts.org>> wrote:
>
>
>
>     Given the dirt-cheap price of HD space these days, why bother
>     compressing the cache, given that the decode is so expensive
>     time-wise? Enlarge the cache maximum size, and toss out the
>     compression - at least give us an option to try it, and see. A
>     simple checkbox or debug option "UseCompressedCache" or somesuch
>     defaulted to yes - then those of us with plenty of space can try
>     it out. People are screaming about texture load times - I can't
>     imagine they wouldn't sacrifice some disk space for a large boost
>     in performance.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>  

-- 
Tateru Nino
http://www.massively.com/

_______________________________________________
Click here to unsubscribe or manage your list subscription:
/index.html



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/49b29f7c/attachment.htm