Eliminating station docking port lag

[Fraktal]

I've heard that a major part of why my space station lags is due to every single exposed docking port polling the distance of every other docking port within physics range on every physics tick. Considering that my station currently has around 7 exposed ports (it's currently in the middle of a refit from junior ports to standard ports), that's about 42 checks per tick.

If I were to plug in the unused ports with a matching-size docking ring and a nosecone, can I expect any noticeable decrease in lag? Or is the average station's part count too high to notice the difference?

[XLjedi]

First I've heard of lag related to exposed docking ports.  But sounds interesting...  I will watch.

[Geonovast]

I've heard about this, and I believe it's why the shielded docking port is a thing.  If you use shielded ports instead of the normal ones, and just open them when you want to dock something to them, it shouldn't be constantly asking if there's something in range on the unused ports.

[AHHans]

9 hours ago, Fraktal said:

If I were to plug in the unused ports with a matching-size docking ring and a nosecone, can I expect any noticeable decrease in lag? Or is the average station's part count too high to notice the difference?

I don't know. Why don't you give it a try and let us know about the results?
(Then I don't have to do it myself.)

[XLjedi]

7 hours ago, Geonovast said:

I've heard about this, and I believe it's why the shielded docking port is a thing.  If you use shielded ports instead of the normal ones, and just open them when you want to dock something to them, it shouldn't be constantly asking if there's something in range on the unused ports.

No shielded ports for the big docking ports though.  This will now influence my latest modular station design in an attempt to minimize this issue.

[Fraktal]

12 hours ago, XLjedi said:

First I've heard of lag related to exposed docking ports.

@Padishar posted this back in 2016:

Quote

No "if" about it, on every physics update every non-acquired docking port searches all the parts within the physics bubble for docking ports until it finds one that is within the activation range.  So the performance impact is at least proportional to the number of docking ports multiplied by the total number of parts in the loaded vessels.  For example, the station in my avatar is 1410 parts of which, 120 are docked ports holding it all together, and 24 are vacant senior ports.  Nearly 9% of the total CPU time is spent in ModuleDockingNode.FixedUpdate (and another 22+% shuffling EC around the Vessel from the 360 solar panels and 42 probe cores).  Eliminating (or greatly reducing) these two parts could increase the framerate by nearly 50%...

Each additional port in physics range increases the number of checks per physics update exponentially.

[XLjedi]

Just now, Fraktal said:

@Padishar posted this back in 2016:

Each additional port in physics range increases the number of checks per physics update exponentially.

Wonder if any of that was negated with time due to station Primary Active Port designation logic being added?

 

[Geonovast]

45 minutes ago, XLjedi said:

Wonder if any of that was negated with time due to station Primary Active Port designation logic being added?

 

I doubt it, since you can still dock to ports that aren't primary.

What would help, though, would be a PAW option to disable ports... essentially doing what the shielded port does, just without a fancy animation.  Maybe put some small indicator lights on the model to that green = active, red = inactive so you don't have to click on the port every time to see if it's enabled.

[AHHans]

O.K. I just did a quick test with a dummy craft with 288 shielded docking ports (out of 295 parts in total). There is indeed serious lag when all those shields are open, compared to when they are closed.

Another test: similar craft but with 288 normal clamp-o-trons covered with a nose cone each (583 parts in total) -> the time display flickers green and yellow, and 10 in-game seconds took 10.32 seconds real time (timed manually on a stopwatch(-app on my phone))
Same craft but without the nose cones (so 295 parts in total) -> the time display is a steady yellow, and 10 in-game seconds took 28.92 seconds real time (Well, a bit less. I got bored. )

So, yes. There definitely is an effect!

Edit:
Another test with a craft with 8 docking ports (uncovered or covered with a nose cone) and enough fuel tanks to bring the total number of parts up to 885 resp. 877 parts showed  no significant difference in the lag between the two craft...

Edited February 23, 2020 by AHHans

[Shadowmage]

Just wanted to pop in and say:

Yes, this is a real thing.  This has been experimented and measured multiple times, by different people and groups.  The finding is always:  More 'open' docking ports = higher CPU usage during their internal updates.

Pretty much exactly as explained by @Padishar in the quote above.  Him, myself, and @riocrokite all spent considerable time trying to find the source of stock 'part-count' induced performance degredation, and the exposed docking ports was one of the worst offenders by a large margin.

 

[linuxgurugamer]

It seems that a way to deactivate a docking port at will might be useful

[Fraktal]

Alright, let's do this by the numbers.

Laptop hardware:

• CPU: Celeron N3450, 1.1 GHz quad-core
• RAM: 12 GB
• VGA: GeForce 920MX

Not very good, I know, but not everyone has the cash for a supercomputer.

KSP is the newest Steam version plus Making History.

Mods installed (omitting some that are not relevant):

• [x] Science!
• 6 Crew Science Lab
• 6 Seat Mk3 Cockpit
• AECS Motion Suppressor
• Alternate Resource Panel
• Antenna Helper
• Attitude Adjuster
• Auto Actions
• Chatterer
• Click Through Blocker
• Correct CoL
• Crew Light
• Distant Object Enhancement
• Dock Rotate
• Docking Port Alignment Indicator
• Editor Extensions
• Engine Lighting
• KAC
• KER
• KISS
• Maneuver Node Evolved
• Modular Flight Integrator
• Quick Revert
• ReCoupler
• Science Relay
• unBlur

The station in question:

Total part count is 214. Three Junior and four regular-sized docking ports are currently unused. Steam overlay says I'm running at 11 FPS.

Stuff I'm using to plug the open ports:

Cheating it up to the station, I'm getting 14 FPS at the start of the approach, drops to 13 FPS within 20 meters.

Once all ports are plugged in and the stack separators cleaned up in the Tracking Station, I'm still getting 11 FPS with occasional spikes to 12 FPS. So the conclusion seems to be that unless you have an absurd number of docking ports, the difference in performance is negligible. In fact, I seem to lose more FPS from the station's self-shadow than from the docking ports being open.

 

[AHHans]

19 minutes ago, Fraktal said:

So the conclusion seems to be that unless you have an absurd number of docking ports, the difference in performance is negligible.

That's also the impression that I have from my tests. Yes, there is an effect. But if you only have a reasonable number of docking ports then this effect isn't so serious.

And from a programmers point of view: I can well imagine that in an older version of the game each docking port tested every part within physics range, but that at some point a dedicated list of docking ports was introduced so that now only that list needs to be searched.

[XLjedi]

55 minutes ago, AHHans said:

That's also the impression that I have from my tests. Yes, there is an effect. But if you only have a reasonable number of docking ports then this effect isn't so serious.

And from a programmers point of view: I can well imagine that in an older version of the game each docking port tested every part within physics range, but that at some point a dedicated list of docking ports was introduced so that now only that list needs to be searched.

I guess depends on what point the number becomes absurd?  In the design of my OASys Station I plan to have at least 19 large open ports.  I have fewer of the mid-size ports and guess I can convert all those (except for a couple of the really small ones) to the closeable variety.

Edited February 23, 2020 by XLjedi

[AHHans]

19 minutes ago, XLjedi said:

I guess depends on what point the number becomes absurd?  In the design of my OASys Station I plan to have at least 19 large open ports. 

Well, my guess is that with 19 open ports (and a few hundred parts in total) you can measure a difference between having the ports open or not. If you actually notice the difference in normal gameplay is another question. Although now that I re-read your message, 19 senior-sized ports plus a comparable number of normal and junior-sized ports is at least at the edge of what I consider "reasonable". The biggest station that I built has 8 normal docking ports, 4 junior-sized ports, and 5 senior-sized ports open and 13 more senior-sized ports that are attached to something. (And it is already pretty laggy, but it is also the biggest - in size, weight, and part count - object I built.)

As you can see from my test, 288 open docking ports is clearly on the absurd side of the scale.

[XLjedi]

1 minute ago, AHHans said:

Well, my guess is that with 19 open ports (and a few hundred parts in total) you can measure a difference between having the ports open or not. If you actually notice the difference in normal gameplay is another question. Although now that I re-read your message, 19 senior-sized ports plus a comparable number of normal and junior-sized ports is at least at the edge of what I consider "reasonable". The biggest station that I built has 8 normal docking ports, 4 junior-sized ports, and 5 senior-sized ports open and 13 more senior-sized ports that are attached to something. (And it is already pretty laggy, but it is also the biggest - in size, weight, and part count - object I built.)

As you can see from my test, 288 open docking ports is clearly on the absurd side of the scale.

I optimized it a bit, I'm now at:

17 large open ports  (it's my primary storage and transfer hub)

All of the mid-size ports have been capped using the shielded part instead.

6 of the small ports.  

So, I'm at 23 open ports right now before bringing in a large craft or two with additional open ports.

I guess as supplies are offloaded some of the ports could be capped if the supplies are designed to be terminating instead of stackable.

Oh and it's like 395 parts with a TON of senior ports that are capped in the process of constructing.  I'm planning 20 missions to get it fully operational.

 

Edited February 23, 2020 by XLjedi

[AHHans]

1 hour ago, XLjedi said:

I guess depends on what point the number becomes absurd?

Coming back to that: I just did a test with using the BG robotics parts to cover the senior-sized docking ports. My test vehicle looks like that (with the ports closed):

As you can see it has groups of five rings of docking ports, each ring has four pairs of docking ports where one is the actual port and the other is the movable "cover" of the port. The craft in the image has three such groups, so 3*5*4*2 = 120 open ports when all of the pairs are in the "open" position. And this is the lowest number of groups where I start to see yellow times, although sometimes they flicker green and there is no significant lag. With four groups (i.e. 4*5*4*2 = 160 ports in total) I see measurable lag when they are open (10 s game time in 15 s real time). If I move all of the "covers" to the closed position the lag (and the yellow times) go away.

So for my machine about 100 open docking ports seems to be the boundary for "absurd" (Btw.: Ryzen 5 1500X, 16 GB RAM, Ubuntu 18.04)

P.S. Due to bug #24435 action groups to open all these doors don't work. (But I guess you - @XLjedi - know that.)

[Fraktal]

2 hours ago, AHHans said:

That's also the impression that I have from my tests. Yes, there is an effect. But if you only have a reasonable number of docking ports then this effect isn't so serious.

And from a programmers point of view: I can well imagine that in an older version of the game each docking port tested every part within physics range, but that at some point a dedicated list of docking ports was introduced so that now only that list needs to be searched.

I agree that it's more efficient to just cache all docking ports in physics range and work from that, checking if they're still in physics range every... say... 20-30 physics updates and removing them from the cache if not. That would result in minor, periodic lag spikes rather than constant lag. I mean, how many hundreds of physics updates go by while you maneuver into docking position anyway? We've got plenty of room to work with before edge cases become an issue.

However, if I were to write the relevant code, I'd also make it so that the cache also includes which docking port is on which vessel and have docking ports not distance-check other ports on the same vessel by default, unless explicitly set otherwise via a tweakable.

[XLjedi]

@AHHans  Thanks for the thorough testing!  

Makes me feel better now; I think my station is safe.

I do wish they would fix that action group bug!  It would make my custom doors/ramps work so much nicer.

[peteletroll]

Free docking Port induced lag could be reduced by not checking for neighbors on every frame, but just, for instance, five times per second: it should be enough for reasonable docking speed. I'm afraid only Squad can change this...

[Incarnation of Chaos]

19 minutes ago, peteletroll said:

Free docking Port induced lag could be reduced by not checking for neighbors on every frame, but just, for instance, five times per second: it should be enough for reasonable docking speed. I'm afraid only Squad can change this...

Personally i'd like for there to be a mechanic where you send a signal to "Activate" the port that's in LOS to your ship, and only enable it when within 1.5km or less. Since even if you have multiple docking ports on a station; you wouldn't be docking to them all at once; then once docked we could check for another port attached constantly for a couple minutes. Then if after ~5 minutes that vessel is still attached; just assume both ports are staying as one unit until the player hits a button to sever the connection. Kinda a Pseudo-welding mechanic.

Because that's the worst part of the overhead; even docked ports constantly check to see if there's another one docked to it. So even after you dock components; they're running thru a loop endlessly sucking down CPU cycles for no good reasons.

[Fraktal]

7 hours ago, peteletroll said:

Free docking Port induced lag could be reduced by not checking for neighbors on every frame, but just, for instance, five times per second: it should be enough for reasonable docking speed. I'm afraid only Squad can change this...

My point exactly, as I wrote it above. Approaching a docking port is a slow enough process to allow significant timing leeway for the checks before we start hitting edge cases where the ports are close enough to magnetize but neither realized it yet.

[fourfa]

How about any port only becomes active and scanning when it's been "set as target" by another craft?  For me, this would make the entire disable/enable process completely invisible and require no behavior change, nor yet another PAW line

[evileye.x]

There's mod for disabling magnet I beleive

[StrandedonEarth]

17 hours ago, fourfa said:

How about any port only becomes active and scanning when it's been "set as target" by another craft?  For me, this would make the entire disable/enable process completely invisible and require no behavior change, nor yet another PAW line

In conjunction with 'control from here'?