Jump to content

Frame time oddity


ChinRey
 Share

You are about to reply to a thread that has been inactive for 2838 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

There was a question in the Answers section here (https://community.secondlife.com/t5/Controls/Menus-are-not-displaying-in-a-zone/qaq-p/3040058) which turned out to be about a heaviy overloaded sim.

Nothing unusual about that of course but when I checked the stats, it turned out total frame time was just 22-23 ms. Script time 8-12 ms, Spare Time stuck at 0.000 ms and Scripts Run between 20 and 40%.

I would have expected an overloaded sim to have a much longer total frame time but that doesn't seem to happen in this case. The sim just had to try to make the best out of the default 22-and-a-bit ms before the next frame kicks in.

Has there been a change in how the system handles overloaded sims recently?

Link to comment
Share on other sites


ChinRey wrote:

There was a question in the Answers section here (
) which turned out to be about a heaviy overloaded sim.

Nothing unusual about that of course but when I checked the stats, it turned out total frame time was just 22-23 ms. Script time 8-12 ms, Spare Time stuck at 0.000 ms and Scripts Run between 20 and 40%.

I would have expected an overloaded sim to have a much longer total frame time but that doesn't seem to happen in this case. The sim just had to try to make the best out of the default 22-and-a-bit ms before the next frame kicks in.

Has there been a change in how the system handles overloaded sims recently?

It sounds like it's working the way it has been for quite a while. Scripts are only allocated a maximum amount of time they can run in a frame and if they won't all run in that slot they take turns in a rotation. Also now things like textures and meshes are sent in parallel streams from the CDN nodes rather than being routed directly through the server. The time it takes to send these things isn't reflected in the frame timing any more.

Link to comment
Share on other sites


Theresa Tennyson wrote:

It sounds like it's working the way it has been for quite a while. Scripts are only allocated a maximum amount of time they can run in a frame and if they won't all run in that slot they take turns in a rotation.

You're right of course, that's how it's supposed to work and should work. But I've been to sims with frame times well above 40 ms and scripts still running fairly normally - although of course rather slowly.

Maybe I should rephrase the question: Are the servers stricter about keeping sim fps up now than they used to be?

Link to comment
Share on other sites

Maybe somebody knows of a subtle change that would account for the reportedly different behaviour in that region, but it looks pretty normal to me. I don't think script load on its own is expected to extend frame time, and scripts seem to be the main load on this sim. There's some minimum time-slice that scripts are assured each frame, and if you watch the stats on this sim long enough you'll notice frames briefly extend when other loads are so high that even that minimal script time isn't available.  

Here it seems to be Simulation and Agent times that push those dilation blips, probably due to new arrivals loading into the sim.

It's basically like a shopping event sim, but with more exposed, heavily-scripted genitals.

I notice the region has a big "shopping district" with many scripted vendors, so when script lag gets heavy enough I imagine shopping gets less fun, too.

Link to comment
Share on other sites


Qie Niangao wrote:

Maybe somebody knows of a subtle change that would account for the reportedly different behaviour in that region, but it looks pretty normal to me.

It may simply depend a lot on the number of avis. This is midweek and too early in the day for most Europeans and too late for most Americans, and there are still 40+ people there and script failure well over 50%. Imagine how that place will be when it's really crowded!

 


Qie Niangao wrote:

It's basically like a shopping event sim, but with more exposed, heavily-scripted genitals.

And lots of heavily scripted furntiure and probably not the kind of clientelle who are too careful with the avatar load and who knows how many of the merchants at the shopping district still use a certain once popular vendor system notorious for it's heavy script load...

But even so, I have been to sims where the server dropped the fps rather than the scripts so something must have changed for the better since then. It's been a while since I noticed it though, so it's probably not a very recent change and not relevant to the current question in the Answers section.

Link to comment
Share on other sites

that has been the norm at SDI for years. scripts are just about saturated even right after a restart, when almost no avatars are there.

simulators do have fewer jobs to do than they did in the past, for example the move of common asset fetches to a CDN saved them countless lookups and deliveries. they have more room to run now, before the main simulation part can't keep up.

 
 
Link to comment
Share on other sites

When I went to Skinny Dip Inn and noticed that with 60 agents in the region, there was no spare time left. The total average script timing of all agents in the region consumed 3.5ms - 4.0ms of timing the rest most likely are being consumed by all the vendors in the region. There may even be a few that are using excessive script timing. A look at Top Scripts will show this info. What stood out though was the number of active scripts in the region, which was over 14000. The average script count of all guests was under 4000 leaving 10000 for everything rezzed in the region. This is an excessive amount and should really should be less than half that value.

There are many events going on in the background that are not reported to sim stats. Some of the top events that have the most severe impact the sim are script loading/unloading and mesh physics data caching. The former occurs with scripted attachments entering and leaving the region as well as with rezzing. The latter occurs with any mesh object whose physics data doesn't exist on the server. The server downloads and caches this data before the entire object is released to the server for rendering, whether it be a rezzed or attached mesh object. While this data is being requested and is caching, the entire asset handling thread is waiting on this caching to finish before another mesh's physics data can be cached. This blocks other events on the same thread and causes major region FPS fluxuation, delayed rezzing, delayed attaching and a delay for attachments to appear on guests entering a region. See https://jira.secondlife.com/browse/BUG-8946

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2838 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...