Re: [Flightgear-devel] Syncing sim time
Hi all, I got an email from Jack drawing my attention to this topic. I have been out of the loop for a while, apparently a PhD thesis doesn't finish itself. Of course my fingers started twitching after Jacks' email, so I pulled in the latest git and tried a couple of things. I noticed the update to the cloud code using a dedicated rng seeded with the time block. On my systems this seems to work, in principle this is the same as the patch I used a while ago (which is in a custom FG repo: https://gitorious.org/csflightgear) the only difference I spot is that my patch also touched cloud code in Simgear. I didn't dive deep enough into the code to see if the simgear cloud code is still used, so I don't know if this is why Vivian is not having the correct results. If I remember correctly, there were two reasons to use a fixed seed. First, in the simulators we are using, there is no guarantee that the system clocks are in sync at all times. Yes they are running ntp, but still there is no guarantee nobody tinkers with a machine in such a way that the clock gets changed. The second, and more important reason, is to be able to run with exectly the same cloud field in different runs. Depending on the kind of experiment we are running, it can be useful or even necessary to present each subject with the same cloud field. Having said this, I think the current patches (either mine or the time slice one) are only temporary fixes. In my opinion, the randomness should end up in the property tree in some way. This should enable us to communicate it to different FG instances, be it on the same machine or across the network. This would not only help multi-screen/multi-machine setups, but would also benefit multi-player scenarios. Nothing is worse than diving into a cloud for cover in a dogfight with the other guy not having a cloud to obscure his view :) Enough ranting for now, as soon as I find some more time, I'm going to look at this a bit more. Cheers, Jan On Fri, May 10, 2013 at 5:58 PM, wrote: > Hi, > > Sent Stuart a set of diff files provided by Jan. > > If you would like copies, just holler. > > Jack > > - Original Message - > Stuart > > provides for > > on > > a > > You did indeed add some code - and I have tested it here on 2 machines and > on 2 instances on one machine. It doesn't seem to do what you intended. > https://dl.dropboxusercontent.com/u/57645542/clouds.png > I ensured that the 3D cloud settings were the same, using the same live > data. Do I need to do anything else? > Vivian > > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Syncing sim time
Hi, Sent Stuart a set of diff files provided by Jan. If you would like copies, just holler. Jack - Original Message - Stuart provides for on a You did indeed add some code - and I have tested it here on 2 machines and on 2 instances on one machine. It doesn't seem to do what you intended. https://dl.dropboxusercontent.com/u/57645542/clouds.png I ensured that the 3D cloud settings were the same, using the same live data. Do I need to do anything else? Vivian -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Syncing sim time
Stuart > Sent: 09 May 2013 21:41 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Syncing sim time > > Hi Jack, > > On Thu, May 9, 2013 at 3:57 PM, Jack wrote: > > Thanks to Jan Comans I've been able to sync the 3D clouds across three > instances of fgfs running on a multi-core machine. This, in turn, provides for > some very respectable frame rates of 40 to 50 fps per core with a three > projector system with older generation Nvidia boards ( GT430 and GT440 ) on > a 64bit I5 machine. The visuals will be just awesome once the collimated > display is completed later this year. > > Could you (or Jan) share with us what changes you had to make to allow > synchronization across multiple instances? I thought I'd added some code a > while back to make the pseudo-random number generator used start with > the same seed for a given 10 minute window to address this, but was never > in a position to test it myself. > You did indeed add some code - and I have tested it here on 2 machines and on 2 instances on one machine. It doesn't seem to do what you intended. https://dl.dropboxusercontent.com/u/57645542/clouds.png I ensured that the 3D cloud settings were the same, using the same live data. Do I need to do anything else? Vivian -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Syncing sim time
Hi Jack, On Thu, May 9, 2013 at 3:57 PM, Jack wrote: > Thanks to Jan Comans I've been able to sync the 3D clouds across three > instances of fgfs running on a multi-core machine. This, in turn, provides > for some very respectable frame rates of 40 to 50 fps per core with a three > projector system with older generation Nvidia boards ( GT430 and GT440 ) on a > 64bit I5 machine. The visuals will be just awesome once the collimated > display is completed later this year. Could you (or Jan) share with us what changes you had to make to allow synchronization across multiple instances? I thought I'd added some code a while back to make the pseudo-random number generator used start with the same seed for a given 10 minute window to address this, but was never in a position to test it myself. -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Syncing sim time
On Thu, 9 May 2013 14:57:21 + (UTC), castle...@comcast.net wrote in message <142462582.1782424.1368111441180.javamail.r...@sz0139a.emeryville.ca.mail.comcast.net>: > Hi, > > Thanks to Jan Comans I've been able to sync the 3D clouds across > three instances of fgfs running on a multi-core machine. This, in > turn, provides for some very respectable frame rates of 40 to 50 fps > per core with a three projector system with older generation Nvidia > boards ( GT430 and GT440 ) on a 64bit I5 machine. The visuals will > be just awesome once the collimated display is completed later this > year. > > However, all is not perfect in simworld. Since each CPU starts and > runs independently there is a skew in sim time for each core and AI > trsffic is just not usable with models "disappearing" into the screen > edge and then showing up at the adjacent screen boundary a few > seconds later. > > One possible solution is to start with the sim clock "frozen" and > once all instances have booted and initialized send out a control > packet via the native-ctrls protocols and unfreeze the clocks. A > better solution would be to use the fdm packets to start the clocks > since that protocol is already being used to sync the fdm slaves to > the master. This network method will still have a bit of latency; > probably the best solution is to have a freeze flag in a portion of > shared memory accessed by all cores and then clear the freeze state > once you are ready to run. This has an additional advantage of be > able to stop and start all instances with microsecond accuracy. > > Just wondering if anyone has messed in this area and has some > info/data on such things as to how much latency is tolerable before > the AI models start "breaking up" across screen boundaries? Is there > clock drift due to variations in delta t's for each CPU/GPU set based > on rendering times for each screen? Any need to send out a local sim > time standard to adjust for any drift and keep things in sync? > > Any thoughts, comments, suggestions would be appreciated and will > earn credits for sim time if you happen to be passing through the > Colorado Springs area. ;-) > > Cheers > Jack ..the ntp time server gives you too much skewed time? On a lan, you should have your box clocks within milliseconds from each other. Details in: http://www.ntp.org/ and http://en.wikipedia.org/wiki/Network_Time_Protocol ..install a ntp server on your master machine and ntp clients on your other machines. Or, set up a ntp server hardware box and run ntp clients on all your FG boxes, to bring them closer. You want the same time error on all your ntp clients. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Syncing sim time
Hi, Thanks to Jan Comans I've been able to sync the 3D clouds across three instances of fgfs running on a multi-core machine. This, in turn, provides for some very respectable frame rates of 40 to 50 fps per core with a three projector system with older generation Nvidia boards ( GT430 and GT440 ) on a 64bit I5 machine. The visuals will be just awesome once the collimated display is completed later this year. However, all is not perfect in simworld. Since each CPU starts and runs independently there is a skew in sim time for each core and AI trsffic is just not usable with models "disappearing" into the screen edge and then showing up at the adjacent screen boundary a few seconds later. One possible solution is to start with the sim clock "frozen" and once all instances have booted and initialized send out a control packet via the native-ctrls protocols and unfreeze the clocks. A better solution would be to use the fdm packets to start the clocks since that protocol is already being used to sync the fdm slaves to the master. This network method will still have a bit of latency; probably the best solution is to have a freeze flag in a portion of shared memory accessed by all cores and then clear the freeze state once you are ready to run. This has an additional advantage of be able to stop and start all instances with microsecond accuracy. Just wondering if anyone has messed in this area and has some info/data on such things as to how much latency is tolerable before the AI models start "breaking up" across screen boundaries? Is there clock drift due to variations in delta t's for each CPU/GPU set based on rendering times for each screen? Any need to send out a local sim time standard to adjust for any drift and keep things in sync? Any thoughts, comments, suggestions would be appreciated and will earn credits for sim time if you happen to be passing through the Colorado Springs area. ;-) Cheers Jack -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
