Re: [Flightgear-devel] Making FlightGear more deterministic
Hi, On Freitag 04 März 2005 16:20, Curtis L. Olson wrote: I know this is hard to do with standard system level calls. For instance setitimer() in unix allows you to specify a very fine resolution sleep/wakeup time. However, the OS only checks the thread during a kernel interrupt which happens at 100hz. So you can only get divisers of 100hz resolution with this approach. This 100hz sound like the old HZ values of the Linux kernel. Note that Linux uses 1000HZ timer interrupt since some time. I do not know the exact time of the transition to 1000HZ but at least every 2.6 kernel uses this value. Anyway, I am not shure if times are limited to that HZ value. If you select on any filedescriptor you can specify microsecond timeouts for that. BTW this is the way qt implements timer events. It selects on the X11 socket (and possible other files the application is waiting for) with a given timeout. This works well on *NIX. Never tried that on Windows. But with qt4 this can change :) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Drew wrote: Hey All, I'm running flightgear on Windows, and have noticed that it seems to use up all of the available processing time, and because of this, it seems to get jumpy when other applications are being used while FlightGear is running. I noticed that I can try to bump up the priority of FlightGear, and everything else comes to a complete halt. I did experience that running Acrobat Reader and FlightGEar simultaneously does cause this behavior. To my opinion there is just one thing that can cause this, another application is also using OpenGL (or DirectX?) for it's rendering... This is done more and more to get hardware support for screen rendering. You might want to experiment a bit to see which program that might be. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Quoting Erik Hofman : Drew wrote: Hey All, I'm running flightgear on Windows, and have noticed that it seems to use up all of the available processing time, and because of this, it seems to get jumpy when other applications are being used while FlightGear is running. I noticed that I can try to bump up the priority of FlightGear, and everything else comes to a complete halt. I did experience that running Acrobat Reader and FlightGEar simultaneously does cause this behavior. To my opinion there is just one thing that can cause this, another application is also using OpenGL (or DirectX?) for it's rendering... This is done more and more to get hardware support for screen rendering. You might want to experiment a bit to see which program that might be. There is the property /sim/frame-rate-throttle-hz that could be used to limit the framerate but the source should be modified to call a system sleep method ( with a fine resolution, for example pthread_cond_timedwait ) instead of looping wildly. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Frederic Bouvier wrote: There is the property /sim/frame-rate-throttle-hz that could be used to limit the framerate but the source should be modified to call a system sleep method ( with a fine resolution, for example pthread_cond_timedwait ) instead of looping wildly. I know this is hard to do with standard system level calls. For instance setitimer() in unix allows you to specify a very fine resolution sleep/wakeup time. However, the OS only checks the thread during a kernel interrupt which happens at 100hz. So you can only get divisers of 100hz resolution with this approach. I could see something with pthreads being made to work, but that sounds like it could add a lot of complexity. The current throttling scheme is obviously not good if you are trying to do more than one FlightGear process on a machine, but it works quite nicely if you have one process per cpu and you want to lock to a framerate that you know your system can sustain. (i.e. you can't quite do 60hz reliably so you throttle down to 30 ...) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Erik Hofman wrote: Drew wrote: Hey All, I'm running flightgear on Windows, and have noticed that it seems to use up all of the available processing time, and because of this, it seems to get jumpy when other applications are being used while FlightGear is running. I noticed that I can try to bump up the priority of FlightGear, and everything else comes to a complete halt. I did experience that running Acrobat Reader and FlightGEar simultaneously does cause this behavior. To my opinion there is just one thing that can cause this, another application is also using OpenGL (or DirectX?) for it's rendering... This is done more and more to get hardware support for screen rendering. You might want to experiment a bit to see which program that might be. I don't mean to get into OS advocacy here, but it's been my observation that Windows runs single monolithic apps as good as any OS available. But when you want to run a lot of little apps, it's process management isn't as refined as unix, and apps quickly become less responsive than you like. Similar issue with files. Windows can handle big large files pretty much as well as the next OS, but when you start dealing with a lot of little files, the performance of it's file system starts breaking down. I know there are many more details underlying all this and I'm sure we could all swap stories about how our favorite OS outperforms the competition under some particular circumstance, but let's not. :-) Having said that, the operating system can't work magic. If you only have one CPU, it's going to have to be shared between all the things you need to run. If you run other applications, they will steal CPU time away from FlightGear making it jumpy. Unix has some nice process management features that can often hide these effect when additional lightweight apps are run, but again, it can't work magic. Also look at your disk activity. IDE drives require a lot of help from the CPU to do the reads/writes so if your other apps are loading or writing files and your disk subsystem is IDE, that can really kill your performance, and the OS can't help there. SCSI drives and controllers are a lot more expensive, but they can do DMA block transfers without involving the CPU so you can do a lot of disk IO and run a CPU intensive app at the same time without them stepping too much on each other. Just bear in mind that you are sharing resources if you are running multiple programs on your computer. FlightGear typically needs *all* the resources for smooth rendering, so running additional apps can cause jitters. Here's another tip ... enable sync to vblanc ... that will help stabalize your frame rate quite a bit and automatically throttle's flightgear to your monitor's refresh rate. I often tune down my monitor to refresh at 60hz (even though it can do higher) so that I can get a nice sync/frame rate with FG. When you sync to the vertical refresh signal of your monitor, and when you can sustain that rate, you get incredible silky smooth animation with FlightGear and it's a beautiful sight to behold! Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Curtis L. Olson wrote: Frederic Bouvier wrote: There is the property /sim/frame-rate-throttle-hz that could be used to limit the framerate but the source should be modified to call a system sleep method ( with a fine resolution, for example pthread_cond_timedwait ) instead of looping wildly. I know this is hard to do with standard system level calls. For instance setitimer() in unix allows you to specify a very fine resolution sleep/wakeup time. However, the OS only checks the thread during a kernel interrupt which happens at 100hz. So you can only get divisers of 100hz resolution with this approach. Indeed. For what it's worth, almost all full screen 3D apps end up spinning on the CPU, for exactly this reason. Trying to sleep for tiny amounts of time really isn't doable in a portable way. Under linux, the real time clock device can be programmed to provide an I/O wakeup to a process at fine intervale (and because it is I/O bound, it is at high priority and generally gets the CPU immediately). But that's not even portable to other Unix kernels, much less windows. Really, the best thing you can do is to turn on sync-to-vblank in the OpenGL driver. This will throttle the process* to the monitor refresh rate, at least. Andy * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Quoting Andy Ross: * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. From my experience, the latest non-beta Windows NVidia driver seems to eat CPU even with sync to vblank enabled. The CPU usage is always 100%. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
There is the property /sim/frame-rate-throttle-hz that could be used to limit the framerate but the source should be modified to call a system sleep method ( with a fine resolution, for example pthread_cond_timedwait ) instead of looping wildly. -Fred Just tried this, and I can make it run at half speed (30 Hz), but it still consumes 99% processor time. Je ne comprends pas! FWIW, I'm sure it's not a video card conflict. The only other process I'm running is just a standard Windows GUI...it's very small, not computationally intensive, but it's real-time critical (it's a crude simulation). 30 Hz is all I need because it's being sent to a TV display, anyway. Thanks again, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Frederic Bouvier wrote: Quoting Andy Ross: * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. From my experience, the latest non-beta Windows NVidia driver seems to eat CPU even with sync to vblank enabled. The CPU usage is always 100%. This made me curious, so I checked. In fact this bug *has* been fixed in the current NVidia linux drivers. Running a plain glxgears causes the CPU load to jump immediately to 100% and stay there as it reports 1500 fps on my laptop. Running it with __GL_SYNC_TO_VBLANK set to 1 causes it to report 55 Hz, and CPU usage just barely gets above zero. Nice. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Making FlightGear more deterministic
Frederic Bouvier writes:
Quoting Andy Ross:
* Hopefully in a CPU-friendly way. I know that older versions of
the NVidia drivers did this by spinning in a polling loop
inside the driver. I'm not sure if this has been fixed or not.
From my experience, the latest non-beta Windows NVidia driver seems to eat
CPU
even with sync to vblank enabled. The CPU usage is always 100%.
Buried in the PPE sources is a 'hackish' but portable way to
limit CPU usage if the desired framerate is met
/*
Frame Rate Limiter.
This prevents any one 3D window from updating faster than
about 60Hz. This saves a ton of CPU time on fast machines.
! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
*/
static ulClock *ck = NULL ;
if ( frame_rate_limiter )
{
if ( ck == NULL )
{
ck = new ulClock ;
ck - update () ;
}
int t_ms = (int) ( ck-getDeltaTime() * 1000.0 ) ; /* Convert to ms */
if ( t_ms 16 )
ulMilliSecondSleep ( 16 - t_ms ) ;
}
Cheers
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Making FlightGear more deterministic
Hey All, I'm running flightgear on Windows, and have noticed that it seems to use up all of the available processing time, and because of this, it seems to get jumpy when other applications are being used while FlightGear is running. I noticed that I can try to bump up the priority of FlightGear, and everything else comes to a complete halt. I'm trying to interface FlightGear with another application (which I'm writing), and would like it to behave more reliably while not hogging the processor for itself. What I'm wondering is, has anyone experimented with scheduling FlightGear to run at a slower rate, but with higher priority (perhaps adding 'sleep' calls to yield some processing time) so it will run more smoothly and reliably while other programs are running? Is this a Windows-specific problem, or does anyone have any additional suggestions? Thanks, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Making FlightGear more deterministic
I don't know if this applies to you, but my recent experience sounds somewhat similar. I have dual monitors, and inadvertently ran FlightGear on a monitor connected to my onboard graphics (instead of nVidia card). It worked okay by itself, but when I ran it with another OpenGL app on the 2nd monitor (the one connected to my nVidia card), everything slowed way down. When I put both monitors on the nVidia card I can run FlightGear on one, and my other OpenGL program that interfaces to it on the 2nd monitor, without issue. That works for me because both monitors are run off of one card. I read online that sometimes even if you have two 3d capable cards, hardware accelerated 3d will only occur on *one* of them at a time, so you can't run OpenGL apps on 2 monitors. That sounds very strange to me, but I never researched it enough to corroborate or debunk. I'm curious what kind of application you are interfacing FG to. I just recently added support to two of our (non-graphical) sims at work to output native-fdm style messages, and have had excellent luck doing so. I wish I could take credit for it when I show it to people at work who are very impressed with FlightGear, but really it's just because it's so easy to write a NetFDM object to the udp port that FlightGear expects it on. No messing with stupid DLLs. :D Good luck, Miles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Sent: Thursday, March 03, 2005 7:34 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Making FlightGear more deterministic Hey All, I'm running flightgear on Windows, and have noticed that it seems to use up all of the available processing time, and because of this, it seems to get jumpy when other applications are being used while FlightGear is running. I noticed that I can try to bump up the priority of FlightGear, and everything else comes to a complete halt. I'm trying to interface FlightGear with another application (which I'm writing), and would like it to behave more reliably while not hogging the processor for itself. What I'm wondering is, has anyone experimented with scheduling FlightGear to run at a slower rate, but with higher priority (perhaps adding 'sleep' calls to yield some processing time) so it will run more smoothly and reliably while other programs are running? Is this a Windows-specific problem, or does anyone have any additional suggestions? Thanks, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
