Hows that Nvidia Frame limiter working out?

[SN737 140]

Reinhard,

I use Panel Position tool to restore undocked pop-up panels, works like charm, First step will be, just for one time, undock panel/s, position them where you like and press panel store; then next p3d session the only thing you need to do is undock the panels you wish to and press panel restore. Google Panel Position, you should find it, if you don't PM me and I'll send it to you. If you have more than one screen and wish to take advantage on the 1/2 refresh and external fps then you are lost, it kills your fps, un-usable.

Edited February 24, 2020 by SergioN

[B777ER 2,486]

On 2/23/2020 at 12:08 PM, Chapstick said:

I don't understand how this is possible. You're literally getting zero stutters? So landing at a major airport like JFK or ORD it's perfectly smooth, all the way down?

For the most part, yes. Smooth even at FSDT KORD new version. Occasionally with a older, not as optimized scenery I may get a couple stutters such as in FSDT KMEM. Most sliders are all to the right expect for autogen at high and autogen density at medium. But I have a 9900k processor.

Edited February 24, 2020 by B777ER

[aua668 5]

3 hours ago, SergioN said:

Reinhard,

I use Panel Position tool to restore undocked pop-up panels, works like charm, First step will be, just for one time, undock panel/s, position them where you like and press panel store; then next p3d session the only thing you need to do is undock the panels you wish to and press panel restore. Google Panel Position, you should find it, if you don't PM me and I'll send it to you. If you have more than one screen and wish to take advantage on the 1/2 refresh and external fps then you are lost, it kills your fps, un-usable.

Hi Sergio,

The position of my undocked panels is not my problem. It works perfectly with my saved scenarios. But If you want to use the method of frame limiting discussed in that topic, it's not possible, because the undocked pop-up panels reduce the frames as described. and docked panels don't restore. And I don't want always to dock/undock my panels.

So I have only to stay with the internal limiter and my undocked panels on the right position or I could use this new method of limiting the frames, which really works well (core 0 is only loaded to 80% and the sim works very smooth) but my panels would not be at the correct position.

I documented my findings here for those, who get similar effects of frames reduced by half, one third etc.
So let's return to the topic, how the limiting of frames via nVidia performs...

Rgds
Reinhard

 

[SteveW 1,792]

On 2/23/2020 at 4:19 PM, GSalden said:

They are running at 25 hertz / Vsync on / NV Limiter at 26.

Not using Vsync leads to tearing on my WidevieW client pc.This is smooth without stutters or tearing.

Before I used 30 hertz but with TE GB London area I could have AG set to Very Dense + Clouds/Terrain Shadows and bad weather ( rain) I got some small stutters . Using 25 hertz gave my server ( dual monitor view ) the extra breathing space it needed to run smooth.

This is a multisession setup? The lowest fps is chosen so it is unclear how the system plays out. In any case I can't see why limiting at 26 for 25 monitor refresh can help. Sending a frame early with VSync eats the frame. Some fps plots show the system trying to vsync in two places. Setting up on mine I put the server in locked 20 and allowed the other node to train to it. Setting a limit above what you need may be simply helping a problem of the server running faster than the other node.

[SteveW 1,792]

Whether arriving a little early or a little late the coincidence spans one frame time forward or backward. So there's no difference in stutter as nothing is any different.

Without VSync the shift in the view is apparent where the buffer had got to before the flip, with VSync the old frame is held while the next frame is assembled.

Instead, the limiter set above the refresh division requires more CPU throughput to maintain the shorter frame to frame time and lost frames are redrawn right away, incurring extra load. The higher fps can show on a graph a higher average fps or quality since most every cycle a spare frame is assembled. We don't see them just the same as we don't see 70 frames per second on a 60Hz monitor, the excess ten are lost.

So far NCP seems to do what it says on the tin. The limiter works after the fact so there's a latency that affects the overall consistency. With VSync applied (P3D Display Settings) early frames cause no delay in drawing the next frame, so as to be unlimited at that point. This can show peaks in fps that draw on the CPU throughput and elongating the next frame. The sawtooth effect can arise.

Later I hope to find time to compare to other limiters. All they do is decide for the GPU the period between frames. There is not a precise consistency unless the limiter is ignored and the simulator uses the internal P3D locked fps setting.

 

[GSalden 4,657]

47 minutes ago, SteveW said:

This is a multisession setup? The lowest fps is chosen so it is unclear how the system plays out. In any case I can't see why limiting at 26 for 25 monitor refresh can help. Sending a frame early with VSync eats the frame. Some fps plots show the system trying to vsync in two places. Setting up on mine I put the server in locked 20 and allowed the other node to train to it. Setting a limit above what you need may be simply helping a problem of the server running faster than the other node.

This is a WidevieW setup. 
Like I wrote with Vsync On + NV limiter set to 1 FPS more than the monitors refreshrate I got rid of small stutters in very detailed areas.

Without the NV Limiter still sometimes the framerate goes up to 2-3x the monitors refreshrate ( going from full cpu load to less cpu load ) . And that is on both pc’s.

So I am quiet satisfied..

[SteveW 1,792]

is it a true 25Hz?

[SteveW 1,792]

if there are more than one monitor that can also play a part too. So it is unclear.

I think emphasis on using a limit above the refresh rate could be circumventing another thing and the aspects of limiting that I am describing is another matter.

Vsync itself will hold the frame and that gives rise the small trembling or long frames. but then even on a 30fps system with a 60Hz monitor the frames can only be elongated by 1/60 s.

Even so, I have been unable to produce a better effect limiting above refresh on single monitor single session systems which I would say is the norm. they use more CPU that's for sure. Otherwise it's hard to spot visually when the system is capable of double the 30 limit unchecked.

Spikes and stutter are more to do with some other aspect of the system.

[SteveW 1,792]

So I don't buy into it, limiting high with VSync. 😊

Of course with going high, that is also going to be below the next coincidence time.

In short, it's only a fantasy, there's no gain in limiting above what we want to limit to.

We can only approach the next coincidence time and we use more CPU to do that.

But eventually we reach above the real frequency of the monitor, say 70fps on a 60Hz, the frames are lost just the same - that is it. try unlimited no vsync and we might see fps even in the hundreds.

But on a 60Hz monitor we only see 60 of those frames at max.

[Dirk98 354]

From my observations and comparisons last 7days or so: 

1) the best sustainable so to say "progression" in the most demanding area (EGLL 27R approach, LAM transition, ORBX EU England, AS Heathrow add wx or traffic to make it even havier) comes with the new NCP setting @29 or @30 FPS, while in P3D  - no VSYNC and at Unlimited frames, on a 60Hz monitor.

2) The most fluid picture overall but with several serious hiccups in the same area comes with RTSS 1/2 -1. The fps are sort of under pressure a bit, but that is seen on the counter mostly. In P3D VSYNC - Off, Unlimited.

3) NCP @29, in P3D VSYNC ON, Unlimited - is close to #2 but wth seemingly more little stutters here and there plus same couple of serious hiccups.

 

RTSS 1/2 -1 seems to be the winner if you don't fly into Heathrow. I think I'll fly # 1) above more and see how it is.

Thanks,

[micstatic 4,319]

Guys.  I'm bringing up this thread again with a question.  I've been using NCP to lock my refresh rate to 30hz (60hz monitor).  It works well, but want to try this RTSS deal to compare.  Does anybody have a list of steps to get me in business I can try so I can compare?  I've never attempted this away so starting at zero.  Any help appreciated.  Thanks. 

[micstatic 4,319]

nobody has any RTSS guidance?  Sorry to pest

[Dirk98 354]

Check out one of these videos in the list:

https://m.youtube.com/results?search_query=P3dv4.5+rtss+tutotial

[Ray Proudfoot 8,960]

Here are my own experiences using both P3D v3 and v4. on both FPS is set to unlimited with triple buffering enabled. First v3...

I use this version just for Concorde. In NCP I set max frame rate to 29. Resolution is 1920*1080 @ 60Hz. The stuttters are dreadful despite CPU0 not being anywhere near 100%.

In v4 the same settings but at 3840*2160 @ 60Hz result in a nice smooth sim with CPU0 activity only at 100% at major airports with lots of Ai aircraft. Otherwise CPU0 runs around 80-90%.

In v3 I have disabled max frame rate in NCL and because of the lower resolution and my 1080Ti CPU0 runs around 70% when airborne and peaks at 100% regularly but not continuously at busy airports with vastly reduced Ai because of VAS considerations. Performance is vastly improved.

In short, excellent for v4, not needed for v3.

[Noel 4,503]

I know setting monitor vertical refresh at 30Hz is less desirable than 60hz, but when P3D is set to unlimited w/ vsync I always get absolutely perfect smooth video provided the CPU & GPU stay ahead of 30fps and have for over 6 years on the last machine in P3D 3.4 and now w/ the new machine in P3D 4.5.  Is it trying to lose the 60Hz refresh for the (slightly to me) less desirable condition that may be compared to 60Hz I wonder why people here are still trying to eliminate stutters using other methods.  Is it losing the 60Hz screen you're after?