Mtasa-blue: triggerLatentServerEvent doesn't work sometimes with bandwidth over 16384 bytes

[StrixG]

Describe the bug
triggerLatentServerEvent doesn't work sometimes with bandwidth over 16384 bytes.
I think it is related to VS2019 update (https://github.com/multitheftauto/mtasa-blue/commit/b908aa8684b305a5c2fe564e6211c458022eb23d).

To reproduce

1. Download latent_event_test.zip and start it.
2. Connect to the server and enter testevent 16384 3000 in the console. The event will reach the server.
3. Enter testevent 16385 3000. Notice the bandwidth is just 1 byte higher.
4. The event will not reach the server and it will block all subsequent latent events.

Expected behaviour
Latent events should work normally at any speed.

Version
Client: Multi Theft Auto v1.5.7-release-20339
Server: MTA:SA Server v1.5.7-release-20320
and
Client: Multi Theft Auto v1.5.7-release-20340
Server: MTA:SA Server v1.5.7-release-20339

[ccw808]

I can't reproduce this with client & server 1.5.7-release-20339
(Server was Windows 32 bit)

Is the server you tested with Windows or Linux, 32 or 64 bit?

[StrixG]

Local Windows 10 64 bit and hosted Linux 32 bit.
Can't reproduce this on 20324 client.
20324:
https://youtu.be/xcWB4FLZV2o
20339:
https://youtu.be/6ogCeJa-ibo

[StrixG]

Eventually, the data reaches the server. But it takes 42 minutes.

On 20324 it takes less than 5 seconds.

[ccw808]

Thanks for the videos. Unfortunately, I can't reproduce here, so the bug is intermittent or depends something else.

What is the FPS of the client when you are running the tests?

[StrixG]

75 FPS in both cases.

[ccw808]

Please test and show me the video using this modified version of your resource latent_event_test2.zip

[StrixG]

20324:
https://youtu.be/lFkBcwthnBg
20340:
https://youtu.be/N2vfVuG2mBc

23 minutes later:

[dmi7ry]

Actually, once I saw similar behaviour with triggerServerEvent for unknown reason (before it, it worked fine for months). Client tried send some data on server (not much, just some short strings as json), but server didn't receive it and then any triggerServerEvent didn't work until reconnect. (In my case it was solved using triggerLatentEvent)

[StrixG]

I can't reproduce this bug when I build MTA with the latest changes on my computer. I can reproduce it only on nightly builds from 20325.

[ccw808]

@StrixG zip up the client MTA folder and upload to https://upload.mtasa.com/

[StrixG]

https://upload.mtasa.com/u/537553469/MTA.zip_

[ccw808]

Still can't repro here.

What happens if you try 16385 first?
What happens if you try 16384 two times?
What CPU have you got?

[StrixG]

I have Intel Core i5-3570
Results: https://youtu.be/uS6VOXGjgdE
Also reproducible on another computer with the same processor.

[ccw808]

Please try latest build 20342

[StrixG]

The problem is partly gone. Now it's not that slow. But it's still somewhat slower than in 20324 build.
20324: https://youtu.be/kRiMQrT11Cs
20342: https://youtu.be/ZXnrPTWozt0

[ccw808]

Use the command shownetstat and make a video whilst holding the CTRL key

[StrixG]

20324: https://youtu.be/AG6ac61wZ1Q
20342: https://youtu.be/zk-veJy1fAY

[ccw808]

Have you got any other resources running?

[StrixG]

admin, ajax, runcode. These resources affect nothing, just checked it.
Without these resources: https://youtu.be/VfYVMUv1I5Y

[ccw808]

The Packets recv/sent stats are increasing at a much faster rate than expected.
I wonder what is causing that

[ccw808]

Start performancebrowser and using a web browser check:
Performance stats->server->Packet usage

[StrixG]

[ccw808]

In mtaserver.conf, what is bandwidth_reduction and the xxx_sync_intervals set to?

[StrixG]

Packet usage is less active with default values.

[ccw808]

Yay, I can reproduce the problem now

[ccw808]

Fixed in r20343