Re: [certi-dev] FlightGear simulation latency

[Eric Noulard]

2009/5/23 Gotthard, Petr <address@hidden>:
[...]
>> I just realized that there are a couple of nice papers on adaptive
>> dead-reckoning on The Net - this one being an example:
>>
>>   http://ducati.doc.ntu.ac.uk/uksim/journal/issue-1/Lee-Turner/B-
>> S%20Lee.pdf
>>
>> Yet I found very little mentioning of such an approach for HLA - do
> HLA
>> folks avoid dead-reckoning for design reasons ?
>
> Interesting paper. The described algorithm applies different techniques
> and sends different updates to different peer nodes. I think this is not
> possible with HLA because the updates are performed by RTI, which knows
> nothing about the transmitted values.

I think it might be possible using HLA DDM (Data Distribution Management)
DDM defines regions of subscription/publication.
Such that an update attribute value (UAV)
[ = HLA message to send a new value to "other interested" federate]
may be sent to a subset of federate which subscribe to the appropriate
"region".

I do not know DDM enough in order to be sure it would fits the need but
this seems possible.

DDM used to work with CERTI, but we did not played (nor tested) with it
since ...hum... some release ago :-(

Another possible way (to be confirmed)
to go would be to add support for  HLA Evolved SURR  (Smart Update
Reduction Rate) Service:

"Björn Möller, Mikael Karlsson. Developing well-balanced federations
using the HLA Evolved smart update rate reduction. Proceedings of 2005
Fall Simulation Interoperability Workshop, 05F-SIW-87, Simulation
Interoperability Standards Organization, September 2005."
http://www.pitch.se/images//05f-siw-087.pdf


2009/5/23 Martin Spott <address@hidden>:
> Petr,
>
> "Gotthard, Petr" wrote:
>
>> As you might have noticed, there is currently no synchronization nor
>> time management in the FlightGear/HLA. I'm afraid that any management
>> would only make the delays worse because the messages will never be
>> delivered faster than now. Or am I missing something?

I'm not so sure to agree with that, in an ideal world having a distributed
synchronous time among simulator would give you the mean to totally
control the networks messages. Thus ensuring you do not create
network flooding burst of messages.

Asynchronous as-fast-as-possible delivery may in some case
be slower that  time coordinated simulation. We do have example of
this kind of behavior using multi-satellite simulation:
ftp://ftp.cert.fr/pub/siron/08E-SIW-061.pdf

The real problem with time-constrained/time-regulator federate
is that one failing federate (or network connection to it) may block
the whole simulation which is clearly unacceptable for a
multi-player game.

> I just found out that using the RPR FOM (--hla=[...],RPR,RPR-FOM-v1.0.fed)
> induces just a fraction of the latency compared to using the ASN FOM
> (--hla=[...],ASN,AviationSimNet-v3.1.fed). In consequence, using the
> RPR FOM results in a latency which is similar to that of FlightGear's
> native MultiPlayer protocol.
> In contrast, increasing the update rate from 10 Hz to 25 Hz just adds
> to the latency (which sounds plausible),

It may be possible that for higher rate using time management
may improve latency. For slower rate I bet it won't change anything.

By the way, Martin, how do you measure the latency with FilghtGear?


-- 
Erk