Re: [certi-dev] FlightGear simulation latency

[Martin Spott]

Hi Eric,

Eric Noulard wrote:
> 2009/5/24 Martin Spott <address@hidden>:

>> To be precise, I'm running two instances planeA and planeB of
>> FlightGear plus the RTIG on the local host.
> 
> In such test configuration you should be aware that observed latency
> may be **very** different depending on the number of processing
> unit (different core of the same CPU or different CPU of an SMP)
> you have.

I'm running this stuff on a NUMA-enabled dual-processor (dual socket,
single core) machine which is pretty good at distributing the load not
only over the two CPU's but also over their respective local memory.

> For each federate (should be each instance of virtualair) you'll
> have 1 process for virtualair (Question for Petr: or is it the same
> process as FlightGear?)

Yup, it's a subsystem which is linked into the one and only 'fgfs'
binary. Flightgear does a very little bit of threading, but just to
load new Scenery from the disk - which hardly occurs in the scenario.

> When sampling data at relatively high rate if you want to reach
> an acceptable "observation overhead" you usually want to
> store the sampled data in memory and dump-to-file when
> you know  you are done with your observation.

Indeed, I'm familiar with this sort of data aquisition. Yet, FlightGear
simply doesn't provide this option. It _might_ be an option to write
the data out onto a RAM disk, but writing out to a file would impose
certain difficulties to set accurate time stamps ....  not from a
technical point of view, FlightGear just does not provide such an
option.
Once we're getting really close to almost no latency (whenever this
would happen), when using the stopwatch doesn't provide sufficient
resolution any more, then I might investigate how I'd create nice
timestamps for writing to a file  :-)

Cheers,
        Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------