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 <[email protected]> To: Alex Dailey (Xan Linden) <[email protected]> Cc: Second Life Developer Mailing List <[email protected]> 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
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
