[sldev] Cache speed experiment & results...

[Tateru Nino]

We've always had capped and metered bandwidth out here (most countries 
do). We've got to watch our SL bandwidth consumption pretty much every 
day, and throttle back as necessary to keep within limits. If you're on 
a commercial, metered connection (most of those outside North America), 
SL is fantastically expensive to connect to - even metered residential 
connections can run into an end-of-month bill of hundreds or thousands 
of dollars if you're not paying attention.

Ann Otoole wrote:
> 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>
> > <mailto: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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>   

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