Deploys for the week of 2013-04-15 (Updated @ 2013-04-16 13:50PDT)

[Pamela Galli]

---

Yuriko Nishi wrote:

i have this vehicle that sometimes combines 2 animations, one for the arms and one for the rest of the body.

worked for years, now it plays the arm animation and only part of the other. the legs play the default sit animation.

is this a server update that broke it?

 

pamela seems to have animation problems too, cant look at the jira (why?) so can´t work with that.

 

please fix asap

 

thanks

---

Yes that is exactly the bug I reported in the fall, was confirmed by Maestro, and then forgotten about.  I have fifty dining sets that are affected. 

[Yuriko Nishi]

thanks for the info pamela

 

that´s bad news!

 

will try to fix it myself then

[Pamela Galli]

---

Yuriko Nishi wrote:

thanks for the info pamela

 

that´s bad news!

 

will try to fix it myself then

---

That one we can't fix, I don't think.  The sim loses count of how many animations are running and stops more than it should, something like that. It is up to the devs to fix it, and evidently they don't want to. The status is "Released" and I don't know what that means.

[Ayesha Askham]

Maestro (and by default Monty)

With all the shenanigans of this past weekend with regard to asset/inventory server failures, I just wonder if anyone has considered the implications of the http texture "refinements" applied in the recent server updates?

One of the worst aspects of general performance, aside from the dreadful inventory issues, at least to my mind, has been the woefully slow rate at which textures are sent by the sim to the viewer.  On a sim with more that one or two avatars on it, it might take 10-15 minutes for a highly textured sim to be properly presented to a viewer with more than a 64m draw distance. The more highly loaded with avatars a sim is and the greater the viewer's draw distance, the longer it seems to take now.

"Twas ever thus", you say, but no, this is FAR slower than it used to be even using UDP.  Has some overly severe throttle been applied?  On highly textured and occupied sims such as those of Fantasy Faire, it is taking so long to load textures that folk are giving up and leaving without:

1) Seeing the exhibits

and

2) Donating to the Charity...RFL.  Now Lindens this is a RL Good Cause, but this issue is blighting it.

[WolfBaginski Bearsfoot]

Maybe obvious, but some viewers have an option to turn off HTTP Textures. Firestorm, for one. Have you tried this,

(It might not actually make any difference, I know.)

 

[WolfBaginski Bearsfoot]

And now I have tried it, and it does seem to make a difference, but I'm not sure whether that might be the effect of caching or not. It's worth some more careful checking. But, since I'm running the Firestorm Preview, take what I'm seeing with a pinch of salt

[Nalates Urriah]

It only 'seems' that way.

[Monty Linden]

---

Ayesha Askham wrote:

One of the worst aspects of general performance, aside from the dreadful inventory issues, at least to my mind, has been the woefully slow rate at which textures are sent by the sim to the viewer.  On a sim with more that one or two avatars on it, it might take 10-15 minutes for a highly textured sim to be properly presented to a viewer with more than a 64m draw distance. The more highly loaded with avatars a sim is and the greater the viewer's draw distance, the longer it seems to take now.

"Twas ever thus", you say, but no, this is FAR slower than it used to be even using UDP.  Has some overly severe throttle been applied?  On highly textured and occupied sims such as those of Fantasy Faire, it is taking so long to load textures that folk are giving up and leaving without:

1) Seeing the exhibits

and

2) Donating to the Charity...RFL.  Now Lindens this is a RL Good Cause, but this issue is blighting it.

---

For us, the challenge before we can take action is to receive actionable data.  For something that's not a small feature request or defect or regression, something that looks like infrastructure, this is more important.  A solid bug report (as per wiki) including actual locations and times, measurements of performance (how long did textures take to load) and well-defined start and end points of the measurement (started with clear cache, stopped timing when texture console emptied) and log files.

That said, a few minutes ago, I visited the host that's currently running the 'Crimson Fields', 'Fairelands Junction', and 'Magnificat' regions.  It was undergoing the heaviest sustained mesh download I've looked at as well as a healthy load of textures.  The result is a significant delay getting into some HTTP services, something I've seen since working on SVC-6760.  Some causes are known to me, some may not be revealed.  But good bug reports will help identify them.

As for workarounds, I don't have any yet.  If it is mesh-dominant, UDP textures won't help so much.  Deleting cache constantly will make your experience worse.

[WolfBaginski Bearsfoot]

Thanks for the response.

Since I'm the guy who mentioned caching, I figured I had better make my thinking clear.

If turning off HTTP textures does make a difference, the only way I can see of a user making a useful measurement is to visit the same region twice, one with HTTP Textures off, and once with them on. And the cache will have to be cleared before each visit.

Otherwise, having data cached will make the second visit, whichever option is chosen, give a faster result.

I think I am awake enough for that to make sense.

From what you say, there's enough complexity in the traffic, with different types of data, that very few of us will have the tools to record useful data. And besides, the internet as a whole can get pretty gnarly. In my own case, I know there are certain times of day when the internet at my end gets very busy, with other customers of my ISP streaming video. Weekdays are different from weekends, and the timing alters during school vacations.

To be honest, it looks complicated enough that I sometimes feel I shall never be able to give useful hard data. I know I've sometimes managed to start something rolling.

 

And one side thought: I've seen pics and machinima of the Fantasy Faire stuff, and the regions look wonderful, and full of wonders. But if they're intended to get people to visit and hand over their hard-earned L$, and they're generating the high server traffic levels reported, maybe something a little less fancy would have been a better design. Is it the equivalent of those hugely complex, slow to load, web pages of the past?

[Ayesha Askham]

Monty

Thanks for that detailed reply. I am sure that as I have said elsewhere, such responses while they are not fixes, make the pain more bearable.

The Mesh download queue is very likely one of the issues at the root of this.  The apparent slowness of http textures in other places is less easily explained. For me, turning off http textures shows me no benefit, and while the inventory servers seem so delicate I am loathe to clear my cache and investigate further

Wolf, you may be right, but Nalates gives you a wise caveat. Different context maybe but applicable nonetheless.  The return to UPD get would, at best, be a temporary fix.  It is a seeming, I suspect, not a genuine effect.

[Eric Castanea]

I have had my AO destroyed 3 times in the last week. Nothing I can do will bring it back again. I have to rezz a new copy - then remake all my outfits again. There is something causing scripts to be destroyed during a sim crossing.

 

[Whirly Fizzle]

---

Eric Castanea wrote:

I have had my AO destroyed 3 times in the last week. Nothing I can do will bring it back again. I have to rezz a new copy - then remake all my outfits again. There is something causing scripts to be destroyed during a sim crossing.

 

---

Eric, please can you file a JIRA with as much information as you can provide.

Specifically: region names, date and time of occurrences.