[sldev] More crash rate statistics

[Ann Otoole]

You will know it if you see it is the only universal measure.
ktris/fr efficiency is tied to GPU right? How fast can the data be dumped to the client? How fast can the textures come down. All that has a lot of ISP factor involved.
Is windlight enabled? that automatically adds 130,000 triangles to the rendering whether you are outside or inside an enclosed space with no alpha texture views out.
Too many factors so I go with "if it feels good it is good".

That said the performance measures that matter are all related to the number of avatars in a region and how many scripts they brought with them. (and phantom script sludge buildup)
If time dilation is unstable or low then your fiber connection, viewer, and super computer isn't going to matter anyway. 
Currently the max number of avatars that can be in a Linden Lab region before it starts going bad is around 15.
This number has been decreasing with every region code update. 
Only 5 to 10 more updates before the grid is dead at the current rate of degradation.

I went to a concert today., The sim peaked at 82 avatars. 
Nothing would rez and nobody could escape so the sim had to be restarted just to release the avatars so they could go somewhere else..
Compare to early 2007 when 100 avatars in a sim was still acceptable. 

User experience is tied more to the sim performance than viewer performance.
A lot more engineering time needs to be applied to the simulator code base IMHO. Perhaps it is. I would have no idea. But it is getting real bad out there. 

$300 a month for a 20 avatar region is pretty steep and the social networking aspects of SL are dying off since it is getting harder to have social events of any serious size.

That is my input.





________________________________
From: Stickman <stickman at gmail.com>
To: Alex Dailey (Xan Linden) <alex at lindenlab.com>
Cc: Second Life Developer Mailing List <sldev at lists.secondlife.com>
Sent: Friday, August 7, 2009 8:40:08 PM
Subject: Re: [sldev] More crash rate statistics

> Here's a challenge to sldev. What do you think a) is the one variable
> viewer performance should
> ultimately be measured by and b) what are, say, three predictive
> variables that influence the dependent variable.

What a fun challenge!

It has been mentioned before in sldev that the developers/content
creators are not your "average" SL users. So the metrics they choose
may not be the best ones for the populace at large. But ask the
populace at large what they want, and even using statistical analysis
on their answers you may not get the heart of the matter. It's like
asking someone to self-diagnose what the issue is when only a trained
doctor knows the bodypart with the problem exists.

Anyway, for me personally... ... ...what a difficult challenge. D:
This isn't fun anymore.

The main thing that's important to me is productivity. Being able to
properly create things inworld. Kinda hard to fit into a metric. Not
crashing, naturally, is important to productivity. But there's a lot
of other factors, too, which seem like more of a problem than crashing
is, or ever was.

The metric to measure performance I would use is:

Communication and response from viewer to server.

The top three predictive variables are:
-Functional Inventory (never really had a problem with it, though)
-Rezzing working and timely (including textures, sculpts, etc)
-Attachments working (No "attachment already pending" getting stuck, etc)

There's a few other issues, like uploads, IMs, FPS, crashing, and
whatever else, but at this moment I'm not having a problem with them,
so they don't seem as important.

Also, a thank you to whoever fixed the double-upload notice in 1.27.2.
That's been bugging me a lot.

But -- that's me. For the average user, I would guess they care about
the same communication element the most. But I am going to guess that
their top three predictive variables would be:

-Functional teleports
-Functional attachments
-Functional rezzing/displaying of existing prims

This is based on what I can visibly see others doing a lot and having
trouble with. So they may not be long-term predictive elements if they
become rock solid, but the core issue of communication would remain
the same.

Also:
> *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead.

The same amount of crashes as a viewer or so ago and having fully
rezzing textures instead? Yes, I can live with that, too. I had to
stop using Snowglobe because of the texture issues. I couldn't even
open them from inventory. I am really looking forward to full
http-texture support, as I expect a lot of speed out of it.

-Stickman
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090807/18c8de5a/attachment-0001.htm