Huge Networking delays introduced in 4.16

Development Programming & Scripting Multiplayer & Networking
, , ,
1

I can confirm I’ve had this issue too. It seems to be to do with 4.16 changes to “UseAdaptiveNetUpdateFrequency”. It is now default on in 4.16 (whereas was default off before then). So you can override it in your DefaultEngine.ini to…

[SystemSettings]
net.UseAdaptiveNetUpdateFrequency = 0

However that’s perhaps a using a sledgehammer to crack a nut.

2

Hello,

Thanks for the projects, Altrue. I’ve reproduced the issue and have logged a bug report, which you can track using the link below:

Have a great day

3

Hi,

After upgrading to 4.16, I noticed huge spikes in network latency when calling NetMulticast RPC functions and using OnRep_ properties / functions in C++.

I have made a test project in 4.15.3 that I then ported over in 4.16.1 to help you see the issue for yourself, this is a rather serious regression.

Link to download the 4.15.3 (bug free) project : https://eve-guides.fr/NetworkLagTest415.zip

Link to download the 4.16.1 project (with the regression) : https://eve-guides.fr/NetworkLagTest416.zip

In those demo projects, pressing TAB will set a variable to TRUE, which will then be replicated to the server using OnRep_. Releasing TAB will set the same variable to FALSE. All four actions (sending boolean false & true, receiving boolean false & true) are logged in the console.

By going into the Engines Preferences, it is possible to enable timestamps on the console input to see the delay between sending a boolean and receiving a boolean.

What happens is (and it is visible with the naked eye as well) that in 4.15.3 the delay between setting a variable and having that variable replicated is maybe 2 to 3 ticks.
But in 4.16, that delay will vary from about 6 to 40 (!) ticks.

Just start both projects, hit play with 1 player AND dedicated server, hit then release TAB 20 times at random intervals, in each project, and see for yourself.

4

Hey aitechtor,

We are not aware of any workarounds at this time.

5

Is some workaround exist to fix this?

6

Not worked for me. Are you sure you provide right notation and ini file?

7

Yo dawg…

8

I can confirm [SystemSettings] net.UseAdaptiveNetUpdateFrequency = 0 solves the problem for me. However I dont know if this is OK to keep this way.

9

Same here (solution and if it’s okay to keep it this way), but it’s going to have to make do for the moment…

I honestly can’t believe that this game-breaking issue for multiplayer has been backlogged tbh.

10

You can call ForceNetUpdate() or SetNetUpdateTime() to force an actor’s properties (or queued unreliable multicast rpcs) to send on the next server net tick.

11

Can confirm this did help. It’s okay to keep it, but once it’s fixed i’d turn it back on.
or possibly use 's solution down below. Although I have not tried it.

If enabled, update frequency is
allowed to ramp down to
MinNetUpdateFrequency for an actor
when no replicated properties have
changed.

at-least it’s fixed and slated for 4.19 so if you used this probably change it back when or if you update to 4.19

12

Do you know what this TODO is referring to and how the limitations of it it would show up in practice?

void UNetDriver::CancelAdaptiveReplication(FNetworkObjectInfo& InNetworkActor)
{
    if (IsAdaptiveNetUpdateFrequencyEnabled())
    {
        if (AActor* Actor = InNetworkActor.Actor)
        {
            if (UWorld* ActorWorld = Actor->GetWorld())
            {
                const float ExpectedNetDelay = (1.0f / Actor->NetUpdateFrequency);
                Actor->SetNetUpdateTime( ActorWorld->GetTimeSeconds() + FMath::FRandRange( 0.5f, 1.0f ) * ExpectedNetDelay );
                InNetworkActor.OptimalNetUpdateDelta = ExpectedNetDelay;
                // TODO: we really need a way to cancel the throttling completely. OptimalNetUpdateDelta is going to be recalculated based on LastNetReplicateTime.
            }
        }
    }
}

Also, does CancelAdaptiveReplication, ForceNetUpdate, SetNetUpdateTime, etc. work for overriding the adaptive frequency in demo recording? (demo.UseAdaptiveReplayUpdateFrequency), or only for the main network driver?