Absurd Problem That Somehow Makes Me Slower

[OdeFinn]

@SETHONMETH have you changed your graphics or game settings after update?
Just wondering if your 6600k was barely keeping up on physics and skipping physics data, now when 7700k can keep up and it just show flaws on your setups which weren't visible on 6600k due lack of processing power, drop from 99% usage to 25% usage is really huge.

 

[SETHONMETH]

I made some changes to the player.json file after switching to the 7700k that include:
"use thread" set to true (in controller.ini file)
garage detail lowered
mirror distance lowered
max headlight distance lowered

Maybe there is more I'm forgetting, as there are loads more that I made (there is an excellent post by Risto Kappet on these changes and Mikk Schleifer's personal website has a great, although outdated list) but I had made some changes when I was on the 6600k and I don't remember what they were specifically. I always ran the game at the lowest graphics settings, mainly because it's the only way then and now that I can get 144fps with near zero frame rate drops.

I think the issue with setups on the 6600k was probably that I was tuning around things caused by the CPU maxing out and not around my driving style.

I'm about to do some tests with the DAMPlugin and Liveracers to see if anything sticks out. Will post my results shortly.

But also I am still unable to get the purple/green bars to show in session. Why can't I do this? I just did some quick research and this feature is definitely still in the game. Did I make some kind of change that disabled it or changed the key combination to pull it up?

 

[SETHONMETH]

These are really good results (Indy at St. Petersburg):
In game replay says 281KPH
Liveracers says 281.0KPH
DAMPlugin says 280.9KPH

I think that this is a small enough margin of error that I can effectively rule out that this same CPU problem is happening on my 7700k. At least not at this car/track.

Also I figured out the purple/green bar problem: I was looking for it on my side monitors and it was in my center monitor. Don't ask me how I didn't see it.

 

[SETHONMETH]

Purple bar stays at about 25% everywhere I tested it. I think it's safe to say I do not have an issue with my CPU anymore.

I'm now checking out my wheel because there may be an issue with it and I'm still not 100% sure I don't have any problems.

 

[Lazza]

Also I figured out the purple/green bar problem: I was looking for it on my side monitors and it was in my center monitor. Don't ask me how I didn't see it.

lol, nice Annoying as it might be, I can imagine how it would happen. It's the best indicator for rF2 CPU occupancy regarding physics, so good it's working and looks fine.

Just wondering if your 6600k was barely keeping up on physics and skipping physics data, now when 7700k can keep up and it just show flaws on your setups which weren't visible on 6600k due lack of processing power, drop from 99% usage to 25% usage is really huge.

rF2 never skips physics data, that's why it goes into slow motion if the CPU isn't keeping up. So no handling changes in that way.

 

[SETHONMETH]

I just reinstalled my Fanatec drivers, because I was unable to open the properties of my wheel. After re-installation I pulled up VIR with the McLaren GT3, as I've just done 1500 laps here in the GT Series qualifier. I was able to go over a tenth faster than my best in under 30 laps on the realroad I saved from the qualifier and it REALLY felt different and a lot easier to drive and there were no strange incidents that left me scratching my head. I had done 500 laps in the qualifier since I set the time and did not improve.

So I think the problem I was having when I started this thread was one with my Fanatec driver, and it seems to be solved now.

 

[Stefan_L_01]

So rf2 speed is system dependent after all (influenced by hardware, thread switching, whatever) - nice to know. Explains some time differences...

 

[SETHONMETH]

So rf2 speed is system dependent after all (influenced by hardware, thread switching, whatever) - nice to know. Explains some time differences...

Sort of true and not true. No system will go faster than the norm, but if your CPU is hitting 100% usage it can go slower than the norm.

 

[Stefan_L_01]

Well if you look at the resource monitor, at least one core is at 100%, but this is normal if you want to have a tire thread of 2400hz which yields at 400µs cycle time. No desktop windows system guarantees 400µs cylce time - if the thread gets interrupted, it may get called after 1ms or more. So of course rf2 does not work same on any system. It would be interesting to now how many tire cycles got missed, a counter could be easily implemented and displayed

 

[Lazza]

@Stefan_L_01 No, no, and no.

 

[SETHONMETH]

Well if you look at the resource monitor, at least one core is at 100%

I just tested this and the highest any of my cores were utilized was 32%

 

[Lazza]

Just to expand a little on my previous post, since I have a little more time now...

So rf2 speed is system dependent after all (influenced by hardware, thread switching, whatever) - nice to know. Explains some time differences...

No.

And nothing above would indicate this. I don't know why you've got that idea in your head, but nothing has ever proven such a thing, the devs themselves have said otherwise, and SETHONMETH's experiences don't support it either. This sort of thing just starts ugly rumours.

Well if you look at the resource monitor, at least one core is at 100%, but this is normal if you want to have a tire thread of 2400hz which yields at 400µs cycle time. No desktop windows system guarantees 400µs cylce time - if the thread gets interrupted, it may get called after 1ms or more. So of course rf2 does not work same on any system. It would be interesting to now how many tire cycles got missed, a counter could be easily implemented and displayed

Before we go measuring a problem that isn't there, let's review a couple of things:

• No tyre cycles 'get missed'. That's the reason it goes into slow motion if the CPU is held up or inadequate. This isn't generally a slight effect, and it's pretty obvious when you're looking for it. So let's back up another step, bypassing this assumption completely...
• Regarding timing, something that's been said through the years regarding rF is that the realtime engine took quite a lot of work to get right in the Windows environment. Now unless you have some sort of inside knowledge, which again seems unlikely because no one's produced any real evidence above some anecdotes or rumours about rF/rF2 timing, I think we need to trust that the professionals are aware of the difficulties and have perhaps worked out a way to deal with them that - surprise surprise - you might not be aware of. That doesn't make it impossible. Also...
• You don't need to run a physics loop each 1/2400th of a second. If the output (physics/FFB) is at 400Hz, that's your target rate. Whether you produce 1/400th of a second worth of physics in 1/2000th of a second or you do it in 1/401st of a second, as long as you get it done before it's needed you can stay in realtime. A game could easily simulate an object's movement at 1MHz because it doesn't need to divide that up into 1000000 pieces each second, and run them all in the correct time - if you targeted 100Hz output, all you need to do is run 10000 loops for each 1/100th of a second output loop. So even if what you say about timing limitations are true, that doesn't mean the tyre isn't simulated at 2400Hz.

So, you can 'of course' all you want, but I have to disagree.

 

[Stefan_L_01]

Obviously you dont know anything about windows time slicing, thread scheduling etc. . You just repeat phrases.
Windows is not a RTOS, and when windows decides to interrupt your process or thread because something different has to be processed, then your calculations are stopped for undefined time, e.g. 1ms breaks can be easily observed in test programs if you add load to your system. Some call this an undefined response time.

 

[stonec]

Obviously you dont know anything about windows time slicing, thread scheduling etc. . You just repeat phrases.
Windows is not a RTOS, and when windows decides to interrupt your process or thread because something different has to be processed, then your calculations are stopped for undefined time, e.g. 1ms breaks can be easily observed in test programs if you add load to your system. Some call this an undefined response time.

Yes, obviously Windows is not an RTOS, that's why you need overhead in the simulation application that is supposed to simulate real time behaviour. Normally there's plenty of overhead and as has been mentioned several times, you only run into issues if the physics loop goes to 100%, which you can track with Ctrl+C. There are no missed cycles otherwise and if the physics run out of realtime, the simulation is coded such that you end up losing in lap time. Otherwise this would open up a can of worms with different configurations allowing different lap times and possibly cheating with loading up Windows with background tasks. Also having a CPU core running at 100% isn't the same as rF2 physics loop being at 100% and out of real time.

 

[Lazza]

Obviously you dont know anything about windows time slicing, thread scheduling etc. . You just repeat phrases.
Windows is not a RTOS, and when windows decides to interrupt your process or thread because something different has to be processed, then your calculations are stopped for undefined time, e.g. 1ms breaks can be easily observed in test programs if you add load to your system. Some call this an undefined response time.

You make games sound impossible to make without timing discrepancies. There are difficulties, sure, but like I said the devs have discussed this in the past. If you doubt their word maybe you can discuss it with them, they certainly have the knowledge to put your mind at ease.

I'll repeat one thing again for you, because you keep missing it: for 400Hz FFB output, you only need to run consistent timing at 400Hz. If you run 6 loops each time you effectively calculate physics at 2400Hz, but you only update at 400Hz. That's 2.5ms, which is more manageable. (easy? No... but easier...)

*Also of note: the Reply link. Helps people see your response.

 

[Stefan_L_01]

@SETHONMETH Before I continue can you give me your laptime in the challenge please? And your slow time with the issue?

 

[Stefan_L_01]

I just tested this and the highest any of my cores were utilized was 32%

Hi again
I just cant believe it In the attach is my proc/core load, sitting offline in a tatuus in a small circuit without AI. Can you post a similiar shot from your system in similiar situation? Can you post your system specs (prozessor clock rating, mem clocking) ? Since 4 years I have one core full of load in rf2, but I encounter in various situations, and mostly in race with 20 people around, similiar issues that you reportet initially.
Note that the ingame ctrl+C chart looks fine top right!
Edit: added image Porsche GT3-R VIR offline without AI
Edit: MSI Gaming Pro MB (Z370) watercooled, 16MB, I5-8600@4.5GHZ, GF GTX1060@6GB

 

[nonamenow]

This is online with F3 Spark at Pukekohe idling in garage. Had to use snipping tool as screenshots are being weird for me.

 

[Lazza]

Hi again
I just cant believe it In the attach is my proc/core load, sitting offline in a tatuus in a small circuit without AI. Can you post a similiar shot from your system in similiar situation? Can you post your system specs (prozessor clock rating, mem clocking) ? Since 4 years I have one core full of load in rf2, but I encounter in various situations, and mostly in race with 20 people around, similiar issues that you reportet initially.
Note that the ingame ctrl+C chart looks fine top right!
Edit: added image Porsche GT3-R VIR offline without AI
Edit: MSI Gaming Pro MB (Z370) watercooled, 16MB, I5-8600@4.5GHZ, GF GTX1060@6GB

Taking a cue from the OP, what controller do you have? And you're on single screen or triples? Sorry if you have info in your sig, can't see them right now.

You could also try running your system at stock speeds, in case a combination of settings is causing issues. My stock 8600 is fine on triples.

 

[SETHONMETH]

Hi again
I just cant believe it In the attach is my proc/core load, sitting offline in a tatuus in a small circuit without AI. Can you post a similiar shot from your system in similiar situation?

I can't say if this was the case with my 6600k or not, but it sure isn't with the 7700k. If I remember correctly though, on the 6600k my total CPU usage fluctuated at 98-99% and my most active core wasn't pegged at 100% like yours but at 98-99% with peaks at 100%. You'll have to take my word for it. If you haven't tried setting "Use thread" to true in your controller.ini file you should, this is one of the things that I singled out that could have contributed to my problem with the 6600k. Note that this has something to do with wheel drivers, and I use a Fanatec CSL Elite.

I specifically bought the 7700k so that I could run it at a clock speed within factory specs because this is something that could potentially cause a problem in some sims, probably not rFactor 2 though. Maybe somebody else who knows more could shine some light on this.

7700k is at 4.5GHz, DDR4 Ram @ 2400MHz using timing listed on ram, RTX2070 Pascal dynamic GPU overclocking that maxes at ~1900MHz and video memory @ 7901MHz