On Wednesday, March 02, 2011 11:32:46 AM Curtis Olson wrote: > Coming from the unix perspective, xntp is a pretty good tool for > maintaining a very accurate real time clock setting on your PC. If you > run this on all your machines they're real time clock should be *very* > close to in sync. Then things like --timeofday=noon should work well. > This is something that can be set remotely via the telnet interface. > > Curt. > > On Wed, Mar 2, 2011 at 6:58 AM, Harry Campigli wrote: > > I am looking to time sync 3 machines running FG over the network and > > would like to sync the sim times to one master machine. > > I have them all on nfs but it seems thats not quite the trick. > > > > So what ever time the master is working on, be it from command at start, > > or selecting for example "noon" on the gui menu, the others follow. > > > > I see in sim timing properties there are lots of values in the property > > tree, And I see system timing also comes via sim gear. > > > > Do is anyone familiar with the code know which is the root time source on > > the property tree? The one I can forward to the slave machines. > > And i guess i will need to stop the slaves from trying to overwrite this > > value locally. > > > > > > -- > > Regards Harry
ntp is very good at keeping clocks in sync with the actual time or with a specific machine. You should probably setup one machine so that it keeps it's clock synced to one or more external time servers via ntp and also acts as a time server on the local network. Its clock will be within perhaps 2 to 5 milliseconds of the actual offical time depending on how carefully you select your time servers and on how good or bad your network connection to the outside is. This could be improved by using a local reference clock such as a GPS receiver to be with in a few microseconds and some setups like this can be as accurate as 50 nanoseconds. Then set up the other computers to use the local time server via ntp. This should keep all of the clocks synced to within perhaps 5 to 10 microseconds of the local time server once things stabilize. If you use external servers for time keeping on all of the machines about the best you will do is to keep the machines synced to within perhaps 5 to 10 milliseconds plus you will generate more external network trafic than you need to. The above assumes *nix machines. For Windows machines about the best you can do is to keep the time within about 10 milliseconds of the external server(s). As an example of what is possible on a Linux box here is what my machine currently reports: $ ntptime ntp_gettime() returns code 0 (OK) time d119250f.15aa6088 Wed, Mar 2 2011 12:20:31.084, (.084631361), maximum error 298591 us, estimated error 309 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -0.104 us, frequency 101.576 ppm, interval 1 s, maximum error 298591 us, estimated error 309 us, status 0x2001 (PLL,NANO), time constant 4, precision 0.001 us, tolerance 500 ppm, This is using a Motorola Oncore UT+ GPS as a time source with ntp and Linux kernel version 2.6.36. As you can see the clock is off by slightly more than 0.1 microseconds (IE. 104 nanoseconds) when I ran this. The Oncore UT+ is a special purpose time keeping GPS. Hal
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
