Sign in to follow this  
Jackson Redstar

meshmaxconcurrentrequests - does anybody know the real setting?

Recommended Posts

it appears there are 2 camps on this debug setting - some say boost it from the default 32, and Firestorm is now says it needs to be lower 

I shoot weddings and this sometimes becomes a BIG issue - the mesh stops loading. Half loaded brides, bridal party, guests, anybody have the correct answer? 

the performane of my machine is fine - usualy about 20fps in "ultra" at a wedding, but on occasion, it appears, mesh overload

Share this post


Link to post
Share on other sites


Jackson Redstar wrote: [...] it appears there are 2 camps on this debug setting - some say boost it from the default 32, and Firestorm is now says it needs to be lower [...]  anybody have the correct answer? [...]


As usual with these things, there’s no single “correct answer for everyone” –if there was, that is, if there existed a specific value that’d work best for everyone, then there wouldn’t even be a changeable MeshMaxConcurrentRequests setting, because no one would ever need to change it to what would therefore always be a worse value.

Now here, here, here, here and here are a few pages describing the issue to some extent; regrettably they’re all somewhat outdated discussions –I haven’t been able to find any more current, but I’m sure with some patience they can be found–, but the gist of the matter is this: the default values were moderate (make that “Linden Lab-style moderate”, i.e. perhaps a bit too conservative) but usually effective enough, yet if you experienced problems, you could always try changing the setting... and, actually, you were better trying both ways –raising the value, and lowering it, since depending on many conditions including your own connection’s, either way could solve or at least ameliorate your problem.

But, more recently, many changes have been made to how SL viewers fetch mesh information through HTTP, and some of these changes mean that changing MeshMaxConcurrentRequests was no longer quite as necessary; in fact there were –and still are– talks about clamping it, and how setting it too high could in fact cause trouble, for you and everyone else. So if you’re experiencing mesh loading problems, by all means do try changing this value, but not too much, and do try going both ways (raising it and lowering it); it’s also worth trying many other connection-related settings, such as HTTP, bandwidth, connection port, making sure your router or firewall isn’t blocking or QoS’ing anything... and of course having an up-to-date viewer, since some of these fetching improvements I mentioned are in fact quite recent.

Share this post


Link to post
Share on other sites


SaraCarena wrote:

I don`t think meshmaxconcurrentrequests is active anymore, it should be Mesh2MaxConcurrentRequests now.


That's correct.  The older setting became ineffective around a year ago.

OP may be experiencing CDN issues as reported here and elsewhere.

 

Share this post


Link to post
Share on other sites

I have a feeling that a lot of connection-related problems could need different answers now that so much has moved from UDP to HTTP, and there is the CDN.

What does the "Bandwidth" setting actually control?

What effect does the CDN have at my end of the connection? Can that traffic mess up the mostly UDP command and control traffic from the Server? That's certainly consistent with the horrible warnings I find else-net, but I don't know the details of just what you did. (You personally and the Lab as a whole)

I sometimes find myself wondering if I am even asking sensible questions.

Share this post


Link to post
Share on other sites

well, whether it is MeshMax or MeshMax2, (but thanks for clearing that up - i was wondering why there was a meshmax2)  I suppose what would be noce to know, is, what, if anything, can be done to download what seems like log jammed mesh. Relogging didn't help, I even switched viewers, that didn't work either

 

and when you are shooting a wedding and this happens, the urge to "calibrate" the viewer with a sledgehammer can be almost overwhelming!

Share this post


Link to post
Share on other sites

I understand how frustrating and messy it looks to have half loaded avatars in a scene, must be infuriating if you`re trying to film a wedding!

I filed a jira on this back in March 2014, it was just after (I think) Get2Mesh but before CDN were deployed.

https://jira.secondlife.com/browse/BUG-5414

The issue is still happening now under some (unfathomable) circumstances with the current SL release viewer. Big Daddys club is a good place to test this because there`s usually 40 or more av`s there 24/7. The texture console reports no log jam when av mesh fails to load. Interestingly the manager at that club often fails to have some part of his mesh outfit load. He always wears a group tag, changing the group tag poofs the stubborn mesh into existence.

I don`t think there`s a magic debug setting that will cure your issue, try asking av`s that don`t load to wear or change a group tag. Does this happen only if it`s a wedding with lots of av`s?

I remember reading two things that may be related to this;

Buried somewhere in the sl wiki "...mesh attatchments for avatars are unlimited but there`s no guarantee they`ll show in world..."

Buried somewhere in the minutes of the server beta user group http://wiki.secondlife.com/wiki/Server_Beta_User_Group

"... we hoping to be able to lift the throttles for av mesh attatchments..." Maestro Linden.

These are not direct quotes because I don`t have time to find them but the gist is accurate. Both were pre CDN

@Monty Did the deployment of CDN make those throttles irrelevant?

Share this post


Link to post
Share on other sites

thanks for that. I remember way back, I think Exodus viewer, had a scene refresh. Reloaded the entire scene. Maybe wouldn't with with CDN and all, but something along that line would be great  to tell it - try again!

Share this post


Link to post
Share on other sites


Jackson Redstar wrote:

thanks for that. I remember way back, I think Exodus viewer, had a scene refresh. Reloaded the entire scene. Maybe wouldn't with with CDN and all, but something along that line would be great  to tell it - try again!

If I remember right, the old Exodus Scene Refresh just quickly changed your active group tag to none and then changed it back.

The trick of changing active group group tag to cause a scene reload used to work pretty well on pre-interesting viewers but it no longer works. Infact, it didn't just stop working, it actually causes the scene loading to stop dead at whatever stage it was at and never finish, forcing you to teleport to a different region, wait until the old scene objects are killed and then TP back. Sometimes that doesn't even fully work and you have to relog to get the scene to load.

See BUG-6299 - Scenes will never load completely if changing active group tag to a different group while a scene is loading

Share this post


Link to post
Share on other sites


SaraCarena wrote:

@Monty Did the deployment of CDN make those throttles irrelevant?

Probably not.  I think they existed for reasons other than asset download.  Having to do with scene description (i.e. interest list) and some heavy-weight operations in the simulator.

@Carol  Yes, the network architecture of SL has changed quite a bit in the past year.  So it's time for a new picture!  :matte-motes-evil:  What follows gives some details on the three main components (viewer, servers and now CDN), the communication between them and what viewer debug settings affect which communication streams.

Viewer, Servers and CDN.png

To the left (in red) are pieces of the viewer.  To the right (in blue) are simhost/simulators and other backend services.  And at bottom (in green) are new CDN services.

Solid lines with arrowheads are communication paths, either UDP or TCP/HTTP.  Dashed lines indicate legacy communication paths that are now or soon will be deprecated, obsoleted and/or deleted.

Ball-and-stick objects between a communication path and a text label indicate a viewer debug setting and the communication path or paths that setting influences.  These, too, are in solid and dashed flavors.  The latter indicating obsolescence.  And as always, at least one error crept into my diagram.  In this case, the 'HttpPipelining' setting only influences mesh and texture communications.  Inventory is currently unaffected by this setting.  [image has been corrected - ed]

Generally, things are moving in the direction of simplification and less resource conflict.  The mesh and texture HTTP traffic, which is usually the greatest load, tends to part ways with the UDP traffic a few network hops after a user's router or modem.  Lacking TCP's throttling mechanism, UDP often wins in a fight (give-or-take the efforts of fairness algorithms along the path).  Allowing UDP to overrun the path between viewer and simulator does still degrade the experience and the bandwidth setting remains an effective tool for avoiding this problem.

Other settings should generally be left alone.  A lot of bad advice was spread around in the community in an effort to work around throughput problems.  We're trying to undo that history and get back on track with more typical (albeit aggressive) HTTP patterns.

 

Share this post


Link to post
Share on other sites

Monty Linden wrote: So it's time for a new picture! 

And a very helpful picture it is, too -- thanks for posting it !

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this