Tracking Down the Plugin Limit

[RitualClarity]

ritualclarity, on 23 Apr 2013 - 21:33, said:

I don't want to state the obvious but have you dialed down the graphics and other settings as low as possible? Just for testing of course.

Nope. And it's not gonna happen. I didn't buy an expensive computer to not run things at full. The results I might get from that test are irrelevant since I'd rather run with less plugins than less graphics.

I stated "for testing of course" for a reason. If it responds and you can increase the plugin limit, focus can be given to the graphics. It is the easiest way to determine if it is multi-core processor or the graphics that are causing the problem. I am sorry if I struck a nerve. It wasn't my intent.

 

[ChancellorKremlin]

 

Well, I reached 142 plugins and I started getting the "buttons don't work ingame anymore" issue like E not working, or the pause menu, or esc, or having the loading map icon at the bottom get corrupted ingame. 

 

So I reduced my iNumHWThreads= from the original 8 to 2, and it seems to have fixed it. I don't know by how much, ie I've not tried installing loads more plugins to see how far it will go, but seeing as my game was breaking at 142 and now its not I'm calling it progress. Extra reading on the internet even says you can force it to 1 and that reduces crashes, so if nothing changes much I'll go on to that. 

 

@CK

I have done the same thing before when I had trouble with graphics. I also used the iFPSClamp=60 or in my case at the time iFPSClamp=30.

For the iNumHWThreads= ... I would try restricting it to 1 just for testing. FNV was able to run well on single core processors provided they had enough speed, yours should be fine.

 

 

By the way, Zippy, if you're still having this problem and haven't tried the suggestion above, I think we're onto something here.

 

Reducing my iNumHWThreads= from 8 to 1 has made all the world of difference for me. I used to have it on 4 by default, and eventually 8 and was having the same issues you have. I'm now at 182 active plugins without any problems, which is quite remarkable and the FPS are steady too. 

 

I just thought I'd bring this up because I wasn't sure if you tried it as low as 1. 

[zippy57]

Haven't tried it as I managed to get it working for the moment. It's things like this that make me hope some of the people working on this game aren't working anywhere any more. How do you manage to make a game run worse with a better CPU?

[BruceWayne]

Haven't tried it as I managed to get it working for the moment. It's things like this that make me hope some of the people working on this game aren't working anywhere any more. How do you manage to make a game run worse with a better CPU?

 

To make it run better on a XBOX360...

[ChancellorKremlin]

Doing that has also dramatically reduced my crashes to desktop. And dramatically would be an understatement. For once, I feel I'm running the game how its supposed to, except for rePopulatedWasteland, which no matter what I do always seems to CTD sooner or later. Stupid plugin.

 

Anyway, good to hear you fixed it Zippy! 

[zippy57]

BruceWayne says you're wrong.

[BruceWayne]

 

BruceWayne says you're wrong. 

 

 

I already told him yesterday.

 

 

... and to make matters more confusing, I've found setting that value over anything other than 1 dramatically increases crashes and CTD's. Ever since I put it down to one I've not had a single crash, which is remarkable.

 

So I guess what we're saying is.... experiment 

 

All I can say to that, is that I never experienced such a thing with iNumHWThreads=4 for my I7 cpu...

 

[ChancellorKremlin]

It seems the effect appears to vary by person and per system. One of those "depends on what you've got" scenarios which I hate so much. How godamn hard can I be to make a program that runs more or less the same across similar platforms? 

 

Anyway, the issue to bear in mind is that, for better or worse, altering those files can achieve results, so its something good to point folks towards. 

[zippy57]

And the better system you have, the worse it gets.

[RitualClarity]

 

BruceWayne says you're wrong. 

 

 

I already told him yesterday.

 

 

... and to make matters more confusing, I've found setting that value over anything other than 1 dramatically increases crashes and CTD's. Ever since I put it down to one I've not had a single crash, which is remarkable.

 

So I guess what we're saying is.... experiment 

 

All I can say to that, is that I never experienced such a thing with iNumHWThreads=4 for my I7 cpu...

 

 

It never gave me problems with my intel i7 either. It wasn't until I went to AMD did I have a problem that required iNumHWThreads= needed to be used.

 

It seems the effect appears to vary by person and per system. One of those "depends on what you've got" scenarios which I hate so much. How godamn hard can I be to make a program that runs more or less the same across similar platforms? 

 

Anyway, the issue to bear in mind is that, for better or worse, altering those files can achieve results, so its something good to point folks towards. 

It might actually be the processor type themselves that are causing the issue. I believe CK is using the same processor type as me and changing the threads help tremendously. After my last post a couple of days ago  I moved to iNumHWThreads=1 myself and it is stable as all hell now.

[Bashis]

ive been playing around with this for a few days and there seems to be a general pattern im seeing, that would fit what you all are saying, the busethreadedai seems to be a quality over quantity type thing. the more cores i have my system use, the lower my plugin limit is, but the smoother my game runs when im under the limit. for example with it set to 1, i can load roughly 170 active mods, but load times are flat out retarded, lag is bad, and sometimes my machine runs itself into the ground and crashes trying to load to much, if i set it to 4, (my number of cores) i can only load about 130, but load times are near instant, and i'm getting constant 60 fps no matter where i go. and before you blame the load times/lag crashes on the extra 40 plugins, im using my normal load order, plus 40 esp's that each contain one caravan playing card, so rule that out right now.

 

my theory on people saying that they get improved performance when lowering thread count is they were near the plugin limit, but not using cpu intensive plugins, thereby knocking up their limit helped them more than hurting. and the same could be said for the other way around, someone usig a crapton of plugins increasing the core usage then getting crashes might mistake it for instability, when in reality they got knocked over their plugin limit.

 

personally i have mine set to 2, i can load all the plugins i want and still have decent fps and load times, but im guessing the number of threads you set your own pc to would be ultimatly determined by how many plugins and how cpu intensive they are, if your only going to run 50 or so knock it all the way up and your game will run hella smooth, but if your pushing 150 like me it might take some adjusting.

 

again i can't prove any of this, but it seems to be a valid theory, and based on what everyone's saying + my testing it makes alot of sense.

[RitualClarity]

ive been playing around with this for a few days and there seems to be a general pattern im seeing, that would fit what you all are saying, the busethreadedai seems to be a quality over quantity type thing. the more cores i have my system use, the lower my plugin limit is, but the smoother my game runs when im under the limit. for example with it set to 1, i can load roughly 170 active mods, but load times are flat out retarded, lag is bad, and sometimes my machine runs itself into the ground and crashes trying to load to much, if i set it to 4, (my number of cores) i can only load about 130, but load times are near instant, and i'm getting constant 60 fps no matter where i go. and before you blame the load times/lag crashes on the extra 40 plugins, im using my normal load order, plus 40 esp's that each contain one caravan playing card, so rule that out right now.

 

my theory on people saying that they get improved performance when lowering thread count is they were near the plugin limit, but not using cpu intensive plugins, thereby knocking up their limit helped them more than hurting. and the same could be said for the other way around, someone usig a crapton of plugins increasing the core usage then getting crashes might mistake it for instability, when in reality they got knocked over their plugin limit.

 

personally i have mine set to 2, i can load all the plugins i want and still have decent fps and load times, but im guessing the number of threads you set your own pc to would be ultimatly determined by how many plugins and how cpu intensive they are, if your only going to run 50 or so knock it all the way up and your game will run hella smooth, but if your pushing 150 like me it might take some adjusting.

 

again i can't prove any of this, but it seems to be a valid theory, and based on what everyone's saying + my testing it makes alot of sense.

Which processor are you using for this testing?

 

[Bashis]

intel i7-3610qm @2.30

[RitualClarity]

BruceWayne also mentioned he hasn't had any problems with his i7. It may be that the game responds a little better on an i7. My old computer had no issues r/t threads. It wasn't until i moved to AMD that I started investigating modifying threads from another forum I found when I had issues with stability.

 

 

[ChancellorKremlin]

Its looking like AMD and the multi-threading functions don't play well. To be perfectly honest, even using NVConfigator and setting all those options to multi didn't seem to make any difference whatsoever for me. The only difference it does seem to make is that setting it to anything other than 1 in the ini files drastically increases the chance of a crash, not to mention it does seem to reduce how many plugins I can use too.

 

 

[astymma]

Well, on my old PC which has dual Intel p4 3.4 GHz processors, I'm seeing results which tend to agree completely with what Bashis was saying. Using the newest SCR with a split main script actually resulted in my game freezing completely, most likely because of thread blocking as one of the main scripts blocked thread execution because it expected variables from the other script to be set. That tells me that my single CPU option of iNumHWThreads=1 was insufficient AND that I was already at or near the performance limit for a single CPU. Increasing iNumHWThreads to 2 fixed everything for me.

 

However, with the current discussion I would have expected a corresponding loss in max plugin count which did not materialize. I was already at my plugin limit of 149. I would have expected that to drop and I was fully prepared to have to start merging/dropping plugins when I changed iNumHWThreads. However, no changes were required, my game continued to function with no drop in plugin max count.

 

EDIT: It's entirely possible that my 149 limit was the limit of a single core processor of my type and not the limit imposed by FNV's architecture. That would explain why my plugin max count didn't drop.

[ChancellorKremlin]

Was it an intel or AMD processor Astymma? It's looking like Intel ones play a lot better with FNV than AMD ones do, at least when it comes to setting multi-threaded features. Personally, even running on just the 1 processor I can't complain of the performance.

[Halstrom]

Well, on my old PC which has dual Intel p4 3.4 GHz processors, I'm seeing results which tend to agree completely with what Bashis was saying. Using the newest SCR with a split main script actually resulted in my game freezing completely, most likely because of thread blocking as one of the main scripts blocked thread execution because it expected variables from the other script to be set. That tells me that my single CPU option of iNumHWThreads=1 was insufficient AND that I was already at or near the performance limit for a single CPU. Increasing iNumHWThreads to 2 fixed everything for me.

 

However, with the current discussion I would have expected a corresponding loss in max plugin count which did not materialize. I was already at my plugin limit of 149. I would have expected that to drop and I was fully prepared to have to start merging/dropping plugins when I changed iNumHWThreads. However, no changes were required, my game continued to function with no drop in plugin max count.

 

EDIT: It's entirely possible that my 149 limit was the limit of a single core processor of my type and not the limit imposed by FNV's architecture. That would explain why my plugin max count didn't drop.

Well I've changed that for the next beta release, it was a bit of a poor assumption on my part that the 1sec delay script would always run before the 5 second interval script on the FO engine

So now I have the 5 sec quest script started only at the 1 second quest scripts completion. Once it's run once it shouldn't be an issue.

[astymma]

Was it an intel or AMD processor Astymma? It's looking like Intel ones play a lot better with FNV than AMD ones do, at least when it comes to setting multi-threaded features. Personally, even running on just the 1 processor I can't complain of the performance.

 

Points at the "Well, on my old PC which has dual Intel p4 3.4 GHz processors..." part

[Halstrom]

 

Was it an intel or AMD processor Astymma? It's looking like Intel ones play a lot better with FNV than AMD ones do, at least when it comes to setting multi-threaded features. Personally, even running on just the 1 processor I can't complain of the performance.

 

Points at the "Well, on my old PC which has dual Intel p4 3.4 GHz processors..." part

 

You should be able to just swap the following into the last similar part of the Fast script and untick the slow script Quests GameStartEnabled box and that should fix it I hope.

		if iGameRestartReload
			Set iGameRestartReload to 0
			DebugPrint "SCRS1MainSCR: First PassOk, Version %8.1f" fCurrVer
			MessageEx "SCRS1MainSCR: First PassOk, Version %8.1f" fCurrVer
			if SexoutSQVAR.iDiseasePerc > 0 || SexoutSQVAR.iDrugDuration > 0 || SexoutSQVAR.fSexoutPregVersion > 0
				if PlayerREF.GetItemCount SexoutSMedicalScanner < 1
					PlayerREF.AddItem SexoutSMedicalScanner 1 1
					DebugPrint "SCRS1MainSCR: Medical Scanner added"
				endif
				StartQuest SexoutSAddToLevelledLists
			else
				if PlayerREF.GetItemCount SexoutSMedicalScanner > 0
					PlayerREF.RemoveItem SexoutSMedicalScanner 1 1
					DebugPrint "SCRS1MainSCR: Medical Scanner removed"
				endif
			endif
			StartQuest SexoutSQMainSlow
;			DebugPrint "SCRS1MainSCR: Add Scanner Check= Disease %3.1f, Drugs %3.1f, PregVersion %8.1f" SexoutSQVAR.iDiseasePerc SexoutSQVAR.iDrugDuration SexoutSQVAR.fSexoutPregVersion
		endif

[ChancellorKremlin]

 

Was it an intel or AMD processor Astymma? It's looking like Intel ones play a lot better with FNV than AMD ones do, at least when it comes to setting multi-threaded features. Personally, even running on just the 1 processor I can't complain of the performance.

 

Points at the "Well, on my old PC which has dual Intel p4 3.4 GHz processors..." part

 

 

lol, I really need to go to sleep haha.. duh!

[RitualClarity]

I still wouldn't recommend automatically changing the threading to 1 for all AMD processors or any processor. I would only recommend it if and only if there are unexplainable errors and limiting characteristics in FNV. If there isn't I wouldn't change the default settings. It does seem to work fine and stable with a recent clean install. (from backup) with little in the way of mods. Less than 50.

 

Another question for those intel/amd users. Is everybody using the New Vegas Stutter Remover, 4gb extender and which one etc. I have used the New Vegas Stutter Remover but currently am not using the 4gb extender of any type. I use the New Vegas Stutter Remover for "fast exit" issues of FNV otherwise I wouldn't / haven't used it. Perhaps some testing and sampling to see if there might be some issues with that as well? There very well might be some issues with the added tools that are providing more stress on the processor than we may be thinking.

 

 

[ChancellorKremlin]

I still wouldn't recommend automatically changing the threading to 1 for all AMD processors or any processor. I would only recommend it if and only if there are unexplainable errors and limiting characteristics in FNV. If there isn't I wouldn't change the default settings. It does seem to work fine and stable with a recent clean install. (from backup) with little in the way of mods. Less than 50.

 

Another question for those intel/amd users. Is everybody using the New Vegas Stutter Remover, 4gb extender and which one etc. I have used the New Vegas Stutter Remover but currently am not using the 4gb extender of any type. I use the New Vegas Stutter Remover for "fast exit" issues of FNV otherwise I wouldn't / haven't used it. Perhaps some testing and sampling to see if there might be some issues with that as well? There very well might be some issues with the added tools that are providing more stress on the processor than we may be thinking.

 

No, I agree I would only recommend using it for users who are experiencing problems, it is just a variable to keep in mind on those occasions. I also only use the stutter_remover for fast exiting purposes, and I disable its inbuilt 30 FPS lock because I don't like it. I also use the 4gb extender, but again, to be perfectly honest I haven't noticed any difference using it or not. Very few if any of these utilities seem to make any difference for me.

[BruceWayne]

Well, I use the NVSR for exactly what it's supposed to do. To remove microstutter. Once you notice it, there is no way to "unnotice" it.

 

I think in the readme or some other source it says, that there is a ctd expected from its use after 2-3 hours of continous play. 

 

What bugs me most performance-wise is, that the newer nVidia-drivers seem to have broken some stuff regarding stutter. This leads to unplayable conditions the moment there is a body of water loaded and you look in its direction (it doesn't even have to be visibile to produce major stutter).

 

I know that I didn't experience this problem before, with the same mods or graphics settings. The only way for me to remove the stutter is to completely disable refractions and reflections from water.

[RitualClarity]

 

I still wouldn't recommend automatically changing the threading to 1 for all AMD processors or any processor. I would only recommend it if and only if there are unexplainable errors and limiting characteristics in FNV. If there isn't I wouldn't change the default settings. It does seem to work fine and stable with a recent clean install. (from backup) with little in the way of mods. Less than 50.

 

Another question for those intel/amd users. Is everybody using the New Vegas Stutter Remover, 4gb extender and which one etc. I have used the New Vegas Stutter Remover but currently am not using the 4gb extender of any type. I use the New Vegas Stutter Remover for "fast exit" issues of FNV otherwise I wouldn't / haven't used it. Perhaps some testing and sampling to see if there might be some issues with that as well? There very well might be some issues with the added tools that are providing more stress on the processor than we may be thinking.

 

No, I agree I would only recommend using it for users who are experiencing problems, it is just a variable to keep in mind on those occasions. I also only use the stutter_remover for fast exiting purposes, and I disable its inbuilt 30 FPS lock because I don't like it. I also use the 4gb extender, but again, to be perfectly honest I haven't noticed any difference using it or not. Very few if any of these utilities seem to make any difference for me.

 

I didn't notice any difference at lower mod levels. Just wanted to cover the possibilities. I use the stutter remover for the fast exiting purposes. I don't remember if I changed the 30 frames to 60 lock or not but I do use a frame lock. Just a preference most likely left over from when I didn't have a good graphic card. As long as it is running smoothly I don't care if it is 30 frames or 130 frames. I don't think I can see the difference.

 

Well, I use the NVSR for exactly what it's supposed to do. To remove microstutter. Once you notice it, there is no way to "unnotice" it.

 

I think in the readme or some other source it says, that there is a ctd expected from its use after 2-3 hours of continous play. 

 

What bugs me most performance-wise is, that the newer nVidia-drivers seem to have broken some stuff regarding stutter. This leads to unplayable conditions the moment there is a body of water loaded and you look in its direction (it doesn't even have to be visibile to produce major stutter).

 

I know that I didn't experience this problem before, with the same mods or graphics settings. The only way for me to remove the stutter is to completely disable refractions and reflections from water.

I agree, with the microstutter statement. Once you play with it on I wont go back even if I have to compromise and lower the amounts of mods.

I can live with it crashing after 2 hours. However I don't seem to be that unlucky. I believe I played for 4 hour stints and no crash. Perhaps the next time I go through FNV I will make a effort to see how long before a crash.

 

I don't have that water bug you mention in FNV. I have the GTX670 and the most current drivers and a clean install with the current hardware so no  hidden .ini config issues. The graphic are turned all the way up on a HD monitor. I don't understand where the water issue is coming from.