avi dosn`t load correctly

[wizzelone]

after the last updat my avatar sudenly dos not load correctly any more.

i have a DSD rabbit avi and his eyes and hands and when talking i get little

piramyds now.

whats going on?

in catznip and firestorm every thing is normal.

 

[valerie Inshan]

Your mesh settings have to be adjusted. Go to the Debug Settings (in the advanced menu or from your login screen before login in), type in "MeshMaxConcurrentRequests". The default value is 32. Increase it until you see yourself correctly (i.e., the yellow triangles disappear). I personally set mine at 100 or 150 and never see those yellow cones anymore! :smileyhappy:

[wizzelone]

thanks but that made me crash ery time lol so a some one here said to clear my cache and that worked.

but still hanks for the help.

[Venus Petrov]

Normally,  a relog will cure the problem.  The yellow triangles are mesh download failure markers (even if you see a script error associated with it, they are not script errors).  Pushing the maxconcurrentrequests setting up as Val suggested can help to rez others wearing mesh but it is recommended that you do not leave the setting high because it can impact viewer performance (from the Firestorm help group).

[Coby Foden]

With slowish connection to Linden Lab servers it's even better to lower the MeshMaxConcurrentRequests and increase the FSMeshRequestTimeout. The latter is available in Firestorm.

In Linden Lab viewer MeshRequestTimeOut is harcoded to value of 30 seconds (no debug setting).

In Firestorm JIRA there is very good info about MeshMaxConcurrentRequests and FSMeshRequestTimeOut.
http://jira.phoenixviewer.com/browse/FIRE-8842

"The problem with setting a high concurrency is: if you have a slow connection and at the same time the viewer tries to download several mesh assets that are quite big, they will not finish within the timeout and the viewer tries again. if you have 32 requests that are in this state, no new mesh will load. Increasing the concurrency will indeed load mesh again, but the situation will get worse since you are now trying to squeeze even more data through the line. So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout."

I had some problems with mesh loadings in mesh intensive places. I changed my settings to:

MeshMaxConcurrentRequests = 16 (default is 32)
FSMeshRequestTimeout = 120 (default in FS 60 seconds)

The result was that meshes loaded faster and more reliably than with the default settings. My local internet connection is fast (10 Mbps, download and upload) but from Europe to Linden Lab server the connection is always musch slower.

 

[Monty Linden]

---

Coby Foden wrote:

So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout.

 

---

I'll confirm that this is the better strategy for the stated reason and for several others.  Higher concurrency increases the chances of a retry/failure cascade.  These come along with warning messages in the SecondLife.log file that include:

  Timeout or service unavailable, retrying.

Each of these represents connection churn (disruptive to certain routers and other gear as well as detectable as a DoS/SYN flood) and a possible charge against future requests at servers.  Too many of these too fast and all mesh download service will stall indefinitely.  I have seen this at 32 but never 16.  Reduce those messages and you should be heading in the right direction.

 

[Alicia Sautereau]

---

Coby Foden wrote:

With slowish connection to Linden Lab servers it's even better to

lower the MeshMaxConcurrentRequests

and

increase the FSMeshRequestTimeout

. The latter is available in Firestorm.

In Linden Lab viewer MeshRequestTimeOut is harcoded to value of 30 seconds (no debug setting).

In Firestorm JIRA there is very good info about MeshMaxConcurrentRequests and FSMeshRequestTimeOut.

http://jira.phoenixviewer.com/browse/FIRE-8842

"The problem with setting a high concurrency is: if you have a slow connection and at the same time the viewer tries to download several mesh assets that are quite big, they will not finish within the timeout and the viewer tries again. if you have 32 requests that are in this state, no new mesh will load. Increasing the concurrency will indeed load mesh again, but the situation will get worse since you are now trying to squeeze even more data through the line.

So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout.

"

 

I had some problems with mesh loadings in mesh intensive places. I changed my settings to:

MeshMaxConcurrentRequests = 16

(default is 30)

FSMeshRequestTimeout = 120

(default in FS 60 seconds)

 

The result was that meshes loaded faster and more reliably than with the default settings. My local internet connection is fast (10 Mbps, download and upload) but from Europe to Linden Lab server the connection is always musch slower.

 

---

Funny, i changed it to 16 aswell and mesh items are loading faster then 32, 100 or 500, significant increase with mesh clothing on other people in large crowd (and no, non ssb region) *add: and every one loads

[Monty Linden]

---

Alicia Sautereau wrote:

Funny, i changed it to 16 aswell and mesh items are loading faster then 32, 100 or 500,

---

 Please tell me 500 was a joke.  That would make me cry...

 

[Alicia Sautereau]

---

Monty Linden wrote:

---

Alicia Sautereau wrote:

Funny, i changed it to 16 aswell and mesh items are loading faster then 32, 100 or 500,

---

 Please tell me 500 was a joke.  That would make me cry...

 

---

 

 

 

That was not a joke and i`ve been crying inworld longer

 

I`ve had issues with rezzing mesh clothing in crowded places for quite along time, both with firestorm and the Linden viewer why i tried to up it in steps but kept failing with half invisible people on the floor lol

Maybe the default should be changed to 16 from 32 because after the first login, every one rezzed pretty fast and complete for the first time! (65 avatars)

I know it`s not my connection as everything else loads damn fast with a 120Mbit that soon will become 150, but maybe with so many people using mesh that the server is more prone to timeout even with 32? i don`t know but 16 worked like a charm

 

 

[Whirly Fizzle]

---

Monty Linden wrote:

Please tell me 500 was a joke.  That would make me cry...

 

---

lol Monty.

Unfortunately the advice to set MeshMaxConcurrentRequests to 500 is pretty common. This is often seen in several "Help" notecards that do the rounds inworld.

Just to make you cry some more :smileysad: ...

 

• "change the MeshMaxConcurrentRequests from 16 to 500"
• "I set my value to 500..."
• Change that 32 ... to something really high:
• I walk with meshmaxconcurrentrequests at 1000 lol and I have no lag

 

[Pussycat Catnap]

The link above referencing my blog is out of date. That article does note such now though - but I've left it there because it is a common opinion that higher would be better.

From a base look at the wording - higher being better makes sense: maximum concurrent mesh.

But it works differently. As max concurrent pipes to use to download mesh through - each pipe can hold multiple chunks of data at a time, and if you use too many pipes you chock your connection and shut them all off...

Back in October I noted a correction on this, and also went into detail on a number of other settings that cause similar issues for users and can all be cross confused:

http://catnapkitty.wordpress.com/2013/10/17/meshmaxconcurrentrequests-texturefetchconcurrency-http-textures-texture-thrashing-and-why-isnt-my-stuff-rezzing-yet/

 

Only noting that here because this old topic is still getting carted out in links, and it then references my older article rather than the corrected one.