Advanced Question Orbiter Asyncronous Processes?

AssemblyLanguage

Donator
Donator
Joined
Jun 10, 2012
Messages
112
Reaction score
1
Points
0
I'm wondering how or if Orbiter implements asynchronous and maybe parallel processes.

I ask because I have identical (I think) scenarios running a take off of a heavy aircraft implemented with Vinka's SC4 and using Arlav's UAP on different systems.

On an AMD10 3,5GHz 12 GB, it pitches up at 80 m/s and takes off nicely at 100 m/s.

On a Celeron 2.13 GHz 8GB, it pitches up at 80 m/s but doesn't take off until 150 m/s -- well out onto the Edward's dry lake.

Both are running W10 x64. Why the difference?

Thanks
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
I'm wondering how or if Orbiter implements asynchronous and maybe parallel processes.

I ask because I have identical (I think) scenarios running a take off of a heavy aircraft implemented with Vinka's SC4 and using Arlav's UAP on different systems.

On an AMD10 3,5GHz 12 GB, it pitches up at 80 m/s and takes off nicely at 100 m/s.

On a Celeron 2.13 GHz 8GB, it pitches up at 80 m/s but doesn't take off until 150 m/s -- well out onto the Edward's dry lake.

Both are running W10 x64. Why the difference?

Thanks

AFAIK, Orbiter uses a variable time-step calculation for its numerical integration by default. This time-step is dependent on the graphics loop, so a computer with different graphics performance might run a slower integration cycle, perhaps resulting in different physics behavior, too.

I think this is the same thing that causes autopilots go wild on high time-accelerations, as well as causing orbit changes in past versions.

Try one of the fixed-length integration modes from the debug settings. Perhaps this will make both machines behave less different.
 

Majid

Active member
Joined
Oct 31, 2014
Messages
156
Reaction score
27
Points
43
AFAIK, Orbiter uses a variable time-step calculation for its numerical integration by default. This time-step is dependent on the graphics loop, so a computer with different graphics performance might run a slower integration cycle, perhaps resulting in different physics behavior, too.

I think this is the same thing that causes autopilots go wild on high time-accelerations, as well as causing orbit changes in past versions.

Try one of the fixed-length integration modes from the debug settings. Perhaps this will make both machines behave less different.

It's odd to me that the differences would be so pronounced. Couldn't this due to UAP issuing different guidance commands on the two machines?
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
I'm wondering how or if Orbiter implements asynchronous and maybe parallel processes.

Orbiter doesn't do asynchronous, the physics are entirely framelocked (texture loading is another matter). So the precision of the physics engine is a function of framerate and time acceleration. That said, add-ons are free to implement their own threading if the author thinks it's necessary. I don't know the architecture of UAP, but usually autopilots tie directly into the framelocked game-loop.
Still, that difference you got there is somewhat drastic. Do you have time acceleration on or something? How different is the performance on both systems?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
It's odd to me that the differences would be so pronounced. Couldn't this due to UAP issuing different guidance commands on the two machines?

Sure. It could be a variety of problems in this regards. Many control algorithms don't go well with variable time-steps.
 

AssemblyLanguage

Donator
Donator
Joined
Jun 10, 2012
Messages
112
Reaction score
1
Points
0
I don't know the architecture of UAP, but usually autopilots tie directly into the framelocked game-loop.
Still, that difference you got there is somewhat drastic. Do you have time acceleration on or something? How different is the performance on both systems?

UAP pitches up at the same point on both systems but I tried flying by hand just too be sure. Same results.

No time acceleration.

I'll check the frame rates.

I'll also play with the time parameters. It's been awhile since I had any dealings with Hrs. Runge and Kutta.

Thanks.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
It's been awhile since I had any dealings with Hrs. Runge and Kutta.

not sure those two guys are involved here. This would be the aerodynamics part of the engine screwing up.
Might be worth checking the atmospheric parameters of earth.cfg in both installs, though I don't see how there could be a discrepancy between the two.
 

AssemblyLanguage

Donator
Donator
Joined
Jun 10, 2012
Messages
112
Reaction score
1
Points
0
Maybe the difference can be attributed to Vinca's SC4. I tried a .dll vessel (DG Glider) and couldn't see much difference on the two systems

I would think Vinca is just mapping the .ini parameters to the Orbiter API but maybe more is going on. Anyone know?

I guess I will be moving my heavy aircraft to a .dll soon than I thought. I was hoping to work out the flight model with SC4 before moving to a .dll.
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
I implemented some async code for my recent LagrangeMFD. The usual model for MFD calculations is to implement something hooked to the clbkPreStep, with a single core to support multiple MFDs. For Lagrange, I wanted to be able to run tems of millions of calcs, out to an arbitrary calculation length (e.g. 0.1sec up to several seconds). I implemented this with the C++11 standard threading library, mutexes, and atomics.

See code at github.com/ADSWNJ/LagrangeMFD
 
Top