Random stutters/freezing on Firestorm 6.6.8 (68380) when turning the camera/moving.

[Kitty Aeghin]

As the title says, one day when I logged in, I started to experience stuttering/freezes for several seconds when I move my camera or move my character. It just happened out of nowhere. I didn't change any settings, update my system, or anything. It was working like normal, and then the next day? it started happening. I reinstalled Firestorm and the issues persisted. I'm baffled as to what could be causing this. I tested it in various difference areas with different levels of activities, and it happened in all of them, other than an area that is literally nothing but my character. I think it might have something to do with buffering/loading textures, but, a few days ago, I could go into populated areas and it didn't have this issue.

So, I'm here, to see if any of you lovely people might have a suggestion or fix!

[Kathrine Jansma]

Do you have an exception in place for your Virus Scanner to avoid touching the Viewer Cache directory?

 

[Profaitchikenz Haiku]

To be fair I wouldn't just point a finger at Firestorm, I experienced this very behaviour last night on the Linden viewer, including being unable to run the cursor to and fro in the box where I was trying to chat in local, cam in and out smoothly, or click on things. It was limited to one particular place, though, TP-ing away cured it.

During the problems I was checking Windows task monitor but there was absolutely no sign of any CPU or memory issues, so that ruled out things like Microsoft Security Essentials trying to save me from myself.

After it was over I checked the size of the cache and saw no signs that it was bloated. That particular region has never given me such problems in the past.

[Aishagain]

I have encountered this issue in recent days, I checked my GPU use and saw no unusual activity, other than a high level of activity of reads and writes to the texture cache, during which activity, the render process appeared to be suspended.  There was no activity from either my OS or my AV, which is fully and correctly set up to "whitelist" any and all viewer functions.

The phenomenon appears to be associated with busy locations with a large  number of animated (dancing) avatars.  As a consequence I had put the issue down to the performance of my GPU (Nvidia GTX1660Ti), I am now wondering what its cause is.

Edited April 5, 2023 by Aishagain
correcting my dratted autocorrect(!)

[Nalates Urriah]

Without information on your viewer and computer, we really can't do anything but guess.

Open HELP->About... and copy past that info into your post when asking a tech question.

[Profaitchikenz Haiku]

I have just been playing around with the Linden Viewer but instead of the Windows Task manager I had the Resource Monitor open. In a region with only one other avatar I was experiencing short periods of freezing, even to the point of getting "SecondLife is not Responding" up on the window title bar. This mostly occurred when I was editing, moving around, changing camera focus to look more closely at the build, but there were some instances that seemed totally unconnected to what I was doing. I spotted that the CPU was at 100%  in resource monitor during these spells, but was not showing any changes in the task manager process monitor. There were no obvious spikes in network traffic or memory usage or disk usage that aligned with the CPU spikes .

Not doing anything for five minutes (and the other avatar in the region wasn't evidently doing much) showed a steady state in all the four areas being monitored. Even a third avatar arriving didn't cause any spiking (but both the other avatars were well outside my draw-distance).

I short, I think this is a rendering issue, and it's not a Firestorm one but is going to apply to all viewers. The CPU still gets a lot of tasks before the GPU is given jobs to do and I think this is what is causing the freezing.

For my next trick I will try turning off ALM and seeing of that changes the behaviour.

 

ETA

Standing up and taking a copy of the object I had been editing back to inventory caused 40-seconds maximim CPU activity that sent the resource monitor window white for half the period, and I wasn't able to click back into the Viewer until the end of that 40-second freeze.

Watching the resource monitor for a while longer, doing nothing, there was yet another 40-second freeze period. Resource Monitor clearly indicated it was SecondLife Viewer that wasn't responding. I hadn't done anything, the question is, had either of the other two avatars present being doing anything, and if they had, should they have been able to impact my viewer even when they were well outside draw-distance?

Edited April 6, 2023 by Profaitchikenz Haiku

[Love Zhaoying]

Not sure if anyone asked in this thread:  Did you make sure your Second Life Viewer (whichever one you used) is white-listed in your Virus / Malware scanner?

The Viewer creates many, many files (in the cache folders, etc.) and if your Virus / Malware scanner targets those folders then it can also result in issues.

 

[Kitty Aeghin]

On 4/6/2023 at 7:13 AM, Love Zhaoying said:

Not sure if anyone asked in this thread:  Did you make sure your Second Life Viewer (whichever one you used) is white-listed in your Virus / Malware scanner?

The Viewer creates many, many files (in the cache folders, etc.) and if your Virus / Malware scanner targets those folders then it can also result in issues.

 

I made sure to set this all up when I first installed SL on my new PC, but, I'll try this again and see if that might help.

 

On 4/5/2023 at 3:06 PM, Nalates Urriah said:

Without information on your viewer and computer, we really can't do anything but guess.

Open HELP->About... and copy past that info into your post when asking a tech question.

Firestorm 6.6.8 (68380) Jan  3 2023 19:59:43 (64bit / SSE2) (Firestorm-Releasex64) with Havok support
Release Notes

You are at 242.7, 210.3, 3,049.0 in Corrupted Innocence located at simhost-0c391baf284606616.agni
SLURL: http://maps.secondlife.com/secondlife/Corrupted%20Innocence/243/210/3049
(global coordinates 230,131.0, 239,314.0, 3,049.0)
Second Life Server 2023-03-24.579022
Release Notes

CPU: AMD Ryzen 7 5800H with Radeon Graphics          (3194 MHz)
Memory: 16253 MB
Concurrency: 16
OS Version: Microsoft Windows 10 64-bit (Build 19045.2728)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
Graphics Card Memory: 6144 MB

Windows Graphics Driver Version: 31.0.15.2756
OpenGL Version: 4.6.0 NVIDIA 527.56

RestrainedLove API: RLV v3.4.3 / RLVa v2.4.2.68380
libcurl Version: libcurl/7.54.1 OpenSSL/1.1.1l zlib/1.2.11.zlib-ng nghttp2/1.40.0
J2C Decoder Version: KDU v8.2
Audio Driver Version: FMOD Studio 2.02.09
Dullahan: 1.12.4.202209142021
  CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114
  Chromium: 91.0.4472.114
LibVLC Version: 3.0.16
Voice Server Version: Not Connected
Settings mode: Firestorm
Viewer Skin: StarLight (Original Orange)
Window size: 2560x1566 px
Font Used: Deja Vu (96 dpi)
Font Size Adjustment: 0 pt
UI Scaling: 1
Draw distance: 64 m
Bandwidth: 1500 kbit/s
LOD factor: 2
Render quality: High-Ultra (6/7)
Advanced Lighting Model: Yes
Texture memory: Dynamic (4096 MB min / 10% Cache / 10% VRAM)
Disk cache: Max size 2048.0 MB (100.0% used)
Built with MSVC version 1934
Packets Lost: 618/31,907 (1.9%)
April 08 2023 01:16:01 SLT

 

My PC is definitely not the problem, but here's the info.

[Henri Beauchamp]

Very similar to this issue (Windows, 16GB of RAM only, and a graphics card with lots of VRAM)... Try disabling the ”dynamic texture memory” setting (in the ”Preferences” floater, ”Graphics” tab, ”Hardware Settings” sub-tab), and set the ”Viewer Texture Memory Buffer” slider to 2048MB, and see what happens then...

Edited April 8, 2023 by Henri Beauchamp

[Aishagain]

@Henri Beauchamp

I am not sure that this is appropriate, since @Profaitchikenz Haiku

says that the phenomenon occurs on the LL viewer as well, which as far as I know, only using it very occasionally, does not have the ability to use dynamic texture memory.

Edited April 8, 2023 by Aishagain
trying to control my phone's predictive text nonsense

[Nalates Urriah]

5 hours ago, Kitty Aeghin said:

My PC is definitely not the problem, but here's the info.

You might be right... but I doubt it.

Your 2GB cache, the 2560x1566 px rez screen image, and the Ultra setting are likely problems, or at least contributing to the stutter. The almost 2% packet loss is not good. But it looks like you captured this shortly after logging in, so the percentage will go down the longer you are on... or should...

Bump your cache up to the 10GB max. If you have SSD storage make sure your Viewer's cache is on it. You want the viewer to do as FEW clean-up runs as possible on the cache.

If you want to see if cache-clean-up is the cause, bump the setting and go in-world, and test.

The viewers use an indexed cache. So file lookup time is NOT a factor in viewer cache size. So go big. And this is not the setting Henri is talking about above. Definitely try his suggestions too.

I suggest you tweak your graphics settings. The default ULTRA settings are a generalized, generally best for most machines sort of thing. You can likely do better. The first article I wrote on tweaking viewers for SL explains many of the terms used. It is Graphics Tweaking for Second Life (2010). A new article based on 2016 recommendations from NVIDIA is NVIDIA Settings 2016. I suspect NVIDIA's recommendations for SL have not changed since then. So I suggest you start with their recommendations. Experiment from there.

I have several preset graphics settings for different times in SL. So, for dancing, crowded places, flying, sailing, etc.

PS: Also, check the region's performance. Press Ctrl-Shift-1 to open the Viewer Stats. Look for the Simulator section. Check the numbers for Time Dilation and Sim FPS. If the region sucks so will your performance.

This morning I tested in Peak Lounge after a few tweaks to my system, which is getting old. After most everyone rezzed and my DD at 512m I had good performance. Sweeping my camera through the place had only minor jerks when doing a 360. When I dropped DD to 128 was smooth enough that moderate speed sweeps had almost no jerks and slow camera sweeps had no noticeable jerks.

 

Edited April 8, 2023 by Nalates Urriah
Adding info

[Henri Beauchamp]

39 minutes ago, Aishagain said:

I am not sure that this is appropriate, since @Profaitchikenz Haiku

says that the phenomenon occurs on the LL viewer as well, which as far as I know, only using it very occasionally, does not have the ability to use dynamic texture memory.

It depends on what version of LL's viewer is used: the PBR viewer is sizing ”texture memory” dynamically...

It does not hurt to try anyway, and might well at least solve the issue for FS...

Also, the recommendations I made in the post I linked to (especially with regard to the swap file, which reallocations could incur such freezes) are no less valid...

Edited April 8, 2023 by Henri Beauchamp

[Profaitchikenz Haiku]

I have been doing some testing and have the following early results:

The latest LL viewer and latest Firestorm both show the CPU spiking.

Catzip and Kirstens, which haven't been updated for a while, do not show the CPU maxing out, but instead they show a lot of disk spiking when turning around. They don't freeze up though.

Currently I am hypothesising that the two recent viewers I am trying are holding a lot more in RAM and using the CPU a lot more, the two earlier viewers are not using so much RAM and are accessing the cache more?

I'd better try with Henri's viewer next.

 

[Rowan Amore]

6 hours ago, Kitty Aeghin said:

Packets Lost: 618/31,907 (1.9%)

Doesn't that have a serious effect or not for this specific issue?

[Henri Beauchamp]

11 minutes ago, Rowan Amore said:

Doesn't that have a serious effect or not for this specific issue?

This is most likely the result of the freezes, and not their cause (while frozen, the viewer cannot process the incoming packets and thus looses them).

[Profaitchikenz Haiku]

Ok, no signs of freezing in CoolVlViewer in the places where I saw it with the other two viewers.

However, the freezing in the places where it had been most observable was less today. Make of that what you will.

 

ETA Correction, just came to a halt for several Second in FS when moving across a room. I noticed that in that period the CPU usage yo-yo-ed wildly from 100% to 0% three times, the drops to 0% were of far shorter duration than the 100% periods.

Edited April 8, 2023 by Profaitchikenz Haiku

[Profaitchikenz Haiku]

I'm just trying to get a sense of perspective on this, I don't want to set people off on sharpening the stakes and lighting the torches before climbing the hill to the lofty developer's Frankencastles.

The misbehaviour isn't totally predictable.

The misbehaviour is specific to certain regions.

The regions have a lot of mesh buildings but few avatars

The regions in question are fully cached (or should be by now) so the network component is simply the list of what is where and with how much festooned on the surfaces.

With all black-box testing, the results nearly always raise more questions than they answer, or at least cause a lot of FUD.

Edited April 8, 2023 by Profaitchikenz Haiku

[Nalates Urriah]

1 hour ago, Rowan Amore said:

Doesn't that have a serious effect or not for this specific issue?

I agree with Henri. I have in the past lost connection with the SL servers and eventually been logged off. While I could not move or stop moving, depending, I could spin in place. No jerkiness in the camera sweep or viewer mini freezes.

Edited April 8, 2023 by Nalates Urriah

[Henri Beauchamp]

1 hour ago, Profaitchikenz Haiku said:

Ok, no signs of freezing in CoolVlViewer in the places where I saw it with the other two viewers.

Not a surprise to me: I spent a considerable amount of time fine-tuning the textures algorithm, and then experimenting and stress-testing it, and did so on 4 different PCs, and in many different situations (over crowded clubs, scenic super mesh-heavy and texture-heavy sims, hour-long travels across sims in the main land with 512m DD, etc).

For the benefit of any TPV developer reading this, here are my findings:

• At least with NVIDIA cards, and even for the ones with 8GB of VRAM, you should never overshoot 3GB of bound texture memory, or will get second-long freezes; this lead me to modify the discard bias algorithm to properly react in time, before such an occurrence would happen (often seen when turning your avatar around in textures-heavy sims and with large draw distances), and to cap the bound texture usage ”soft limit” to 2.5GB by default, even when the viewer is configured to use more than 6GB of texture memory.
• Enough *texture* VRAM must be left free (10% of the total texture VRAM as detected on viewer startup, or 1GB, whichever is the smaller): should the VRAM get too full, the driver will spill textures over the RAM, causing seconds-long freezes. This poses a problem with iGPUs (no VRAM, so no GL call to get the free VRAM) and with AMD GPUs under Windows (their OpenGL call for reporting the free texture VRAM is bogus, and most often reports silly huge numbers); this can be worked around by assuming that the texture VRAM consumed is twice the amount of bound GL textures.
• Of course, you must make sure there is enough free RAM (physical RAM, and not virtual one which accounts for the swap space), else the OS (and especially Windows) will swap, and you will get very long freezes.
• The texture bias calculation algorithm must be made smart enough to avoid entering a yo-yo effect (bias increasing too fast, then textures getting blurry and memory getting massively released as a result, causing a bias excessive decrease and an immediate massive increase of textures memory consumption, etc): this became more likely to happen since the image decoding became multi-threaded (the textures decode so fast, that huge memory consumption variations can now happen in under a second, i.e. too fast for a discard bias readjustment to take effect).

Edited April 8, 2023 by Henri Beauchamp

[Aishagain]

I hope I am not being previous in saying this but after some (not a great deal and with a fairly full texture cache) testing on some tricky textured areas under moving shadow conditions, when I turn off dynamic texture memory and rely simply on the value given by my viewer ie 2048MB, I am getting a much less jerky and hesitant rendering that I would call smooth and no obvious penalty in either quality or FPS.

Of course I need to do further testing in challenging situations but these initial results are both surprising and encouraging almost in equal measure!

This is using Firestorm 6.6.8 release on Windows 10 with 32GB RAM, CPU is Ryzen 9 3900X, GPU Nvidia GTX1660Ti (6GB VRAM)

Edited April 9, 2023 by Aishagain
punctuation and spelling

[Profaitchikenz Haiku]

9 hours ago, Aishagain said:

but after some (not a great deal and with a fairly full texture cache) testing on some tricky textured areas

I am wondering if this is the significant area: what I think I see is that with a completely empty cache, there is less hesitancy as everything stream in across the network, but with everything cached there seems to be some sluggishness, maybe checking the validity of the textures, maybe checking dates, I can'tr tell, but what I am seeing with the freezing only seems to happen once I have a region cached.

Edited April 9, 2023 by Profaitchikenz Haiku

[Aishagain]

For what it is worth I have created a FS JIRA about this and put down my fairly inexpert findings, feel free to contibute or criticize as you see fit.

FIRE-32868

Edited April 9, 2023 by Aishagain

[benchthis]

On 4/8/2023 at 3:17 AM, Kitty Aeghin said:

Disk cache: Max size 2048.0 MB (100.0% used)

Looks like your cache might be full? if you go to preferences you can increase cache space. Also you can clear cache from time to time too in preferences. 

[benchthis]

On 4/8/2023 at 3:17 AM, Kitty Aeghin said:

Bandwidth: 1500 kbit/s

If your able to in preferences you can increase your internet speed settings. I can't remember which Linden meeting it was in the past regarding a problem with the cache processor not being able to keep up with max internet speeds, bottlenecks and generates undesired performance issues. I usually bump my cache up to 8 gigs or max and I try not to max the internet speed because of the bottle neck issue. 

[Cali Souther]

The latest Firestorm has been nothing but trouble for me!   Same computer,  so....  

Freeze, kicks, lose all my settings!   I get kicked out,  come back and my clothes are different colors,  etc.

Very frustrating!