Multi-core Performance Update, Improvement or Deterioration?

Palidon · May 2018

As usual ZOS makes things worse. With Summerset I now have FPS issues. I go from 55 to 5 then jump back up. Changed video settings to see if that would fix the issue and nope. Also experiencing Longer load screens to go from one map to another and to even log into the game. Keep this poor game performance up ZOS and it will eventually bite you in the butt if it hasn't started already.

Palidon · May 2018

labambao wrote: »

No difference to me, but after summerset i have FPS drop from 100 to 10 and back to 100

Having the same issue. Tried changing the game video settings and that did not fix the problem either. Whether I am on Ultra settings or Custom turning off a lot of features there is no change.

Bevik · May 2018

ZOS_AlexTardif wrote: »

ramasurinenpreub18_ESO wrote: »

The massive freezes feel like a thread collision related to player character model loading, where the main game thread passed off the loading to other cores, but they weren't ready with results when asked for them. The freezes happen most often and severely when approaching wayshrines, especially in Artaeum and Alinor, where a lot of people tend to go AFK.

I've been messing with the UserSettings.ini settings for multicore, restricting the number of threads a bit. The freezes are definitely coming from the "WorkerThreads" line, as setting it to 0 removes them entirely, but at the loss of a little fps in general, while setting them to 8 turns the entire game into a near constant slideshow. With the settings below I have managed to completely remove all the freezes and stutters, in Alinor and everywhere else. Framerate now seems to be about the same as pre-patch. Smooth as silk. Maybe give these a try until they get a proper fix in.

SET MaxCoresToUse.4 "8" (if you have a quad core hyperthreading cpu, if not use "4")
SET RequestedNumJobThreads "4"
SET RequestedNumWorkerThreads "1"

Also, setting GPUSmoothingFrames to "0" or "1" can be very helpful with general smoothness and microstutters, as well as input lag and responsiveness if you have a high end GPU. "0" is best if you can get away with it.

Cheers.

You're correct! The momentary freeze is indeed because of some processing that runs on a worker thread, so you may well see that issue occur less frequently (or not at all) by doing what you've stated, however the impact of reducing your worker thread count to 1 means that only a single thread is able to perform all of the background work that the game demands. This means you would have longer load times, slower in-game streaming, and potentially lower frame rate than you would have otherwise. This is because much of the work done for this patch was to offload main thread work to worker threads so that it wouldn't slow down your framerate. The new stutters are situations when the main thread finds itself waiting on something a worker thread is doing, which is not good, and didn't show up in our internal testing environment. We have a number of fixes for these situations on the way, so we recommend changing those settings back after we patch these fixes in to see if it improves your experience.

@ZOS_AlexTardif And when can we see that patch for the fixes? It is - and don't want to be rude - disappointing after hyped the performance patch so much.

Doctordarkspawn · May 2018

Hopefully the patch today will help fix some of these.

To be honest, it seems like a rig by rig basis thing. Thus is the case with PC gaming

PouletRico · May 2018

Doctordarkspawn wrote: »

Hopefully the patch today will help fix some of these.

The patch is available on PC EU (I'm downloading it right now), I'm going to do some test, but I hope all those FPS issues will be fixed

profundidob16_ESO · May 2018

Doctordarkspawn wrote: »

Hopefully the patch today will help fix some of these.

To be honest, it seems like a rig by rig basis thing. Thus is the case with PC gaming

it's true that the recent multicore changes yield positive results for some computers while negative results or status quo for others. For the people interested here's why:

The game used to be 32bit only at creation time and all worker processes ran roughly speaking in 1 big single thread with no options to effectively use multicore cpu's. This was and has been common practise for ages. This meant that the only way for people to get really good performance was to maximize the single core performance. So all the people with specific cpu's overclocked above 5ghz were (and still are) in luck because they have been getting the best fps and general performance in ESO

People on the other end with slow clocking laptop cpu's @2.4Ghz for example litteraly get crap performance and fps, resulting in the many existing complaints.

It wasn't until very recently that ESO's slow and gradual change towards becoming a 64-bit application was implemented well enough to be considered 'truly 64-bit'. That means the 64-bit version for the main executable has been there for a while next to the 32-bit but the worker processes were not split up (enough) and stuff still ran mainly on 1 core load-wise.

So now for the first time in history the game allows the cpu load to be spread over different processes equally or being forced onto 1 single core like before (depending on your personal choice in the usersettings file)

the more cores you set for the worker processes in the user settings, the more the cpu load gets spread (= better fps) but the more delay and overhead latency you create because all those threads have to "synchronize" their calculated results and pass it back on to eachother in order to display the final results on you screen.

And there it is: High end cpu's with a single core performance of 5GHz+ will see better steady fps and performance currently when forcing the worker processes back onto 1 main thread, eliminating all possible extra delay, latency and stalls/hickups while low end cpu's that previously were completely bottlenecked by their single core performance will see a huge increase by defining the maximum of cores to be used by worker processes because their existing single-core bottleneck is finally gone. Yet they will still experience the extra delays, latency and stalls/hickups until ZOS devs find a way to get rid of most of the current multicore issues -maybe todya's patch ?- and optimize the processes (a work in progress I believe)

High end cpu's with a single core performance of 5GHz+ are experiencing crap performance right now since patch due purely due to the extra delays, latency and stalls/hickups but at least they have the option to modify the user settings file as per the options mentioned in the previous pages of this thread.

profundidob16_ESO · May 2018

Bevik wrote: »

ZOS_AlexTardif wrote: »

ramasurinenpreub18_ESO wrote: »

The massive freezes feel like a thread collision related to player character model loading, where the main game thread passed off the loading to other cores, but they weren't ready with results when asked for them. The freezes happen most often and severely when approaching wayshrines, especially in Artaeum and Alinor, where a lot of people tend to go AFK.

I've been messing with the UserSettings.ini settings for multicore, restricting the number of threads a bit. The freezes are definitely coming from the "WorkerThreads" line, as setting it to 0 removes them entirely, but at the loss of a little fps in general, while setting them to 8 turns the entire game into a near constant slideshow. With the settings below I have managed to completely remove all the freezes and stutters, in Alinor and everywhere else. Framerate now seems to be about the same as pre-patch. Smooth as silk. Maybe give these a try until they get a proper fix in.

SET MaxCoresToUse.4 "8" (if you have a quad core hyperthreading cpu, if not use "4")
SET RequestedNumJobThreads "4"
SET RequestedNumWorkerThreads "1"

Also, setting GPUSmoothingFrames to "0" or "1" can be very helpful with general smoothness and microstutters, as well as input lag and responsiveness if you have a high end GPU. "0" is best if you can get away with it.

Cheers.

You're correct! The momentary freeze is indeed because of some processing that runs on a worker thread, so you may well see that issue occur less frequently (or not at all) by doing what you've stated, however the impact of reducing your worker thread count to 1 means that only a single thread is able to perform all of the background work that the game demands. This means you would have longer load times, slower in-game streaming, and potentially lower frame rate than you would have otherwise. This is because much of the work done for this patch was to offload main thread work to worker threads so that it wouldn't slow down your framerate. The new stutters are situations when the main thread finds itself waiting on something a worker thread is doing, which is not good, and didn't show up in our internal testing environment. We have a number of fixes for these situations on the way, so we recommend changing those settings back after we patch these fixes in to see if it improves your experience.

@ZOS_AlexTardif And when can we see that patch for the fixes? It is - and don't want to be rude - disappointing after hyped the performance patch so much.

I believe we could very well be seeing improvement after today's patch. How much exactly remains to be seen. We'll know by tomorrow after testing

Gythral · May 2018

mixed blessing
mostly ok but now with microstutters instead of areas where fps dropped a bit

KoultouraS · May 2018

Ok so I see some well informed lads here , so do you mind if I ask something that might be related?
I have seen posts/threads about light attack animation canceling not working properly after Summerset update.
I happen to have experienced some weird things as well.
Not perfectly describing it but it feels like 1/3 (or so) of the light attacks you try to animation cancel via skill
just do not connect.
It feels like they (LA's) were never triggered/or registered in the first place, to be precise.
Is it anyhow having to do with this mutlithreading isssue? (i7 6700k not OCed)

What do you guys think?

Octopuss · May 2018

There's absolutely no mention about ANY fixes for the bad performance in today's patch. WTF?

profundidob16_ESO · May 2018

Octopuss wrote: »

There's absolutely no mention about ANY fixes for the bad performance in today's patch. WTF?

that doesn't necessarily mean there aren't any changes in though. Some of the changes go in unmentioned or rather..."empirically" if you know what I mean

De devs might have wisely decided they will not make any (more) hard proclamations/announcements until after the effects have been 'tested' on live and proven to work in the majority of cases without unexpected negative sideeffects

Slayer62 · May 2018

still same problem fps drop much unplayable at cyro.

Someone thinks to fix this ?

profundidob16_ESO · May 2018

KoultouraS wrote: »

Ok so I see some well informed lads here , so do you mind if I ask something that might be related?
I have seen posts/threads about light attack animation canceling not working properly after Summerset update.
I happen to have experienced some weird things as well.
Not perfectly describing it but it feels like 1/3 (or so) of the light attacks you try to animation cancel via skill
just do not connect.
It feels like they (LA's) were never triggered/or registered in the first place, to be precise.
Is it anyhow having to do with this mutlithreading isssue? (i7 6700k not OCed)

What do you guys think?

at this point I don't see an immediate correlation between the multicore changes and changes in weaving animation BUT the good news is that you can find that out for yourself and tell us the result right here.

Use the previous pages of this thread to set your workers to "1" and test for an hour. Then change it to "-1" and test for an hour again and see if you feel a difference.

Inoki · May 2018

I'm not gonna bother entering Summerset until they fix performance issues. All areas are fine for me, average 30 - 40 FPS, delves 50 - 60 FPS.

In Summerset and related zones I get 9 FPS, 15 FPS on average.

I understand we have to be gentler with nature, but did you really have to insert so much green (heavily increased object density) into Summerset?

Ethoir · May 2018

ZOS_AlexTardif wrote: »

You're correct! The momentary freeze is indeed because of some processing that runs on a worker thread, so you may well see that issue occur less frequently (or not at all) by doing what you've stated, however the impact of reducing your worker thread count to 1 means that only a single thread is able to perform all of the background work that the game demands. This means you would have longer load times, slower in-game streaming, and potentially lower frame rate than you would have otherwise. This is because much of the work done for this patch was to offload main thread work to worker threads so that it wouldn't slow down your framerate. The new stutters are situations when the main thread finds itself waiting on something a worker thread is doing, which is not good, and didn't show up in our internal testing environment. We have a number of fixes for these situations on the way, so we recommend changing those settings back after we patch these fixes in to see if it improves your experience.

@ZOS_AlexTardif I found another cluster of spots that you may or may not have identified. These are in Rawl'kha and I've cobbled together a "map" of their positions using multiple screenshots of the in-game map. I see a pattern in them, at least for that city.

I'm on a Ryzen 5 1600X (6C/12T) at stock clock speed, 16 GB of RAM (DDR4-2400), and I play using an MSI Radeon RX 580 4GB GPU (Factory OC'd).

bottleofsyrup · May 2018

Useless patch.

ZOS_AlexTardif · May 2018

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

lihentian · May 2018

way way way worse. i had i7 4790.. not good.. but shouldn't be too bad...right? lag like hell after summerset

Lieblingsjunge · May 2018

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

Thanks a bunch for the continuous updates!

Feanor · May 2018

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

As disappointing as this news is, I much appreciate the communication as well. Thanks for keeping us posted!

Octopuss · May 2018

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

Good, at least we know what's going on.
I guess we can survive another week.

profundidob16_ESO · May 2018

Feanor wrote: »

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

As disappointing as this news is, I much appreciate the communication as well. Thanks for keeping us posted!

+1

Wildcopper · May 2018

Stuttering sometimes happens when massive amounts of player characters pop on the screen at the same time, like e.g. near the Artaeum wayshrine. But in the world, I'm still getting good performance including in Summerset even in areas with dense vegetation.

Core I7 8700k @ 4.7ghz
GeForce 980 Ti
16gb DDR4 3ghz

Acrolas · May 2018

It's so simple I can't believe I didn't think of it, but in researching performance I landed on a gfx temperature guide on a crypto mining site. One of their big suggestions was to, every month or two, take compressed air and give the interior of your rig a really good cleaning, as a few months of dust can really impact the optimal performance of your hardware.

Considering that debugging originated from a tech finding an actual moth in the Harvard Mark II, I figured passing on this troubleshooting idea couldn't hurt.

Iselin · May 2018

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

I must have experienced a post-patch placebo effect. I could have sworn it was less hitchy today

kisazeky · May 2018

Acrolas wrote: »

It's so simple I can't believe I didn't think of it, but in researching performance I landed on a gfx temperature guide on a crypto mining site. One of their big suggestions was to, every month or two, take compressed air and give the interior of your rig a really good cleaning, as a few months of dust can really impact the optimal performance of your hardware.

Considering that debugging originated from a tech finding an actual moth in the Harvard Mark II, I figured passing on this troubleshooting idea couldn't hurt.

While this is good advice for general computer maintenance, it won't do much to solve this particular issue. It's been confirmed that this bug is on ESO's end, as an unintended result of multi-core optimization.

BuddyAces · May 2018

Iselin wrote: »

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

I must have experienced a post-patch placebo effect. I could have sworn it was less hitchy today

If you're on the USA servers it's probably because there are less folks on than normal since it's a 'return to work today' day.

bethsheba · May 2018

ZOS_AlexTardif wrote: »

Just to update everyone, the fixes for this were not in today's patch. We wanted to give QA enough time to test them thoroughly before pushing them out. Thanks for your patience!

Thanks Alex, I didn't think so after reading the notes. I know there will be tweaking as we go along, I'm happy to wait for it to be right. or righter.

Preyfar · May 2018

It's gone up... and down. On a 5930K with 32GB of RAM and a GTX90 I'm hitting 100+ FPS almost consistently... until I get in combat, which it can drop down to 30-ish at times. The highers are high and the lowers are lower. But on the plus so I find the game far, FAR more responsive. Some of the issues I used to get where the game would just stop recognizing my input during trials/intense raids seems to have gone away.

Idinuse · May 2018

profundidob16_ESO wrote: »

Idinuse wrote: »

Septimus_Magna wrote: »

ramasurinenpreub18_ESO wrote: »

The massive freezes feel like a thread collision related to player character model loading, where the main game thread passed off the loading to other cores, but they weren't ready with results when asked for them. The freezes happen most often and severely when approaching wayshrines, especially in Artaeum and Alinor, where a lot of people tend to go AFK.

I've been messing with the UserSettings.ini settings for multicore, restricting the number of threads a bit. The freezes are definitely coming from the "WorkerThreads" line, as setting it to 0 removes them entirely, but at the loss of a little fps in general, while setting them to 8 turns the entire game into a near constant slideshow. With the settings below I have managed to completely remove all the freezes and stutters, in Alinor and everywhere else. Framerate now seems to be about the same as pre-patch. Smooth as silk. Maybe give these a try until they get a proper fix in.

SET MaxCoresToUse.4 "8" (if you have a quad core hyperthreading cpu, if not use "4")
SET RequestedNumJobThreads "4"
SET RequestedNumWorkerThreads "1"

Also, setting GPUSmoothingFrames to "0" or "1" can be very helpful with general smoothness and microstutters, as well as input lag and responsiveness if you have a high end GPU. "0" is best if you can get away with it.

Cheers.

What do you set if you have a 6 core, 12 thread CPU?

SET MaxCoresToUse.4 "-1"
SET RequestedNumJobThreads "-1"
SET RequestedNumWorkerThreads "-1"

Atm I also suggest to set

SET HIGH_RESOLUTION_SHADOWS "0"
SET SHADOWS "0"

NO, that's wrong. The first 2 lines perfectly ok but the stuttering will stay until you change the "-1" in the third "RequestedNumWorkerThreads" line (= max cores) into "1" (limit the jobs into a single thread so they don't have to wait for eachother -which causes the stuttering- )

thoroughly tested and verified last weekend

disclaimer: the information I provide might become invalid when they possibly fix the cause in the upcoming patch of today. IF that happens then "-1" for the work might actually become the better value

Yes I know it should, but on my rig, for some reason, -1 on RequestedNumWorkerThreads works best, idk why.

Edit* But of course for Hyper-threading super multiple thread CPUs, your setting is no doubt totally optimal.