22 hours ago, newtie said:

Unless one has to wait while the other takes his turn 

Exactly. 

In the early days of hyper-threading Microsoft recommended that SQL Server not be deployed on a HT machine. The reason for this was that too often the second thread (logical thread#=odd) would obtain a lock and enter a wait state. The first thread (logical thread#=even) would then get dispatched, but could not do much because the resource was locked on the inactive thread that had to wake up first, etc, etc, etc. Of course, all those threads also introduced "convoy" and "race" conditions where all the threads when dispatched tried to obtain the same resource. 

Eventually, Microsoft figured it out and SQL Server is now an excellent multi-threaded application for huge number of threads, whether multi-core or multi-socket systems. We can only hope that Lockheed-Martin achieves the same measure of success! 

That's kind of correct but when the proper AM was applied for ht they had little problem with slowdowns and heat.

...I remember a dual CPU machine with one better cooled CPU so the most intensive work was moved onto that with the AM as well as making considerations for HT - they went well. Of course, there ware some with SQL queries coming to the same conclusion after millions of unnecessary calculations, but that's another way to overstress a machine.

6 minutes ago, Howellerman said:

Exactly. 

In the early days of hyper-threading Microsoft recommended that SQL Server not be deployed on a HT machine. The reason for this was that too often the second thread (logical thread#=odd) would obtain a lock and enter a wait state. The first thread (logical thread#=even) would then get dispatched, but could not do much because the resource was locked on the inactive thread that had to wake up first, etc, etc, etc. Of course, all those threads also introduced "convoy" and "race" conditions where all the threads when dispatched tried to obtain the same resource. 

Eventually, Microsoft figured it out and SQL Server is now an excellent multi-threaded application for huge number of threads, whether multi-core or multi-socket systems. We can only hope that Lockheed-Martin achieves the same measure of success! 

This is what bothers me about adding processes to mange processes.. I call it 'minimal fps impact' creep.

The apps that many of us run, AS, Chaseplane, UTLIve, Simstarter, ProcessLasso, etc. are all billed as having a minimal fps impact and that is true on an individual basis. Collectively, not so good. I'm learning as I go along that if I can possible manage P3D with the tools that are provided, I'm better off. I think many isolated or unidentifiable problems are the result of too many processes running at the same time with too many sliders past their useful maximum. Then we turn on HT and start assigning. Often, this error becomes self evident with a fresh install of P3D or refreshing the .cfg file.

Do I run AS (from a batch file) and Chaseplane, yes. I have also run AS with SimpleCam from AivlaSoft, no overhead running process. Anyway, that's a hit I'm willing to take.

Cheers,

Mark

12 hours ago, GSalden said:

 

Wheh using a Locked framerate you do not have to set Vsync or TB . Vsync and TB do nothing in Locked mode. However , in locked mode frames are more correctly spread apart in the same time then Unlimited . 

Hi Gerard (or anyone that might have an an answer)

Is it really true that if you select a locked frame rate in P3D the Vsync and TB functions are basically disabled and have no impact?

Thanks in advance

Joe

Edited March 22, 20188 yr by joepoway

Yes.

What do you think happens when you lock your framerate to 25 and use Vsync icw a 60 hrtz monitor.... ?

Edited March 22, 20188 yr by GSalden

2 hours ago, SteveW said:

No. Problem there Mike is your AM it uses all cores and by doing that it must share the load with everything.

Hi Steve,

Drat! There was I believing I understood this stuff. Quite clearly I need to return to the drawing board. I have been assuming that the Windows Job Scheduler would allocate free resources (amongst the 8 unused LPs) appropriately and I wouldn’t have to set individual apps manually. Life is rarely so simple. However, to be fair, general performance seems very good and these juddering instances are mostly, but not always, confined to denser scenery areas. I suppose the latter could be a red herring and in fact it’s a background process or processes unrelated to P3D that are competing with the main thread for attention.

While P3D is running I note activity on LPs 0, 4,6,8,10,12 and 14. LP0 is the busiest (main thread and all that) while the others are showing varying percentage activity (approx. 20-70 with occasional brief peaks at 100%) according to demands imposed by approaching Scenery.

Also, and for whatever reason, I am noticing some blurry textures nearby as I fly. This is most noticeable in mountainous areas as I admire the detail of the mountainside texturing. Often this clears spontaneously as I get closer and at other times there is no problem whatsoever.

I’ll give your suggestions a shot and report back.

Thanks!

Regards,

Mike

Edit: If possible, I would like to continue with HT=ON as there appears to be no downsides with everything else installed and I have yet to see a core rise above 70C while P3D is running.

 

 

Hi Mike, If you think of the four core guys getting good results, can we automatically expect good results with the same hardware and double the core count? Not as much as we would hope because the resource is spread wider. Simply whacking in 8 cores for a job doesn't make sense for a flight sim, rather a video encoder would suit that kind of setup.

6 minutes ago, SteveW said:

Hi Mike, If you think of the four core guys getting good results, can we automatically expect good results with the same hardware and double the core count? Not as much as we would hope because the resource is spread wider. Simply whacking in 8 cores for a job doesn't make sense for a flight sim, rather a video encoder would suit that kind of setup.

Hi Steve,

I suspect there will be a few smiles after having read that response 😉

Fortunately I know I can and do achieve very good results....most of the time. The challenge comes with tuning for ‘perfection’.

Regards,

Mike

Of course if we give anything 8 cores it should work well enough - right? We're not talking about that we're talking about how things are optimised.

For example, got three wheels on your plane yeah? Why not whack on another three, since wheels are cheap.

Of course not - there's an optimum number of wheels.

Let's say you find the scenario loads fastest with 7 cores

01,01,01,01,01,01,01,00

you add an 8th

01,01,01,01,01,01,01,01

and the scenario doesn't load any faster so we need 7 cores - right?

 

You have not yet come to the conclusion you are looking for.

 

Next we need to address the work done by our addon exe apps that run alongside the sim, the weather and traffic, maybe also some panel drivers and so on.

We may find we need more room for those and yet we want to maintain that scenario loading speed.

00,01,11,01,01,01,01,00

we might find that's pretty close if not just as good and yet yields an entire core to the rest of the system.

 

55 minutes ago, GSalden said:

Yes.

What do you think happens when you lock your framerate to 25 and use Vsync icw a 60 hrtz monitor.... ?

Sorry for my ignorance but if you look at my posts and signature you’ll see that I run a 30 Hz monitor. So my question is really about Vsync and how it works. I wasn’t sure if locking 30 FPS actually forces a true Vsync with a 30 Hz monitor or if they just happen to be running at roughly the same frequency. As I understood things Vsync actually manages frames diffferently but based on your response I must be incorrect.

So that’s why I was wondering if I ran 30 FPS locked and didn’t enable Vsync and TB that the video frame management might be different and not as robust in terms of any potential missing frames if my FPS dropped momentarily below 30.

I’m surprised the user interface in P3D lets you still enable or disable TB and Vsync regardless of the locked or unlimited frame state?

Thanks for the reply

Joe

P3Dv4 works better than the older sims on HT systems with few cores because it splits out onto those LPs in a way that leaves the main threads working well. That's not to say we don't need to do anything. With many cores we need to know what we are doing. Too many LPs allocated comes to no greater performance and is dissipated as heat.

The sim sits on a bedrock of highly threaded resources that respond better to an HT enabled system. If we have an overclock optimised for HT Disabled and we want use HT=On, the overclock might need to come down a bit to accommodate the extra heat from the extra work done.

 

With P3D forget what we know about Vsync. Instead when looking at the P3D display settings window, Vsync=On means each next frame will be adapted to the refresh timing of the monitor. The hidden desktop display settings control the vsync that without proper timing cases the tearing we associate with older technology. The TB is a third frame buffer which improves the frame to frame time associated with the locations and physics in the sim, it won't alter the way the view looks.

Edited March 22, 20188 yr by SteveW

With Locked framerate the Vsync and Triple Buffer are replaced with a different system. The back buffer frame memory is used for look-ahead frames which are built ahead of time, generally three. These frames get used up very quickly with any kind of wobble in the flow and the exact time between frames cannot be maintained. This can't go on for very long before the buffer is exhausted. The buffer might take many frames, even seconds just to get back to three ahead.

So although the system has been improved in DX11 and by LM, we must still have a very powerful system or Locked must be used sparingly on low framerates.

34 minutes ago, SteveW said:

With Locked framerate the Vsync and Triple Buffer are replaced with a different system. The back buffer frame memory is used for look-ahead frames which are built ahead of time, generally three. These frames get used up very quickly with any kind of wobble in the flow and the exact time between frames cannot be maintained. This can't go on for very long before the buffer is exhausted. The buffer might take many frames, even seconds just to get back to three ahead.

So although the system has been improved in DX11 and by LM, we must still have a very powerful system or Locked must be used sparingly on low framerates.

Steve

Thanks for the response, a couple of clarifying questions:

Is the “different system” used when locked frames are deployed independent of the user interface checked boxes? In other words does it automatically deploy whether you check the Vsync and TB boxes or not.

 

My original interest in this post regarding FFTF was my system runs pretty well with unlimited, TB and Vsync to maintain the 30 FPS for my 30 Hz monitor. I do however get periodic blurries and since unlimited forces FFTF=0.01 I was thinking of increasing it with the config mod to 0.05 assuming I still have enough CPU overhead to better enable terrain loading time hopefully better dealing with some occasional blurries.

 

Also I recall from days of old big debates on whether FFTF could really be set below 0.1 but it looks like 0.01 - 0.09 are ligitamate values?

 

For now I’m not ready to move to a real-time FFTF adjusting tool but this is where I am heading:  Unlimited, TB on, Vsync On (with my 30 Hz moinitor) and add FFTF=0.05  What do you think in terms of helping with blurries, basically the point of this original post by Gerard?

Thanks

Joe

 

Edited March 22, 20188 yr by joepoway