FlightGear I/O considerations
| This article is a stub. You can help the wiki by expanding it. |
Understanding VSync
Note
|
| Note In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).
While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible. |
|
VSync is short for Vertical Sync. It's also an option you can enable somewhere in your video card settings. In short it makes sure the monitor doesn't display parts from different frames at the same time, like the upper half from a new frame and the lower half from the old one. This is not an issue for static images, but as soon as you start moving things in the image it might become visible. More technical info here. |
|
|
|
That option helps with VSync (The option that reduces horisontal tearing when the card has to send a new frame to the monitor and it has not finished drawing it). With triple buffering VSync can happen at any frequency, thus improving framerates. Without triple buffering, VSync will progresively half the framerate with respect to the desired refresh rate (i.e 30, 15, 7 fps for a 60hz refresh rate), in order to keep frames in sync, basicaly keeping the same image for 2 cycles (or 4, or 8 ), until the GPU catches up. So it's generaly a good idea to keep it on, if you have VSync on. |
|
|
|
The thing about running with Vsync on is that you will always get 60fps (say) unless each frame takes longer then 1/60s (16.6ms) to prepare, which will cause a dropped frame as a minimum, and running at 30fps or 20fps if the interruption is longer. Even if the frame update time is 17ms (58.8fps) you will only see 30fps on screen.
Even one or two frames at half your regular frame rate will look like a stutter. If you are running with a high refresh rate (100Hz, 85Hz) you may want to reduce the refresh rate to 75Hz or even 60Hz to see if it reduces the stuttering. — Richard Bytheway (2007-04-11). Re: [Flightgear-devel] framerate hesitations....
(powered by Instant-Cquotes) |
|
|
|
OSX does the sensible thing and turns on vsync for your drivers, while windows doesn't. Try to switch off vsync if possible and you'll see much more than 60
|
|
|
|
Recent nvidia drivers have a new mode that will maintain vsync speed when it can and then get out of the way when it can't. I forget what it is called inside the driver UI so you will need to play around with it to locate the option (the vsync setting basically has 3 options off, on and the new mode - what ever that is called). I am currently using the new mode and I adjust my eye candy in FG to the point where I can maintain vsync most of the time (for my hardware everything is close to max). In this mode when the GPU load is high enough to cause things to slow down below vsync they only go a little below (IE. I seldom see less than 50FPS). Definitely worth looking into and over all much better than using the frame rate throttling in FlightGear or the older style vsync throttling in the NVidia driver.
|
|
|
|
I had trouble with the FG frame rate throttling on my machine in that it would throttle to 50FPS no matter what. Turning off the FG throttling and using the drivers adaptive vsync mode was a huge improvement and now I see 60FPS 95% of the time with very high eye candy settings both in the driver settings and FG rendering settings. Using the non-adaptive vsync driver setting I would see much larger frame rate hits when the video card was loaded so the adaptive setting is definitely the way to go. I haven't seen any posts here before about this and now that the usefulness of this setting has been confirmed by someone else I will get on the wiki and add this info.
|
|
|
|
For most users with normal resolution single monitor setups Nvidia cards in the $100 to $150 price range should give a very good FG experience although some eye candy may need to be turned off to get frame rates that are close to the vsync rate
|
|
|
|
Almost all LCDs have a native refresh rate of 60 FPS which works out to about 16.66 milliseconds per frame. There is a frame rate at which the human eye — Hal V. Engel (2007-02-24). Re: [Flightgear-users] sound stutters and frame rate drop on dual
core.
(powered by Instant-Cquotes) |
|
|
|
The reason to use higher refresh rates on CRTs is that this reduces the flicker that occurs because the phosphors start to fade during the longer — Hal V. Engel (2007-02-24). Re: [Flightgear-users] sound stutters and frame rate drop on dual
core.
(powered by Instant-Cquotes) |
|
|
|
A geforce 670mx is a powerful GPU and depending on the monitor resolution locking onto vsync (IE. 60 FPS) should be fairly common with that level of hardware even with high levels of eye candy.
|
|
|
|
My GTX 770 will run FG more or less locked onto vsync frame rates with all of the eye candy more or less maxed out at 2560x1600 (way over HD resolution).
|
|
|
|
One of the things I have found with the NVidia drivers is that if I set various things like how to set syncing to vsync and anti-aliasing settings so that these were set in the driver rather than in FG that this seemed to help frame rates significantly. This allowed me to bump the eye candy way up while still keeping frame rates at or near the vsync rate.
|
|
|
|
I have a high end system with a newer higher end I7 Intel processor (IE. one with 8 virtual cores that maxes out at 3.9GHz) with an overclocked 4GB GTX770 and 16G memory but I am also running a 2560x1600 monitor. I run ALS with all of the shaders more or less maxed out, random buildings, random trees and with some tweaks on the nvidia driver side. I generally see frame rates right at the vsync rate (60FPS) most of the time with max latencies of around 20ms most of the time. I turn off frame rate throttling in FG because this seemed to get the number wrong (IE. I would set it for 60 and it would throttle to 50) and use the dynamic throttling feature in the new nvidia drivers which seems to work great.
|
|
|
|
the merits of disabling vsync depends entirely on your use-case, especially in conjunction with frame rate throttling and time step acceleration or even just benchmarking to compare performance and draw conclusions, especially because of the generally non-threaded SGSubsystem architecture, e.g. restricting I/O subsystems - So the other obvious use-case is I/O (e.g. networking) requiring frequencies >= (or more stable) than your monitor's vsync rate. We've seen people doing Matlab interfacing or other scientific projects, where the standard 30-60 fps would not suffice, so they had to use a handful of different options to accelerate/slow down simulation rate and use a corresponding FDM rate, as well as an appropriate frame rate to ensure that all these numbers match up - for details, refer to the interfacing sub forum. I think AndersG has posted a number of explanations on configuring your computer accordingly.
|
|
|
|
disabling vsync will also give you a ballpark figure on maximum update rate per subsystem for your particular computer - e.g. even with rendering of aircraft/scenery/terrain and models entirely disabled via draw masks and vsync disabled, which shows up in performance monitor accordingly, which is why people like Mathias have been working towards decoupling rendering from the simulation main loop (fgviewer) and using HLA to partition the main loop into distinct components. Those people satisfied with 60 hz/fps, simply happen to be in the camp of people with powerful hardware who are not usually CPU bound/limited with their use-cases. Others however, are interested in seeing update rates beyond 60 hz for certain subsystems, so need to find a workaround to make that happen.
|
|
- http://www.techopedia.com/definition/92/vertical-sync-vsync
- http://gaming.stackexchange.com/questions/198184/what-is-v-sync-and-when-should-i-enable-it
- http://www.geforce.com/hardware/technology/adaptive-vsync/technology
- http://www.tomshardware.com/reviews/g-sync-v-sync-monitor,3699-5.html
- http://www.pcgamer.com/nvidia-g-sync-synchronizes-monitor-refresh-rates-to-the-gpu/
Objective: High-Rate I/O
|
|
I am trying to connect flight gear to a real autopilot. To do this I am communicating with the autopilot via UDP and I have written a code that converts all necessary data from flightgear and sends it to the autopilot in the correct format. Controls inputs from the autopilot is converted and sent back to flightgear. So far so good.
|
|
|
|
I am trying to record certain data during a flight at 100 Hz without success.
|
|
Workarounds
|
|
We do have a mechanism that uses a software timer based system so it is not perfect, but does seem to work pretty well. From the command line or your .fgfsrc file you can use the following option:
— Curtis Olson (2009-07-22). Re: [Flightgear-devel] Generic input protocol delay.
(powered by Instant-Cquotes) |
|
|
|
The main properties to adjust FlightGear's I/O rate are these:
Also, not all hard-coded I/O options may fully support these properties (e.g. telnet/props). |
|
Tweaking nvidia settings to obtain higher frame rates by disabling vsync to blank
Tweaking Nvidia Powermizer to obtain higher frame rates
Misc
|
|
Regarding your requirement to run the simulation at 700 hz - you need to differentiate between simulation and rendering - the latter often being affected by vsync, i.e. 60 hz/fps. That said, osg does have pretty good support for splitting up these two tasks. Like you say, the existing property tree/Nasal mechanism for using Canvas isn't designed for handling 700 hz/fps - mainly due to the way the main loop is structured, and due to the Nasal GC, as well as the fact that Canvas lives in the global property tree. — Hooray (Fri Apr 03). Re: Simgear-based subsystem with Canvas support?.
(powered by Instant-Cquotes) |
|
|
|
the "flight" subsystem will update fdm related properties - any code invoked by the FDM will thus also show up in the "flight" profile, including code triggered via listeners - which is why it is generally discouraged to register FDM listeners invoking Nasal code, because that makes the FDM non-deterministic, as the Nasal engine being invoked at FDM rate may mean that the garbage collector (GC) may be triggered, which means that duration of each FDM iteration may vary significantly. This is why it is generally favorable to use AP/property rules instead of Nasal for FDM coupled systems.
|
|
|
|
I only started with --model-hz=500 to make the difference really obvious (see the linked image) — Hooray (Sun Aug 19). Re: Actual programming language for autopilot implementation.
(powered by Instant-Cquotes) |
|
Problem & Background
|
|
all the protocols are limited by frame rate, so 100Hz might not be possible. (Running it with the FDM should be possible with a few C++ changes (minimum), but wouldn't be "steady" Hz, only an amount of Hz on average AFAIK.)
|
|
|
|
Because of the way FlightGear is structured, these numbers are only updated internally at FlightGear's rendering rate, and only output at this rate. So I suspect your computer is probably averaging about 10 fps running FlightGear. Really the only way to improve this is to turn down some of your graphics options or run on a faster computer ... or maybe you could post process the data file and interpolate @ 100 hz which would be somewhat fictitious, but add some white noise and it might be closer to reality than we'd like to think.
|
|
|
|
I/O is frame-rate dependent - typical frame rates are roughly 50-60 fps/hz. Thus, 100hz would seem like a lot, and it would never be steady either, because all I/O is running interleaved with the main loop, i.e. with other subsystems. Unfortunately, FlightGear's I/O system doesn't run in its own thread. Like Philosopher said, you /may/ be able to work around this by using an FDM-coupled subsystem,or by interleaving your I/O subsystem with the FDM, which may either require creative use of listeners & signals (property rules). Alternatively, you could throttle the frame rate to a sane value like 20-30 fps and then use accelerated sim time. I think several people have used this workaround in the past |
|
|
|
It might be possible to get the systems to run at a more even frame rate by setting the property /sim/frame-rate-throttle-hz to something the computers can deliver consistently. With that done the genlock might be able to get the systems to render in synchrony too.
— AndersG (Wed Aug 22). Re: jerky behaviour in flightgear when running in three comp.
(powered by Instant-Cquotes) |
|
|
|
t can be done in several ways. The two most common is:
— AndersG (Mon Aug 27). Re: jerky behaviour in flightgear when running in three comp.
(powered by Instant-Cquotes) |
|
|
|
You can also set the /sim/max-sim-time-per-frame property to 0.01 or less to force FG into running at at least 100 HZ in simulated time. The simulation rate is likely to be below 1, however.
|
|
|
|
As AndersG pointed out, to get samples at 100 Hz value of /sim/max-sim-time-per-frame property has to be change.
|
|
|
|
Three things to try:
|
|
|
|
it is also possible to view the current command line in fgrun (look around below "Advanced") and to set properties such as /sim/frame-rate-throttle-hz from the GUI - the corresponding --prop:/sim/... line should then show up on the command line fgrun sends to FlightGear. I don't use fgrun so I can't give more precise information on how to find these things there - but I know it is possible to do.
|
|
|
|
solution: enable sync to vblank in nividia-settings or set /sim/frame-rate-throttle-hz=60 (or some other number < 120).
|
|