Show variance for average values in server termbox metrics

Question

Show variance for average values in server termbox metrics

sourencho opened this issue 4 years ago · comments

I was just testing my client against the remote server and although I had an "average drift" of 3 (gameplay should be smooth at this number), i was experiencing a lot of snapback.
You can kind of see it in this gif:

I think this is because even though on average the metric was doing well, it had a lot of variance.
I pinged the server and saw a lot of variance:


64 bytes from 45.79.106.21: icmp_seq=45 ttl=54 time=9.170 ms
64 bytes from 45.79.106.21: icmp_seq=46 ttl=54 time=8.339 ms
64 bytes from 45.79.106.21: icmp_seq=47 ttl=54 time=55.735 ms
64 bytes from 45.79.106.21: icmp_seq=48 ttl=54 time=130.032 ms
64 bytes from 45.79.106.21: icmp_seq=49 ttl=54 time=8.619 ms
64 bytes from 45.79.106.21: icmp_seq=50 ttl=54 time=39.570 ms
64 bytes from 45.79.106.21: icmp_seq=51 ttl=54 time=7.623 ms
64 bytes from 45.79.106.21: icmp_seq=52 ttl=54 time=9.156 ms
64 bytes from 45.79.106.21: icmp_seq=53 ttl=54 time=9.065 ms
64 bytes from 45.79.106.21: icmp_seq=54 ttl=54 time=9.991 ms
64 bytes from 45.79.106.21: icmp_seq=55 ttl=54 time=26.506 ms
^C
--- 45.79.106.21 ping statistics ---
56 packets transmitted, 56 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.623/40.768/211.696/54.035 ms

Copacetic · Answer 1 · Mon Apr 27 2020 23:49:05 GMT+0800 (China Standard Time)

I wonder if variance is exactly what we want maybe "bad packets" is more useful, like a count of packets with a high cmd drift

…

On Sun, Apr 26, 2020, 11:36 PM Souren Papazian ***@***.***> wrote: I was just testing my client against the remote server and although I had an "average tick delta" of 3, i was experiencing a lot of snapback. You can kind of see it in this gif: [image: Uploading ungroup_snapback.gif…] I think this is because even though on average the metric was doing well, it had a lot of variance. I pinged the server and saw a lot of variance: 64 bytes from 45.79.106.21: icmp_seq=45 ttl=54 time=9.170 ms 64 bytes from 45.79.106.21: icmp_seq=46 ttl=54 time=8.339 ms 64 bytes from 45.79.106.21: icmp_seq=47 ttl=54 time=55.735 ms 64 bytes from 45.79.106.21: icmp_seq=48 ttl=54 time=130.032 ms 64 bytes from 45.79.106.21: icmp_seq=49 ttl=54 time=8.619 ms 64 bytes from 45.79.106.21: icmp_seq=50 ttl=54 time=39.570 ms 64 bytes from 45.79.106.21: icmp_seq=51 ttl=54 time=7.623 ms 64 bytes from 45.79.106.21: icmp_seq=52 ttl=54 time=9.156 ms 64 bytes from 45.79.106.21: icmp_seq=53 ttl=54 time=9.065 ms 64 bytes from 45.79.106.21: icmp_seq=54 ttl=54 time=9.991 ms 64 bytes from 45.79.106.21: icmp_seq=55 ttl=54 time=26.506 ms ^C --- 45.79.106.21 ping statistics --- 56 packets transmitted, 56 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.623/40.768/211.696/54.035 ms — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#196>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIBOZZI72ATDO7JJFSFVYTROURXTANCNFSM4MRUJZFQ> .

Souren · Answer 2 · Tue Apr 28 2020 06:03:34 GMT+0800 (China Standard Time)

How about both?
We can have a "warnings" panel that's spitting out warnings like server SPS < 20 or Client 3 Average Drift hit > 7 (20) while still showing the data in another panel.

This way it's still transparent what the warnings are based on and you don't need to rely on just the warnings' interpretation of the data

Souren · Answer 3 · Tue Apr 28 2020 06:05:41 GMT+0800 (China Standard Time)

We could have a warning section per client and one for the server so one spammy client doesn't prevent us from seeing other warnings

Copacetic · Answer 4 · Tue Apr 28 2020 08:30:51 GMT+0800 (China Standard Time)

gotta consider terminal screen real estate. soon might need to add a way of going into different terminal "views"! like give me more data on a specific client :) both works for me, could all be part of the players table with a count of discarded due to drift updates in the last 10 seconds or something like that. I've been thinking about your point about out of order packets or packets which are actually ahead of the server , might be worth tracking how often this happens in the long run or handling it more robustly. for now though I think we can feel quite confident in the performance of the server at least and should focus on client quality improvements mostly

…

On Mon, Apr 27, 2020, 3:05 PM Souren Papazian ***@***.***> wrote: We could have a warning section per client and one for the server so one problematic client doesn't spam — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#196 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIBOZYTBDHJ5ZHSWTN4HT3ROX6UFANCNFSM4MRUJZFQ> .