Jump to content

SecondLife randomly stuttering/slowing down.


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

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

Recommended Posts

So, i've started to experience random stuttering/slowdowns in SL. My computer is definitely good enough to run the game, and it only started happening recently, and I'm unsure what I could do to alleviate it. I have a feeling it has something to do with loading in textures/avatars, but even after everything is loaded, the same issues persist. It's overall not a huge issue, but, it is quite annoying.

Here are my current graphic settings. As for my computer specs, here you go:

Ryzen 7 5800H
NVIDIA RTX 3060
32GB of DDR4 3200MHz RAM
Windows 10 Pro.

I have all the latest driver updates as well.

  • Like 1
Link to comment
Share on other sites

Do you have vsync on in the hardware tab?

Firestorm for me will sometimes enable vsync after an update even though I keep it off. Vsync on SL is a bit buggy and I’ve found it causes stutter and slowdown even when it’s working as intended and attempting to keep the framerate at a stable level. I found it fluctuates a lot between 30 and 60 when enabled.

Link to comment
Share on other sites

This is an issue that I've been looking into a lot lately.  I beleve that it is caused (partly at least) by the swapping between your GPU's VRAM and system RAM.  Like you I have 32GB DDR4 RAM with an AMD Ryzen 9 3900X CPU, but once the texture loading exceeds the value set (somewhat arbitrarily) for your GPU in Dynamic Texture Management (look in Preferences>Graphics>Hardware settings) which I assume you have activated.  I also assume you are using Firestorm (if not you will grossly underuse the VRAM available on your 3060).  I found disabling DTM and running at the arbitary 2048MB limit imposed for my GPU (GTX1660Ti 6GB) resulted in a smoother run but quite unacceptable levels of texture thrashing.

I have, as yet,  not found a "sweet spot" between texture thrashing and stuttering and I am thinking that the balance between the two is something you may well need to establish by trial and error yourself.  Given free reign, Firestorm is a real resource-hog when it comes to VRAM use, and I doubt if it is unique in that regard.

There may well be more accomplished minds able to offer you more effective solutions.  All I can say is that V-Sync is a poor function and results in very poor FPS on occasions.  Avoid it like the plague!  I have tried various frame-rate limiters, both the NVidia one in the GPU's own control Panel and the Firestorm one and while neither are brilliant, the Firestorm one is better.

ETA : I might add that I was sufficiently irritated by this phenomenon that I raised a support request in the Firestorm JIRA, but to date I have had no useful response.

Edited by Aishagain
further info
  • Like 1
Link to comment
Share on other sites

13 hours ago, Aishagain said:

This is an issue that I've been looking into a lot lately.  I beleve that it is caused (partly at least) by the swapping between your GPU's VRAM and system RAM.  Like you I have 32GB DDR4 RAM with an AMD Ryzen 9 3900X CPU, but once the texture loading exceeds the value set (somewhat arbitrarily) for your GPU in Dynamic Texture Management (look in Preferences>Graphics>Hardware settings) which I assume you have activated.  I also assume you are using Firestorm (if not you will grossly underuse the VRAM available on your 3060).  I found disabling DTM and running at the arbitary 2048MB limit imposed for my GPU (GTX1660Ti 6GB) resulted in a smoother run but quite unacceptable levels of texture thrashing.

 

I see this too on occasion and also have noticed with VRAM is at its limits (in my case 8g) or just before its limits, it can do this, but not always. I always suspected it could have something to do with where the additional memory is coming from. I have 32g RAM (3200mhz) and of course all SSD drives . But since it doesn't seem to do it all the time, who knows!

Link to comment
Share on other sites

I am a tad surprised that this topic has attracted so little apparent interest.

This has been repeated on other threads on this issue.

Does no-one care or is it just a very few of us that experience it?

If the latter, why?

Link to comment
Share on other sites

I have experienced what I think is the same thing, its an approximately 10 second period of stuttering/choppy frame rate that resolves itself.

It isn't a throttling issue, CPU and GPU temperature remains stable and weirdly viewer reported frame rate stays constant despite the framerate actually reducing to maybe 10FPS during the time it is happening.

Doesn't appear to have any trigger that I can determine and happens rarely. I think the theory above about it being related to some sort of video memory bug might be correct, it's almost as if Firestorm is doing something intensive behind the scenes (for no obvious reason) but it resolves itself relatively quickly and it's hard to determine what has happened.

 

edit: I will try using RivaTuner to monitor the GPU and catch it happening, there might be some indication it is related to video memory

 

Edited by AmeliaJ08
  • Like 1
Link to comment
Share on other sites

1 hour ago, AmeliaJ08 said:

It isn't a throttling issue, CPU and GPU temperature remains stable and weirdly viewer reported frame rate stays constant despite the framerate actually reducing to maybe 10FPS during the time it is happening.

What you describe appears to be the action of the V-Sync function as the viewer's FPS falls below the refresh rate of your monitor.  To avoid "tearing" of the video (a phenomenon I barely understand since I have never knowingly seen it) by rendering an incomplete frame, V-Sync reduces the frame rendering rate to a fraction of your monitor's refresh rate, usually 1/2 though on occasions it might be less.  That is an undesirably slow frame-rate for most folk which is why I so forcibly condemn it.

The stutter seen at other times can be closely correalated with VRAM and system RAM use by the viewer and I assume reflects the lag difference between accessing on-board VRAM on the GPU and accessing system RAM.  Whether that is correct or not it is a real phenomenon and may or maybe not a result of some arcane video memory function.

That I don't see the stutter when Dynamic Texture Memory management is disabled my be a complete red herring since with it off, the texture thrashing that results is considerably less desirable than the stuttering (for me, YMMV).

Edited by Aishagain
spelling (I kan't spel)
  • Like 1
Link to comment
Share on other sites

6 minutes ago, Aishagain said:

What you describe appears to be the action of the V-Sync function as the viewer's FPS falls below the refresh rate of your monitor.  To avoid "tearing" of the video (a phenomenon I barely understand since I have never knowingly seen it) by rendering an incomplete frame, V-Sync reduces the frame rendering rate to a fraction of your monitor's refresh rate, usually 1/2 though on occasions it might be less.  That is an undesirably slow frame-rate for most folk which is why I so forcibly condemn it.

The stutter seen at other times can be closely correalated with VRAM and system RAM use by the viewer and I assume reflects the lag difference between accessing on-board VRAM on the GPU and accessing system RAM.  Whether that is correct or not it is a real phenomenon and may or maybe not a result of some arcane video memory function.

That I don't see the stutter when Dynamic Texture Memory management is disabled my be a complete red herring since with it off, the texture thrashing that results is considerably less desirable than the stuttering (for me, YMMV).

I did have V-Sync enabled, I've turned it off and will report back to see if I see this happen again.

Is Firestorm V-Sync just broken? it appeared to happen completely randomly, the first time I thought it must be throttling due to it seeming so similar but turns out no and the way it just resolves itself seemed very odd.

 

Link to comment
Share on other sites

4 hours ago, Aishagain said:

I am a tad surprised that this topic has attracted so little apparent interest.

This has been repeated on other threads on this issue.

Does no-one care or is it just a very few of us that experience it?

If the latter, why?

Because this game is ancient and barely functions, it can be such a massive variety of things that are causing the problem, it could be fixed with the next viewer update with no fanfare entirely by accident, it’s hard to figure out an exact cause. It’s like trying to figure out “why does my car run rough” and they’re driving a 30 year old car, it can be literally dozens of things.

My guess was vsync, others noted dynamic vram allocation, both are possible causes to the problem, but the problem still could be something else entirely.

The only time I’ve ever experienced stutter and inconsistent framerate lag in this game was with vsync on. 

Link to comment
Share on other sites

I'd like to add another suspect to the list:  After spending 3 hours on a parcel with 40 other avatars, my viewer's rendering takes a dirt nap when I step into another parcel in the same region when the parcel I am entering has disabled "Avatars on other parcels can see and chat with avatars on this parcel".

Link to comment
Share on other sites

5 hours ago, AmeliaJ08 said:

Is Firestorm V-Sync just broken?

I don't think it is broken as such, I suspect that it just operates in a very clunky and unhelpful way in SecondLife.  In games where the complexity of scene to be rendered does not change as much it may well work as intended but others more technically minded can explain its operation better than I. 

@Beq Janus?

Edited by Aishagain
  • Like 1
Link to comment
Share on other sites

On 6/21/2023 at 10:31 PM, Aishagain said:

I don't think it is broken as such, I suspect that it just operates in a very clunky and unhelpful way in SecondLife.  In games where the complexity of scene to be rendered does not change as much it may well work as intended but others more technically minded can explain its operation better than I. 

@Beq Janus?

V-Sync works exactly as designed (it is just the OpenGL Vsync; we do nothing else) it is just that that design is a very very very poor choice in SL, so I would very rarely suggest anyone use it. You are far better off simply using the viewer "limit FPS" to cap the FPS to a defined value. As for the design of V-Sync, you are correct; it is more acceptable in a game where you are not subject to the effects of user-generated content, where FPS can be predictable and more stable. V-Sync works by waiting for the next full draw to complete before switching the screen; as a result, if your monitor is 60Hz (60 refreshes per second - or one refresh every 16.7 milliseconds), but you are getting 58fps (one frame takes 17.3milliseconds). You will miss the screen refresh every time by a millisecond, the GPU/driver will then wait until the next refresh to complete that frame, so you only get 30FPS effectively because you are waiting for every other frame. Like I say, don't use it; it's a dumb mechanism for our use case.

There was/is an issue with the default value of V-Sync somehow being restored when you installed a new version. I think that was fixed in the latest release, or if not it is in the current beta round. That is a bug, for sure, but not a bug in how V-Sync works, just that it enables it when you don't expect it to. 

With regards the Jira etc., sorry for the lack of response; Jira responses are often slow (there are so few of us) and for my part, I've not been pulling my weight as I've been barely able to spend time on Viewer dev for months now due mostly to being too busy in RL (work and family, nothing bad, just lots of it 🙂 ). As a result, I've not been able to look at a number of things that were on my to-do list. There are several things like missing meshes, area search weirdness, and other things screaming for attention, so I hope RL will give me a break in the coming months. We are also balancing the fact that we have a massive update in the form of PBR coming soon, so attention is also being directed there. 

 

  • Thanks 1
Link to comment
Share on other sites

On 6/21/2023 at 6:30 PM, Ardy Lay said:

I'd like to add another suspect to the list:  After spending 3 hours on a parcel with 40 other avatars, my viewer's rendering takes a dirt nap when I step into another parcel in the same region when the parcel I am entering has disabled "Avatars on other parcels can see and chat with avatars on this parcel".

Interesting, this is repeatable?

Link to comment
Share on other sites

17 hours ago, Ardy Lay said:

Yes.  It  happens to me at approximately the same time every Saturday Night.

How peculiar, there's a bug/feature/behaviour that we've been puzzling over for a while where the viewer's framerate tanks and does not recover. We've had a few reports, but nothing is consistent enough to reproduce it under observation. While "3 hours in a parcel with a crowd, then move to a shielded parcel" is not going to be an easy test to reliably reproduce, but it is at least a well-defined scenario.It might be worth looking at your logs after it tanks to see if there is anything looping or behaving in a clearly different fashion.

Link to comment
Share on other sites

1 hour ago, Beq Janus said:

How peculiar, there's a bug/feature/behaviour that we've been puzzling over for a while where the viewer's framerate tanks and does not recover. We've had a few reports, but nothing is consistent enough to reproduce it under observation. While "3 hours in a parcel with a crowd, then move to a shielded parcel" is not going to be an easy test to reliably reproduce, but it is at least a well-defined scenario.It might be worth looking at your logs after it tanks to see if there is anything looping or behaving in a clearly different fashion.

Oh, it's a short nap.  The viewer recovers after a few seconds.  I suppose that "unloading" is at least as hard as "loading", and, in the circumstance I describe, 30+ avatars are unloading all at the same time.

Link to comment
Share on other sites

38 minutes ago, Ardy Lay said:

Oh, it's a short nap.  The viewer recovers after a few seconds.  I suppose that "unloading" is at least as hard as "loading", and, in the circumstance I describe, 30+ avatars are unloading all at the same time.

Ahh, I see; that's a different scenario, but as you say, expiring stuff can be as much work. Though ideally,  that wouldn't affect the fps, so there's stuff that could be done there. It is, of course, one of those wonderful features of SL that what we consider "30 avatars" may be 1000s of objects and 100s of textures.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 356 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...