Re: [certi-dev] FlightGear simulation latency

[Eric Noulard]

2009/5/24 Martin Spott <address@hidden>:
> Hi Eric,
>
> Eric Noulard wrote:
>
>> By the way, Martin, how do you measure the latency with FilghtGear?
>
> Oh, I'm using a rather simplistic approach by comparing two views on
> the same aircraft visually, using outside views and a stopwatch  :-)
>
> 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.

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?)
and 1 process for the corresponding RTIA (try "pgrep rtia"), plus
the RTIG.

All those processes may be competing for CPU (even if they essentially
do nothing but select / receive / send messages).
Say that your typical simulator run at 20Hz your and send 4 messages per-cycles
you'll be sending 4*20*4 = 3200  msg/second.

You can have a good idea of the number of HLA messages sent by
each simulator when terminating the virtualair process CERTI should
print by-message statistics.

>  Now I'm configuring
> FlightGear's views in a way that the 'master' instance which is running
> planeA internally as well as the 'slave' instance (via HLA) both show
> the same view on planeA.
>
> In order to set a visual 'marker', I'm taxiing a Cessna 172 along some
> runway and then I'm hitting a key to toggle full brakes - which lets
> the Cessna on the 'master' view rotate around its pitch axis (nose
> down) instantaneously. As a reference I'm taking the moment when the
> nose gear compression has reached its maximum (to allow dead-reckoning
> to gain some influence). With the current setup (RPR FOM), the period
> from hitting the brakes until the nose gear has reached maximum
> compression is large compared to the HLA/MultiPlayer latency. Now I
> just have to measure the time until the aircraft on the 'slave' view
> fulfills the same movement.
>
> I know, this setup doesn't meet typical requirements for scientific
> data aquisition, the method is prone to errors, but the net results are
> still pretty good

If the test fulllfills your needs, that's obviously a good way to go.

>  - especially given the alternatives:
> 1.) Using a simple boolean value as a marker, setting it on the
> 'master' and measuring the time until the change becomes visible on the
> slave would be an option. But this doesn't buy us a lot because it
> would circumvent dead-reckoning techniques - which are highly
> appreciated.

Yes you are right.

> 2.) Using the setup as described above (Cessna taxiing, hitting full
> brakes), configuring both master and slave to write pitch values of
> planeA out via network socket at a high rate. This would, itself,
> induce error due to the fact that writing the data out at a high rate
> slows the simulation down to a noticeable extent and therefore doesn't
> yield 'better' results compared to the simplistic approach which I'm
> currently using ....

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.
The idea is to stay away from *ANY* system call during the
observation phase, you should only do memory copy.

With today's number for PC main memory size and speed
this may be an acceptable solution too. There is an overhead
but in the 1-64Hz range this should be fine.


-- 
Erk