Issue Type: Performance
Impact: Low
Frequency: Constantly
Date First Experienced:
Date Last Experienced: 2021-04-06 21:04:00 (+02:00)
Reproduction Steps:
This affects mostly users with poor network connections, I used an external program to induce packetloss in a controlled manner, pinged the server from the client at ~60 HZ and measured the time it took for the ping request to reach the server and for the server to answer back.
The results for each ping are then printed out.
My findings can be reproduced in a place I created to test this behavior which can be found here:
The P-key can be used to temporarily stop pinging the server and the F9 key can be used to view the output.
The generated output should be read as such:
LatencyUp is the estimated amount of time in miliseconds it took for the ping to arrive at the server
LatencyDown is the estimated amount of time in miliseconds it took the server to process the pingrequest and answer back to the client
Both LatencyUp and LatencyDown use a synchronized clock to estimate the time it took for the ping to travel and shouldn’t be off by more than a couple of ms.
RTT is the recorded round trip time, i.e the total amount of time it took for the client to recieve an answer.
FrameCSent is the client frame number at which the ping was sent out. Since we are pinging the server once per frame this number will increase by 1 for every single ping.
FrameS is the server frame number at which the ping was processed by the server, please note that the frame counter on the client and the server are not synced up and should not be directly compared.
If 2 pings have the same frame number this means that they were processed in the same frame.
FrameC is the client frame number at which the answer from the server was processed by the client.
With a good connection this is what the generated output roughly looks like:
Expected Behavior:
When packetloss occurs I expect the size of the resulting pingspike to be more or less the same regardless of which direction this packetloss occurs in.
Actual Behavior:
First off I used my network emulator to simulate outgoing packetloss, i.e packets being droped when traveling from the client to the server.
With a low latency connection (average ping of ~66ms) this results in a small but measureable pingspike as roblox apparently forces all data sent between the server/client through a single ordered reliable channel (which is bad, please let us send data through an unrelaible and/or unordered channel to avoid these pingspikes altogether but i digress)
I marked the moment a pingspike as a result of packetloss occured.
The resulting pingspike is quite small with only 75ms which makes perfect sense considering my average ping of only 66ms.
Now I simulated inbound packetloss to drop packets sent from the server to the client instead.
The resulting pingspike is much worse as you can see:
The server I tested this on was the same an I played with the same 66ms average ping.
This results in consistent pingspikes of over 500ms.
Yikes.
Considering the resulting pingspikes are only this bad when packets sent by the server to the client get droped but not the other way around this looks like unintentional behavior to me and the reason why I consider this to be a bug.
As far as I can tell every single game on roblox is affected by this issue as during such a pingspike all (even unrelated) network traffic is temporarily halted until the missing packet gets resent by the server which is pretty bad for games that rely on time sensitive information being sent between the server/client like FPS-games.
Workaround: