1 hour ago, newtie said:

Are you using NVI?

Interesting suggestion.

NVI is on the machine, but I just checked and it has the default settings for P3D which I've looked through and there is nothing in there which would control frame rate.

17 minutes ago, Bert Pieke said:

And that may again explain some differences in user experience..

I like the fluid feel of my airplane in "normal" scenery situations, and recognize that downtown LA or SEA with full Orbx regions is going to introduce a minor performance impact which I will have to live with. No blurry scenery or fps hell though .

I'm targetting 30fps, and the machine will hold that even flying into a busy airport.

The only time I see slowdowns are at dawn/dusk, but I believe this is a know phenomena.

And yes glassy smooth animation is what I go for. Maybe we can't have perfection until LM replace some more core code, but I get pretty close.

I also test by flying over busy airports at Mach 1.6 in the F-22. If it can handle that, then it's very smooth with GA planes.

19 minutes ago, Bert Pieke said:

No guessing.. my recipe calls for the first option.

Sorry my sloppy typing.

I assume you actually use:

Framerate limit = 0
Scanline Sync = x/2   60

Correct? Cos that seems to do nothing for me. It just runs at unlimited, bouncing between 45 and 60 fps unless I do:

Framerate limit = 30
Scanline Sync = x/2   0

16 minutes ago, SledDriver said:

P3D main processing will be thousands of threads, all perfectly capable of being distributed across many cores.

That's just how CPU's work.

The fact that it loads up Core0 unless you stop it, is almost certainly legacy programming which has not yet been rewritten by LM.

This has been discussed as long as FSX has existed... SP1 and then SP2 made the first steps towards offloading some of the work (mainly scenery loading) onto the other cores.. The Aces Team explained this in detail. So yes, the guys who wrote it..

LM has continued along this path with every new release version improving on this behavior.

At present, P3DV4.5. loads up using two cores for the main threads which you can see if you simply sit still on the tarmac after all the scenery has loaded.  As soon as you take off, the other cores show activity varying with scenery loading requirements.

What we are trying to do with resetting the Affinity after P3D has started is to interfere somewhat with LM's settings.. Time will tell if that is always wise, or not..

Edited April 12, 20197 yr by Bert Pieke

5 minutes ago, SledDriver said:

Sorry my sloppy typing.

I assume you actually use:

Framerate limit = 0
Scanline Sync = x/2   60

Correct? Cos that seems to do nothing for me. It just runs at unlimited, bouncing between 45 and 60 fps unless I do:

Framerate limit = 30
Scanline Sync = x/2   0

Not sure why it is not working for you... this is something new for me too (I was using NVI before) but it gives me very fluid flight which I like!  Do you have several monitors, or unusual Nvidia settings?

Edited April 12, 20197 yr by Bert Pieke

1 minute ago, Bert Pieke said:

This has been discussed as long as FSX has existed... SP1 and then SP2 made the first steps towards offloading some of the work (mainly scenery loading) onto the other cores.. The Aces Team explained this in detail. So yes, the guys who wrote it..

Yes I am aware of that, 15 years ago or so. I think the key word in there is 'mainly'. And early multicore stuff often wasn't very clever sometimes wasting more time managing cores and threads than any benefit gained.

I believe it is quite reasonable to suggest that a modern machine with a modern OS can handle this stuff much better than any old FSX legacy coding which is still in P3D to date. i see no problem 'fooling' the app into spreading the load.

It's working great here . 🙂

4 minutes ago, Bert Pieke said:

Not sure why it is not working for you... this is something new for me too (I was using NVI before) but it gives me very fluid flight which I like!  Do you have several monitors, or unusual Nvidia settings?

The only thing I ever tweaked in NVI was FSX.

And yes I have 5 monitors on the system, but only one used for P3D

Just now, SledDriver said:

The only thing I ever tweaked in NVI was FSX.

And yes I have 5 monitors on the system, but only one used for P3D

Maybe RTSS is sensitive to that.. who knows..

All that really matters is that you have smooth flight, and whether that is using the same settings as someone else.. Who cares

Sure.

1 hour ago, SledDriver said:

Top post on this page disagrees with you. Who is right?

Is it as suggested a the top of this page:

Framerate limit = 0
Scanline Sync = x/2

Or is it

Framerate limit = 30
Scanline Sync = x/2

Please don't guess.

You will be right... when you find what works for you, your system, and the way you fly.  Setting FR=0/Scanline Sync=x/2 will work fine for some folks.  For my simming experience and hardware I needed to set the Framrate.  In RTSS setting my FR to 29 and Scanline Sync x/2 to 60 gives me the smoothest performance (and not surprisingly, least variation in frame rate).

Since you get 37 FPS when you set RTSS to FR=0/SSx/2=60, are you certain your monitor is running at 60 Hz?  Could it be running at 75 Hz?

 

2 hours ago, SledDriver said:

Yes I am aware of that, 15 years ago or so. I think the key word in there is 'mainly'. And early multicore stuff often wasn't very clever sometimes wasting more time managing cores and threads than any benefit gained. I believe it is quite reasonable to suggest that a modern machine with a modern OS can handle this stuff much better than any old FSX legacy coding which is still in P3D to date. i see no problem 'fooling' the app into spreading the load.

This reminds me of a similar trick back in the FS9 days where you could manually tweak the affinity of FS9.EXE in task manager and it seemed to use two cores. Instead of being 100% on one, it was 50% on two. Strangely enough the sum between the cores never seemed to exceed 100.... I wonder?

At the end of the day, there is nothing you can do in Windows to make a single thread divide its work between multiple cores. What I suspect is happening is that the kernel is switching the thread between cores rapidly, more often than Task Manager updates so it looks like two cores are being run. Instead of spending 1000ms executing on a single core, it's spending 500ms on a core, and 500ms on another. I suspect it helps you a little because it may reduce thermal heating on that core, and it hurts you a LOT because you're likely flushing your L1 and L2 caches on a regular basis.

But no matter what, there is no silver bullet. Sequential code is just that, sequential.

55 minutes ago, lownslo said:

You will be right... when you find what works for you, your system, and the way you fly.  Setting FR=0/Scanline Sync=x/2 will work fine for some folks.  For my simming experience and hardware I needed to set the Framrate.  In RTSS setting my FR to 29 and Scanline Sync x/2 to 60 gives me the smoothest performance (and not surprisingly, least variation in frame rate).

Since you get 37 FPS when you set RTSS to FR=0/SSx/2=60, are you certain your monitor is running at 60 Hz?  Could it be running at 75 Hz?

 

Well the nVidia control panel says the monitor refresh is at 60Hz during the sim.

6 minutes ago, Luke said:

This reminds me of a similar trick back in the FS9 days where you could manually tweak the affinity of FS9.EXE in task manager and it seemed to use two cores. Instead of being 100% on one, it was 50% on two. Strangely enough the sum between the cores never seemed to exceed 100.... I wonder?

At the end of the day, there is nothing you can do in Windows to make a single thread divide its work between multiple cores. What I suspect is happening is that the kernel is switching the thread between cores rapidly, more often than Task Manager updates so it looks like two cores are being run. Instead of spending 1000ms executing on a single core, it's spending 500ms on a core, and 500ms on another. I suspect it helps you a little because it may reduce thermal heating on that core, and it hurts you a LOT because you're likely flushing your L1 and L2 caches on a regular basis.

But no matter what, there is no silver bullet. Sequential code is just that, sequential.

Hmm. Just fired up the sim again. Didn't do the core thing. Core0 hammered. other 5 cores at 30-50%.

Did the core thing. All cores regularly at max, and sim definitely smoother.

Get it - smoother. But no, I'll put it back to the old way which is obviously the right way and live with the stutters. 😉

I obviously don't actually know how it is actually programmed either. All I can do is report what I see.

Yes and I remember the split core = 100% thing. But that wasn't FSX/P3D. This is later code than that at least.

Hopefully LM will sort this out properly some time and recode the whole kernel of the sim.

 

Of course, it's a never ending story trying to tweak all this stuff.

There are simply too many variables for any human to keep up with. You change one thing and you have to tweak again - weather, location, speed, plane, etc, etc.

That's why none of us should be doing this. The blinking computer should be optimising all these things for us on the fly - literally.

Some day, huh...

3 hours ago, SledDriver said:

Top post on this page disagrees with you. Who is right?

Is it as suggested a the top of this page:

Framerate limit = 0
Scanline Sync = x/2

Or is it

Framerate limit = 30
Scanline Sync = x/2

Please don't guess.

When RTSS is set for using scanline sync the frame limiter is "autodisable".
In better words scanline has priority to frame limiter
That is what i read in RTSS forum in the morning from one of the DEVELOPERS (of rtss), so i think it is attendible. (If I understood correctly)
Unfortunately today I didn't have time to test it on my sim, so I can't give you information from my sim, but as soon as I try I will let you know