[sldev] Cache speed experiment & results...

[Darien Caldwell]

If you were to run the client at full bandwidth available (1500kb) non stop 24/7, you would use up the proposed 240 gbit a month Comcast is proposing in 48 hours.  Fortunately, most people don't eat up that much.  A sustained data rate of 275kbps 8 hours a day for 30 days would use up the 240 gbit limit.  Key word is sustained, sitting in a sim doing nothing it's rare you get a transfer rate over 50kbps.  It would be interesting to see how a normal session averages out however.  This certainly will impact heavy users (like me), but to the average user, they won't see any problems.
  ----- Original Message ----- 
  From: Ann Otoole 
  To: Second Life Developer Mailing List 
  Sent: Tuesday, June 03, 2008 3:26 PM
  Subject: Re: [sldev] Cache speed experiment & results...


  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





------------------------------------------------------------------------------


  _______________________________________________
  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/3575a63f/attachment.htm