Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

FlightGear I/O Considerations

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.


Understanding VSync

Note
Cquote1.png If you sync to the vblank signal in FlightGear (and have enough cpu/graphics hp) you can run at a very solid 60hz (or whatever rate your display refreshes at.) If you don't quite have that amount of hp consistently for all situations, there is a throttle-hz property you can set to force a slower update rate (maybe 30 or 20 fps ... ideally you want an even divider into your display update rate.) If consistent frame rates are your goal, there are ways to achieve that. However, because of the variability of systems and personal preferences, we don't turn a lot of this on by default.
— Curtis Olson (2009-08-05). Re: [Flightgear-devel] Multithreading support.
(powered by Instant-Cquotes)
Cquote2.png


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.

Cquote1.png 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.
(it comes from the CRT era, but is still valable today)


— i4dnf (Thu Apr 21). Re: What would enabling this option do...?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
Same thing happens if the GPU renders the frames faster than the monitor displays it, thus frames above 60 will get lost.


— i4dnf (Thu Apr 21). Re: What would enabling this option do...?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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
— i4dnf (Thu May 10). Re: Frame-rate impact of Random Buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— hvengel (Thu Sep 11). Re: 3.2rc1 Overall impression.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— hvengel (Fri Sep 12). Re: 3.2rc1 Overall impression.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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
— hvengel (Tue Apr 15). Re: grapics upgrade.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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
can detect the motion not being smooth but I suspect that it way below 60
FPS. In fact my gut feeling is that this is closer to 10 FPS. Think about
movies which are 24 FPS do these not seem smooth to you when you go to the
theater? In addition I believe that the current HDTV standard calls for 30
FPS. I think if it required more than this frame rate to get a smooth
presentation that the standard would have a higher frame rate. One other
data point the FAA requires that certified flight simulators must have a
frame rate of at least 10 FPS. My own experience with FG is that anything
over 20 FPS feels just fine as long as the CPU is doing everything it needs
to to keep each frame synced to what should be happening. So Andreas should
be golden at 60 FPS with his LCD display.


Cquote2.png
Cquote1.png 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
interval between passes of the electron gun at slower refresh rates. LCDs
don't have this issue because the pixels have a more or less constant output
at any setting. EI. no fading during the refresh cycle like a CRT and
therefore no flicker even at very slow refresh rates.


Cquote2.png
Cquote1.png 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.
— hvengel (Fri Sep 05). Re: 3.2rc1 Overall impression.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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).
— hvengel (Wed Apr 16). Re: grapics upgrade.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— hvengel (Mon Apr 21). Re: GPU stays ilde -> low fps.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— hvengel (Wed Jul 02). Re: FlightGear in Eyecandy Mode.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Hooray (Mon Mar 16). Re: How to increase your fps past 60... [.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Hooray (Mon Mar 16). Re: How to increase your fps past 60... [.
(powered by Instant-Cquotes)
Cquote2.png

Objective: High-Rate I/O

Cquote1.png 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.


But for some reason I cannot get flightgear to send data at a higher rate than 20 Hz. Even if I send the data to a file instead of UDP I still only get 20 Hz even though I specify 100Hz.

Is there some frequency limiter hard coded into flightgear that limits the generic output frequency to 20Hz? My target is to have around 100Hz.


— rokwell (Thu Jul 03). Low generic output frequency.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I am trying to record certain data during a flight at 100 Hz without success.


My main objetive is to record latitude, longitude, altitude, and attitude at 100 Hz to simulate later an IMU's output.

I am a Linux user, FG version 2.10.0

I executed:

$ fgfs --generic=file,out,100,fg.truth,insgns-truth

According to FG manual, this command saves data previously defined in insgns-truth.xml to the file "fg.truth" at 100 Hz, i.e., 100 samples per second. Well, data are saved at about 10 samples per second.


— rodralez (Wed Jun 26). How to record insgns data at 100 Hz.
(powered by Instant-Cquotes)
Cquote2.png

Workarounds

Cquote1.png 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:

--prop:/sim/frame-rate-throttle-hz=30


— Curtis Olson (2009-07-22). Re: [Flightgear-devel] Generic input protocol delay.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The main properties to adjust FlightGear's I/O rate are these:
  • /sim/max-simtime-per-frame - determines how long FlightGear may take to build a single frame
  • /sim/gui/frame-rate-throttled - determines the max frame rate used by FlightGear, you can use this to throttle your frame rate to a stable value that your system can safely provide (e.g. 25-35 fps)
  • /sim/model-hz - determines the FDM rate (some subsystems run interleaved with the FDM, e.g. the AP, defaults to 120)
  • /sim/speed-up - determines FlightGear's simulation rate, defaults to 1


And then there's obviously the "hz" (hertz) parameters itself supported by most I/O options (multiplayer, protocols, generic etc)

You may have to disable vsync throttling (which is typically around 60 fps/hz)

Unfortunately, all of these settings are extremely inconsistent and they have never been formalized, so how well a certain aircraft/FDM, and its subsystems (hardcoded or scripted) may support these properties is fairly random for the time being admittedly. This also applies to many instruments and dialogs which may deal with different properties and support them to varying degrees. Pausing the simulator, and which subsystems to halt, also isn't sufficiently formalized yet [1]. This kind of chaos would be prohibitive in a professional simulator, so we're kinda lacking structure and standardization here...

Also, not all hard-coded I/O options may fully support these properties (e.g. telnet/props).


— Hooray (Sat Jul 05). Re: Low generic output frequency.
(powered by Instant-Cquotes)
Cquote2.png

Misc

Cquote1.png 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.
Then again, in "fgcanvas" mode, it is possible to disable tons of features that you won't need - which means that AFTER disabling vsync, you can still get impressive update rates in terms of fps/frame space - for instance, here's Philosopher's Nasal/Canvas-based interactive Nasal console (REPL) running in fgcanvas mode on a 7-year old laptop (look at frame rate and frame spacing):

FGCanvas
Interactive_Nasal_Console
Nasal-REPL-via-fgcanvas.png


— Hooray (Fri Apr 03). Re: Simgear-based subsystem with Canvas support?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Hooray (Sat Feb 14). Re: Sometime, with Yasim... frame-rate is slow.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I only started with --model-hz=500 to make the difference really obvious

(see the linked image)


Cquote2.png

Problem & Background

Cquote1.png 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.)
— Philosopher (Thu Jul 03). Re: Low generic output frequency.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— curt (Wed Jun 26). Re: How to record insgns data at 100 Hz.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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


— Hooray (Thu Jul 03). Re: Low generic output frequency.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
Cquote2.png
Cquote1.png t can be done in several ways. The two most common is:



1. The command line parameter --prop:/sim/frame-rate-throttle-hz=40


2. Add <frame-rate-throttle-hz type="double">40.0</frame-rate-throttle-hz> inside the <sim> element in preference.xml


Cquote2.png
Cquote1.png 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.
— AndersG (Wed Jun 26). Re: How to record insgns data at 100 Hz.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png As AndersG pointed out, to get samples at 100 Hz value of /sim/max-sim-time-per-frame property has to be change.


After a few tests, I set /sim/max-sim-time-per-frame=0.0075 and got samples at exactly 100 Hz.


— rodralez (Fri Jun 28). Re: How to record insgns data at 100 Hz.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Three things to try:


1. Enable synch. to VBlank in your video driver.
2. Add --prop:/sim/frame-rate-throttle-hz=120 to your FGFS command line. (There is probably an option for this somewhere in the launcher GUI if you use that.)
3. Try both full screen mode and windowed mode. (--enable-fullscreen / --disable-fullscreen / --enable-game-mode / --disable-game-mode)


Bad things may happen when the frame rate exceeds the 120Hz update rate of the physics engine.


— AndersG (Tue Jan 15). .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— AndersG (Wed Mar 05). .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png solution: enable sync to vblank in nividia-settings or set /sim/frame-rate-throttle-hz=60 (or some other number < 120).
— AndersG (Thu Aug 14). Re: Help,fg too slow..unusable!.
(powered by Instant-Cquotes)
Cquote2.png