Red_

Extreme FPS Drops, very consistent pulses

Recommended Posts

# A title dictating what the bug you are reporting is - ūüĎć

 

 

# What happened - I've put off reporting this because I was doing my own testing to see if I could figure out what was causing this. I thought maybe it was from my collection of wagoners, but I dismissed all of them and I'm still having extreme FPS drops which you can see in the video. I was told maybe it could be the lamps on my deed or possibly the massive mine that my husband and I have dug underground (All the graphics from the mine underground as well as the overworld terrain is loading all at once, so maybe that's causing FPS drops?).

 

These FPS drops only occur on my own deed and/or on other large deeds (that seem to have alot of stuff on them).

 

And another note, none of my graphic settings I've changed since I started playing wurm online over a year ago. I have them on the lowest settings, but even if I were to change the settings (which I did in my own testing temporarily), I'm still getting those FPS stutters/drops. 

 

Unfortunately, I'm out of ideas, and I have no solutions to offer, but my hopes is if I post about it here someone on the wurm team can investigate? These FPS drops are making the game almost unplayable -- especially considering ticks are important for sleep bonus, organizing my junk properly (I've accidently put low ql items in with higher ql items due to the FPS tick making my game stutter), and this all potentially interferes with other tick related events in game on my end.

 

If there's anything that I can do to help fix this issue or any advice I'm happy to take a listen, as this is making me lose my mind, and even making me so frustrated at times I don't even want to play the game.

Thank you.

 


# What you expected to happen - No Frame Drops Please :(

 


# Steps to reproduce - See video:

 

  • Like 4

Share this post


Link to post
Share on other sites

i have it since i remember i wouldnt be suprised if it was ram thingy

Share this post


Link to post
Share on other sites

I've been trying to gather some performance data on this to try and help supplement this and have found the following out.

 

While AFK on deed, game minimised, you can see the following happening

 

GPU: 

 

The drops in usage are whenever we experience a drop in FPS

1c3c99a9b7471fb242acdc7799723c58.png

 

CPU: 

 

The spikes in CPU Utilisation are whenever we experience an FPS drop (ignore the slight upwards curves, it's the sharp spikes)

eba0ab7bd1179497471a98bb92f286b3.png

 

Disk:

 

This one is a bit more of a guess, however I've also noticed it does spike around the same time that this happens

35b8227b6c65fc3139105411723aeae8.png

 

It is worth noting this is while AFK without Wurm open, as soon as I open it I will still have the exact same drops, at the exact same time

 

The screenshots were taken at separate times and weren't all on the same cycle of lag spikes, you can see from the gaps that this appears to be a regular thing that happens on a timed interval, what it is exactly I'm not too sure of

 

I've noticed if I venture around deed for a long period of time my game can grow in Memory Usage from 2GB -> 7.8-9GB, as soon as I leave deed and go further down the highway, it suddenly has an extremely large FPS drop, for 2-3 seconds, then my memory usage will drop back down to 2GB, and then performance will be fine again.

Once returning to deed, I will have very small, sometimes unnoticeable FPS drops, and then it will slowly build back up to the point as you can see in Red's video

 

I've tried this on Both Windows 10 and Windows 11 on completely fresh PC builds to try and avoid any potential conflicts and this also seems to linger around

 

Hopefully that helps, I can get more performance metrics if needed

 

Edited by Blueheart
I can't spell
  • Like 1

Share this post


Link to post
Share on other sites

Sounds like this is a garbage collection issue and the spikes are java cleaning out all the extra data which can take some time when it builds up that much. I took down some info from red about where this was happening for them to look into if anyone else would like to add to that info it would be very helpful in tracking down where all this extra data is building up from for ya so quickly. Feel free to pm it to me if you don't want to post it publicly.

  • Like 2

Share this post


Link to post
Share on other sites

can you post information for cpu / video (both for relative performance) / ram / disk(both for performance around caching/reading/writing/heapsize/etc) 

 

profile configuration - could show how much you stress on loading highest ql textures, distance, loading threads, etc

 

afaik large heapspace + garbage collector could lead into something like that, a lot of information to process and long pause when that happens

 

 

Share this post


Link to post
Share on other sites

Bump (kinda) - Spoke to a GM about this today, and a few friends, its happening for a lot of people on deed

 

Details specs/logs/whatever can be provided, preferably over a DM though, my basic specs have been posted above which is more than enough information for now

 

Appreciate it

 

Also if Debugging works on the Wurm client I'm more than happy to get this enabled and provide some logs, if anyone is aware on how to do that

Edited by Blueheart
Added note about Debugging
  • Cat 1

Share this post


Link to post
Share on other sites

Set an environment variable called _JAVA_OPTIONS to '-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log'. It might only work on *NIX, I don't use or know Windows. The log file will appear wherever the current working directory is, so you may want to use a full path to the log file instead.

 

You can probably correlate lines starting with "Full GC" to your freezes.

 

FWIW, Wurm probably churns through too many objects, but a lot of issues also just come from the GC doing full runs and stopping the world.

Edited by Batolemaeus
  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, Batolemaeus said:

Set an environment variable called _JAVA_OPTIONS to '-XX:+PrintGCDetails -XX:+PrintGCDateStamp -Xloggc:wurm_gc.log'. It might only work on *NIX, I don't use or know Windows. The log file will appear wherever the current working directory is, so you may want to use a full path to the log file instead.

 

You can probably correlate lines starting with "Full GC" to your freezes.

 

FWIW, Wurm probably churns through too many objects, but a lot of issues also just come from the GC doing full runs and stopping the world.

 

I assume this won't fail to function due to Wurm having a self contained Java install?

 

Either way, cheers for this, I'll get it added tomorrow and see if I can get any results out of it, much appreciated

  • Cat 1

Share this post


Link to post
Share on other sites

The environment variable _JAVA_OPTIONS gets picked up by any Java implementation I know of. It looks like this:

 

$ export _JAVA_OPTIONS="${_JAVA_OPTIONS} -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log"
$ GDK_BACKEND=x11 ./WurmLauncher
[...]

Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log
 

So it should be visible in the client log file as well. So if you set the env variable system-wide, it should get picked up by the launcher no matter where.

 

The GC log file contains nothing particularly identifying, by the way. You can dump it into whatever online analyser you want. gceasy.io gets SEO'd to the top of the search results and is, by all accounts, decent enough. "Pause time" is the important statistic, it indicates the time when no code gets executed. If that goes beyond 16ms, Wurm will drop a frame.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, Batolemaeus said:

The environment variable _JAVA_OPTIONS gets picked up by any Java implementation I know of. It looks like this:

 

$ export _JAVA_OPTIONS="${_JAVA_OPTIONS} -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log"
$ GDK_BACKEND=x11 ./WurmLauncher
[...]

Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log
 

So it should be visible in the client log file as well. So if you set the env variable system-wide, it should get picked up by the launcher no matter where.

 

The GC log file contains nothing particularly identifying, by the way. You can dump it into whatever online analyser you want. gceasy.io gets SEO'd to the top of the search results and is, by all accounts, decent enough. "Pause time" is the important statistic, it indicates the time when no code gets executed. If that goes beyond 16ms, Wurm will drop a frame.

 

Sounds good, I've never really worked with self contained Java installs, so I wasn't sure how it would translate over, thats good to know that it should at least

 

Yeah I'm happy with providing those kinds of logs, I know its nothing damaging at least, I just don't want to overshare and give off red herrings!

 

This seems brilliant, I'll probably be on Wurm at some point in the week (playing it is proving to be a pain atm lol) so I'll see how it goes and report back

 

Appreciate the help!

  • Cat 1

Share this post


Link to post
Share on other sites

I am getting similar to this but worse.  Framerate is usually 30 but often dropping to 1.  It makes leaving the deed very stressful.

 

I was initially blaming the amount of junk on my deed, but recently noticed it was happening to a lesser extent even out on the steppe, it's just that I am less busy and not trying to do anything precise.

 

I have noticed the laptop overheating a lot when Wurm is running.  Sometimes I have to minimise the client or actually log out and do something else until it cools down.

  • Like 2

Share this post


Link to post
Share on other sites

The number of objects around you directly impacts the amount of memory that gets dirtied and has to be removed during garbage collection once the game discards them from active use (i.e. when you are moving away). That's expected and inevitable.

 

Laptop overheating is normal, they can usually only run at full throttle for a very short time before throttling down. Garbage collection is expensive, so you're getting choked from both ends.

 

Newer versions of Java can alleviate that somewhat, but the underlying cause is object creation/destruction, and a solution necessarily involves someone who knows how to work with real time applications in garbage collected languages (those people are pretty expensive).

 

FWIW, I have good results using a different GC (https://wiki.openjdk.org/display/shenandoah/Main), but it's no silver bullet and trades higher CPU use for smoothness.

Share this post


Link to post
Share on other sites

I'm not going to pretend I'm an expert with Garbage Collection logs, however, I have managed to get some spun up and logged

 

They are here;

 

wurmgc.log -> https://pastebin.com/ZQSrA9He

wurmgc.log.0 -> https://pastebin.com/9geFLzXJ

 

While uploading and writing this up I thought I'd look up something that analysed the logs for me, so at least I could see if I found anything that made this worth actually posting about, and I found this

 

Screenshot-2023-03-18-14-17-24.png

 

Source: https://gceasy.io/diamondgc-report.jsp?oTxnId_value=edcf77e2-5ae8-4df3-a34b-ab67223ac3c6

 

I'll let anyone here who's more educated take a peek, this was taken within maybe 1-2 minutes of playing, I can do a longer session if need be

 

Thanks everyone who has helped so far :)

Share this post


Link to post
Share on other sites

Your average pause time is at least four frames at 60fps, with one pause at half a second.

 

Yeah, you're going to feel those. Nothing you can do about it. It's normal.

 

If I run up and down the highway with Wurm's current defaults (-XX:+UseG1GC -XX:MaxGCPauseMillis=8 -XX:MinHeapFreeRatio=11 -XX:MaxHeapFreeRatio=18
 but in OpenJDK 17):

 

5Z8Hzwg.png

 

Same track, different GC implementation, pay attention to the scale though (-XX:+UseShenandoahGC -Xmx4G -Xms256M):

 

4dbYBrX.png

 

There isn't too much stuff around me, so a stress test would be the Oak Hill Ranch area, but you can see the difference. Run #2 is much smoother.

Share this post


Link to post
Share on other sites

Alright so I have reason to believe that there are specific items, combinations, situations in the game that are causing these stutters. I was having stutters on my deed despite not having really anything. The culprit was the drying grass on the ground. I harvested it and the stutters are gone. This could be the drying grass by it self or a stage in which the drying process is in I'm not sure. 

Likely a number of items or combinations of things in the game that cause these stutters. Good luck figuring them all out and solving the reason why they cause stutters.

 

If I run into another one of these things that cause stutters that I would like to have on my deed I'll probably quit the game. Because the stutters are beyond annoying.

 

I'll also add that I did take a trip through "Red HQ" the other day and yup stutters a lot. My frame drop is only about 10fps but it's a stutter so really the drop doesn't matter as the game freezes all the same. I have ran through a couple of other settlements that were causing stutters as well. 

Edited by Aaelius

Share this post


Link to post
Share on other sites

I just tested it by cutting a bunch of grass away from my deed and yup it stutters. Drying grass causes stutters. As soon as I move away from it, stutters stop.

 

I'm not surprised that people haven't caught this because I haven't seen a field of drying grass on anyone's deed yet. 

Edited by Aaelius

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now