certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] FlightGear simulation latency


From: Martin Spott
Subject: Re: [certi-dev] FlightGear simulation latency
Date: Sun, 24 May 2009 21:23:20 +0000 (UTC)
User-agent: tin/1.9.3-20080506 ("Dalintober") (UNIX) (Linux/2.6.29.3 (x86_64))

Eric Noulard wrote:

> Some more FlightGear for dummy question,
> Why should the VirtualAir plugin call
> 
> set_hz()

FlightGear is designed to run (almost) everything in a single loop
(except Scenery tile loading). Now, in order to set Network I/O to a
certain rate according to the users' preferences, these subsystems are
calling 'set_hz'. Using 10 Hz for network 'slaves' typically makes a
good compromise between accuracy and loss of performance due to copying
the data out to the network stack. To my experience, coping out to the
net on the 'master' is much more a performance hit than reading in on
the 'slave(s)', no matter which protocol you use.

> If it is the case why should FilghGear do that kind of thing periodically?
> Won't it be easier to do it asynchroneously, "when necessary"?
> I thought it was the purpose of the dead reckoning to do such thing,
> am I wrong?

The purpose of dead-reckoning is to predict how a vehicle is likely
going to move within a certain time frame.
FlightGear is using a very simple flavour of dead-reckoning and it's
doing this on the reciever side only. The sender doesn't do any
calculations (in contrast to dead-reckoning in DIS for example). Thus,
doing things periodically is presumably only related to transmitting
network packages on the sender side (say, 10 packets per second).

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]