SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[DaveS]

On a more productive note: I found the source of the progressive fps slowdown we get at increasing time accelerations: a step subsampling feature in SubsystemDirector. Each time step it must do 3 calls to each subsystem, and it must do them (step length / 40ms) times, so as the step length increases with time acceleration the number of times those calls are done skyrockets. :compbash:

That explains that on slower PC's, although I never saw it on my older 4690K-CPU(Z-97)based machine. Something I did see and still do even on my current 7700K(Z-270) system is 20 second long load times for scenarios with the SSU orbiter in it. And this is even with an M.2 NVMe SSD.

Is this something caused by the systems initialization?

 

[GLS]

That explains that on slower PC's, although I never saw it on my older 4690K-CPU(Z-97)based machine. Something I did see and still do even on my current 7700K(Z-270) system is 20 second long load times for scenarios with the SSU orbiter in it. And this is even with an M.2 NVMe SSD.

Is this something caused by the systems initialization?

This subsampling only (visibly) slows things down when the time acceleration is used, and it adds more load on low fps situations, so it feeds back on slowness and slows things even further, etc...

About the loading taking time, my buck is on the mesh and texture loading weighing the most. After that I'd put reading files from the disk (also applies to graphics), and last I'd put the loading of our "code stuff". Yes, we have tons of code, and lots of it runs (only) at the start, plus memory allocation, etc, but we also run a truck load of code EVERY time step and if we were getting 10fps (not counting the graphics), and had 10 times as much code to run during loading, it would load in 1 second, let's even say 2, so IMO the code is not the long pole in the tent.

 

[DaveS]

This subsampling only (visibly) slows things down when the time acceleration is used, and it adds more load on low fps situations, so it feeds back on slowness and slows things even further, etc...

About the loading taking time, my buck is on the mesh and texture loading weighing the most. After that I'd put reading files from the disk (also applies to graphics),

It isn't. I just ran a number of tests,. all using the same scenario (Atlantis in orbit). First tests was with everything enabled to establish a baseline load time (~17 seconds). Then I disabled all of the orbiter textures, no change in load times at all, maybe a few ms.

Third tests was identical to the first tests but with the orbiter as a simple *.cfg based vessel (I used the default Carina, just altered the MeshName parameter). Dramatic reduction in load time, from 17 seconds to barely 4 seconds.

It's the same with the Carina mesh, which completely rules out the graphics. The load time is completely due to the code.

 

[GLS]

On an 14s load, I got a 2s decrease with loading just one small texture.
I also found about 3s for loading the aero data, which I currently know nothing about, so I still have to look at it to see if something can be done.

I'd like to replace all the mesh groups with a smaller version to see the effect of a smaller mesh file, but that would take all day... :facepalm:
There's something on an Orbiter manual about a binary mesh format that would be faster to load... anyone know anything about it?

---------- Post added at 12:57 PM ---------- Previous post was at 12:48 PM ----------

It isn't. I just ran a number of tests,. all using the same scenario (Atlantis in orbit). First tests was with everything enabled to establish a baseline load time (~17 seconds). Then I disabled all of the orbiter textures, no change in load times at all, maybe a few ms.

Third tests was identical to the first tests but with the orbiter as a simple *.cfg based vessel (I used the default Carina, just altered the MeshName parameter). Dramatic reduction in load time, from 17 seconds to barely 4 seconds.

It's the same with the Carina mesh, which completely rules out the graphics. The load time is completely due to the code.

Yes it is, because if you have no code, then no mesh or texture will ever be loaded. They are connected. One can say that creating the RCS textures and particle streams is "code" while the another can say that is "graphics". Most of the times it's hard, if not impossible, to separate things.

 

[Urwumpe]

Also, this isn't subsampling, AFAIR. We tested subsampling once in the past and it did not really solve all problems we had. The three steps are introduced for making sure, the subsystems work on the correct state data. The alternative would have been having a memento class for storing the subsystem states of all subsystems and create a copy of the old state before calculating the new state... which was much more evil to code. That is why the orbiter life-cycle was including in a smaller version inside SSU: Pre, Propagate, Post.

 

[GLS]

Also, this isn't subsampling, AFAIR. We tested subsampling once in the past and it did not really solve all problems we had. The three steps are introduced for making sure, the subsystems work on the correct state data. The alternative would have been having a memento class for storing the subsystem states of all subsystems and create a copy of the old state before calculating the new state... which was much more evil to code. That is why the orbiter life-cycle was including in a smaller version inside SSU: Pre, Propagate, Post.

Yes, we have those 3, but there are also 3 more:

		while(t0 < fSimT + fDeltaT) {
		double dt = min(SUBSAMPLING_DELTAT, fSimT + fDeltaT - t0);
		for(i = 0; i<subsystems.size(); i++)
		{	
			[COLOR="red"]subsystems[i]->OnSubPreStep(t0, dt, fMJD);[/COLOR]
		}
		//if(BusManager() != NULL)
			//BusManager()->clbkPropagate(t0, dt);
		for(i = 0; i<subsystems.size(); i++)
		{
			//
			[COLOR="red"]subsystems[i]->OnSubPropagate(t0, dt, fMJD);[/COLOR]
		}


		for(i = 0; i<subsystems.size(); i++)
		{	
			[COLOR="Red"]subsystems[i]->OnSubPostStep(t0, dt, fMJD);[/COLOR]
		}
		t0 += SUBSAMPLING_DELTAT;
		lSubCount ++;
	}

Like I said, I don't know is this, or something similar is going to be needed for the new DPS, but currently it is not used and creates a slide show at 100x or higher.

---------- Post added at 01:56 PM ---------- Previous post was at 01:50 PM ----------

There's something on an Orbiter manual about a binary mesh format that would be faster to load... anyone know anything about it?

It seams this isn't an alternative... :uhh:

ORBITER uses a proprietary mesh file format. Mesh files are ASCII text files. (A binary format may be introduced in the future).
(...)
meshc: mesh compiler. Eventually this may be extended to convert mesh files from text to a binary format (for more compact storage and faster loading)

 

[DaveS]

On an 14s load, I got a 2s decrease with loading just one small texture.
I also found about 3s for loading the aero data, which I currently know nothing about, so I still have to look at it to see if something can be done.

I'd like to replace all the mesh groups with a smaller version to see the effect of a smaller mesh file, but that would take all day... :facepalm:
There's something on an Orbiter manual about a binary mesh format that would be faster to load... anyone know anything about it?

---------- Post added at 12:57 PM ---------- Previous post was at 12:48 PM ----------



Yes it is, because if you have no code, then no mesh or texture will ever be loaded. They are connected. One can say that creating the RCS textures and particle streams is "code" while the another can say that is "graphics". Most of the times it's hard, if not impossible, to separate things.

There is code behind the *.cfg files. In fact they're the original code for add-on vessels. *.dll modules for vessels only came along much much later along with novelties such as animations and particle streams.

Even the default Atlantis loads in the same 4 seconds as the Carina tests. The only thing I can't test, is how much of an impact our VC has. I'd like to see a log of when each element is loaded. This way it could be definitely established what takes the longest to load.

 

[GLS]

There is code behind the *.cfg files. In fact they're the original code for add-on vessels. *.dll modules for vessels only came along much much later along with novelties such as animations and particle streams.

Even the default Atlantis loads in the same 4 seconds as the Carina tests. The only thing I can't test, is how much of an impact our VC has. I'd like to see a log of when each element is loaded. This way it could be definitely established what takes the longest to load.

The subsystems, mesh and texture loading, plus setup of pretty much everything takes about ~3.5s. If we don't load the meshes (Orbiter, Cockpit, VC, MidDeck, Ku_band_DA and SSU_entry), those 3.5s go down go to peanuts. (This means I'll really do something I've been considering for a while which is moving the Ku antenna mesh stuff out of the Atlantis class, as like the RMS, ODS, ExtAl, CISS, EDO, etc, it isn't mandatory, so it should only get loaded when it is needed. This won't gain much and it will only be when not using the antenna, but it makes total sense.)

Scenario loading, mission file loading, vc panel loading (now with panel meshes/textures) and a few more subsystems takes another ~2.5s. Loading a "huge" scenario vs nothing doesn't seem to change anything.

The aero data could be hardcoded as I don't see the need for it to be "configurable" as it is. IMO this is the only part where we might gain something on the code side... any volunteers for understanding all that aero stuff and 4D tables? :uhh:

 

[DaveS]

The subsystems, mesh and texture loading, plus setup of pretty much everything takes about ~3.5s. If we don't load the meshes (Orbiter, Cockpit, VC, MidDeck, Ku_band_DA and SSU_entry), those 3.5s go down go to peanuts. (This means I'll really do something I've been considering for a while which is moving the Ku antenna mesh stuff out of the Atlantis class, as like the RMS, ODS, ExtAl, CISS, EDO, etc, it isn't mandatory, so it should only get loaded when it is needed. This won't gain much and it will only be when not using the antenna, but it makes total sense.)

Scenario loading, mission file loading, vc panel loading (now with panel meshes/textures) and a few more subsystems takes another ~2.5s. Loading a "huge" scenario vs nothing doesn't seem to change anything.

The aero data could be hardcoded as I don't see the need for it to be "configurable" as it is. IMO this is the only part where we might gain something on the code side... any volunteers for understanding all that aero stuff and 4D tables? :uhh:

That still doesn't add up to 17 seconds. 3.5+2.5=6.0! This is from when the SpaceShuttleUltra vessel shows up on the load screen until scenario start (it's the last thing to be loaded). Even loading all the planetary stuff is rocket fast. Something is eating up CPU cycles. Is it systems initialization that takes so long? That's something only we do. That I could understand.

Moving on: How are we handling verniers currently? I think that they might be a bit too powerful as the orbiter is very sensitive when translating (doing prox ops).

 

[GLS]

That still doesn't add up to 17 seconds. 3.5+2.5=6.0!

The STS-1 orbit scenario I was loading took ~12-15s.
It's actually 3.5 (constructor) + 2.5 (state load) + 4.0 (module init, mostly the aero data) = 10s. I measured a few more but it's all in the tens or hundreds of a millisecond range.

Something is eating up CPU cycles. Is it systems initialization that takes so long? That's something only we do.

I took the mesh loading out of the equation and the constructor, where several duzens of systems are created + the all current GPC software, went down from 3.5s to tens of milliseconds. :shrug:

---------- Post added at 06:05 PM ---------- Previous post was at 06:00 PM ----------

Moving on: How are we handling verniers currently? I think that they might be a bit too powerful as the orbiter is very sensitive when translating (doing prox ops).

Probably by firing the current RCS thruster setup at 10% or something...
Our RCS is IMO very rudimentary. Making all the thrusters correctly and having all the visuals is easy, the big problem is creating the "RCS table" in the GPCs so when the vehicle wants to rotate in a certain direction, the correct thrusters are commanded for the correct duration...

 

[Urwumpe]

Like I said, I don't know is this, or something similar is going to be needed for the new DPS, but currently it is not used and creates a slide show at 100x or higher.

Should work without, the only kind of "subsampling" like behavior might be counting the IO operations to tell when a timestep is over. Luckily, the IOP already is a single CPU running multiple parallel I/O operations in a round-robin fashion.

 

[DaveS]

Quick q: Where is the shuttle-to-MLP attachment point located WRT to the SRBs? I'm trying align the stack with the HDPs on the new MLP and there seems to be some sort of offset. I have verified the position of the HDP attachment point in the MLP code, it is spot on.

 

[GLS]

Quick q: Where is the shuttle-to-MLP attachment point located WRT to the SRBs? I'm trying align the stack with the HDPs on the new MLP and there seems to be some sort of offset. I have verified the position of the HDP attachment point in the MLP code, it is spot on.

Too tired at the moment to dive into that now... I'll look at it in the morning.

---------- Post added at 11:47 AM ---------- Previous post was at 02:08 AM ----------

Quick q: Where is the shuttle-to-MLP attachment point located WRT to the SRBs? I'm trying align the stack with the HDPs on the new MLP and there seems to be some sort of offset. I have verified the position of the HDP attachment point in the MLP code, it is spot on.

Should be this:

const VECTOR3 POS_HDP = _V(0.0, -10.25, -19.6);

Atlantis_defs.h:109

 

[DaveS]

Anyone have any objections to me correcting HDP_POS to actually be at the bottom of the SRB aft skirts where they meet the HDPs on the MLP?

 

[Urwumpe]

Anyone have any objections to me correcting HDP_POS to actually be at the bottom of the SRB aft skirts where they meet the HDPs on the MLP?

No. I would I just say we should make sure its not the "bottom of the SRB aft skirts" but precisely "Z axis coordinate is the interface plane between SRB and MLP"

 

[DaveS]

No. I would I just say we should make sure its not the "bottom of the SRB aft skirts" but precisely "Z axis coordinate is the interface plane between SRB and MLP"

Which is the one and the same: https://www.dropbox.com/s/btmxwkmwtfof6sf/SRB_AftSkirt.jpg?dl=0

The only protrusions are the thermal curtain, nozzle and the HPU exhaust duct.

 

[Urwumpe]

Which is the one and the same: https://www.dropbox.com/s/btmxwkmwtfof6sf/SRB_AftSkirt.jpg?dl=0

The only protrusions are the thermal curtain, nozzle and the HPU exhaust duct.

Yes - but if we are not describing it as explicitly as possible (source code comment should be enough), we might easily break it in the future.

---------- Post added at 23:11 ---------- Previous post was at 19:30 ----------

After digging for hours through the documentation on my HDD, I finally found the answer I was looking for:

A Listen Command over the Shuttle Bus is a command word with a interface unit address of 01000B (8).

(This was hidden in a document explaining how the redundant set synchronization works)

Inside the command data word is a 8 bit index, which is defined as an even number from 0 to 254 (Yes, that actually means 7 bit).

This command is mentioned a lot in the I/O processor flow charts. It operates together with the WIX (wait for index instruction). When a listening BCE is in WIX state and receives a "listen" message, it will take the index of that message for looking into a table (The WIX table) in the FCOS CSECT which contains the addresses of BCE programs that will process the incoming data words.

This mechanism is especially important for the ICC busses and the DK busses.

Yeah... now still to research the question: How often do BCE programs change? If they are mostly constant except large configuration changes and even payload I/O not requiring new BCE programs, it would be better to define the functions in C++ and just configure which programs are available for a mission (For example automatically if a certain hardware component is installed). The FCOS programs for example did not change much since ALT.

Also interesting: There is a self-test BCE (#25) in the AP-101S, which is missing in the AP-101B...

 

[DaveS]

Here's a question: Should we migrate over to dbeachy1's XRSound package given all the problems that OrbiterSound has with Orbiter 2016? For me SSU plays nicely with XRSound even though it isn't tied into it. No CTDs or other weird oddities.

 

[GLS]

Here's a question: Should we migrate over to dbeachy1's XRSound package given all the problems that OrbiterSound has with Orbiter 2016? For me SSU plays nicely with XRSound even though it isn't tied into it. No CTDs or other weird oddities.

For example...

 

[DaveS]

For example...

Could you explain this further? Do you mean with OrbiterSound or with XRSound?