[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [certi-dev] FlightGear simulation latency
From: |
Eric Noulard |
Subject: |
Re: [certi-dev] FlightGear simulation latency |
Date: |
Sat, 23 May 2009 15:15:20 +0200 |
2009/5/23 Martin Spott <address@hidden>:
> Hi Petr,
>
> "Gotthard, Petr" wrote:
>
>>> 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.
>>
>> Brilliant! I tell you why: The RPR FOM has entries for velocity and
>> acceleration, while the ASN does not. The native dead reckoning
>> algorithm thus works only for the RPR FOM, what makes the latency
>> similar to the native MultiPlayer.
>
> Oh yes, after re-reading through the different FOM's and the
> corresponding player-xxx files I was already suspecting such a
> correlation.
> I noticed that even RPR doesn't support angular acceleration -
> appparently the folks at SISO don't consider it to be meaningful for
> dead-reckoning in such a use case.
Concerning dead-reckoning for which I am quite a newbie,
could one of you explain how the distance between
"exact/high-fidelity position" and the "extrapolated position" is measured?
I mean the only entity which may compute this is the one which runs
the high-fidelity model, because otherwise it would require the packet
for which DR is precisely made for?
Am I right?
example: a simulation with 2 entity planeA and planeB
planeA is using DR for both the planeB data and its owns data
along with the 'high-fidelity" model for itself and then compare
the DR value for itself and the "high-fidelity value" and send
an update (to planeB) with new high-fidelity values when the
DR threshold is reached, is that right?
> Thanks for sharing your insight with me,
>
> Martin.
> P.S.: If the CERTI folks feel uneasy about me polluting the list with
> FlightGear-related stuff, please don't hesitate to complain.
No complain, we are learning :-)
The CERTI ML is not that high number of msg ML to be disturb with
user's application test case.
--
Erk
- Re: [certi-dev] CERTI billard test / http_proxy, (continued)
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- RE: [certi-dev] CERTI billard test / http_proxy, Gotthard, Petr, 2009/05/22
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- Re: [certi-dev] CERTI billard test / http_proxy, Martin Spott, 2009/05/22
- RE: [certi-dev] FlightGear simulation latency, Gotthard, Petr, 2009/05/23
- Re: [certi-dev] FlightGear simulation latency, Martin Spott, 2009/05/23
- Re: [certi-dev] FlightGear simulation latency,
Eric Noulard <=
- RE: [certi-dev] FlightGear simulation latency, Gotthard, Petr, 2009/05/23
- Re: [certi-dev] FlightGear simulation latency, Martin Spott, 2009/05/23
- RE: [certi-dev] FlightGear simulation latency, Gotthard, Petr, 2009/05/23
- Re: [certi-dev] FlightGear simulation latency, Martin Spott, 2009/05/23
- RE: [certi-dev] FlightGear simulation latency, Gotthard, Petr, 2009/05/23
- Re: [certi-dev] FlightGear simulation latency, Martin Spott, 2009/05/24
- Re: [certi-dev] FlightGear simulation latency, Martin Spott, 2009/05/25
- RE: [certi-dev] FlightGear FOM, Gotthard, Petr, 2009/05/25
- Re: [certi-dev] FlightGear FOM, Martin Spott, 2009/05/25
- Re: [certi-dev] FlightGear FOM, Jon Stockill, 2009/05/25