Conversation
|
Having the @ 120hz then having the % arrival for 60hz is a bit odd imo, maybe swap them for 80%|100% ? |
|
The @ Xhz changes too, if your game is running at 90fps, it'll say |
|
I think it being swapped makes more sense, or maybe just different formatting for this info. |
|
tbh I might be on edge about having the 60hz tag at all, surely just the % for 120hz is fine. We know that 50% == 60hz, 2 numbers might just confuse ppl |
|
The 120 percentage shows 0% when running at 60hz though (0% percent of ticks arrive within 1/120 of a second) |
|
I am also slightly confused about how to read this or what the takeaway is. You are running the game at 144 fps to demonstrate what it looks like when RLBot runs poorly. But it is not clear that RLBot runs poorly because the game is at 144 fps. I mean, that's what you are trying to communicate, right? Why are we interested in 60 Hz? Is that for low-end users? I am also surprised that with 5% of packages arriving after 13.9ms (around 60 Hz), you still get 120 Hz on average. Your violin plot doesn't show any arriving earlier than 8ms (120 Hz), so I'd expect something inbetween. |
|
Yeah 60hz percentage would be for low-end users, and it also makes the much more strict 120hz percentage next to it look less bad ig. Not sure how we could tell users that it is their 144fps cap that is causing the 80% value without a sentence explaining that. The p95 is this high because the p05 is ~0ms. I think the violin plot didn't catch it because core skips sending those ticks maybe? |
|
Maybe the old packet-arrival-rate is better than the packet-arrival-in-time-for-60 Hz metric since it gives a more intuitive number for how far away from 120 Hz it is. I would display it in parentheses, e.g. |
|
The average hz value already shows you that information, but I agree that it could be more intuitive your way 🤔 |
For low fps, yes, but your 144 fps example has an average of 120 Hz, so here the value is not useful. Maybe we can estimate the user's fps using the number of same-frame packets. If the number of duplicates divided by 120 isn't approximately an integer, then the game is likely not at N*120 fps. |
|
The hz value conveys the exact same information as the old packet-arrival-rate, its just multiplied by 120. While it is definitely possible to estimate the users fps, I think the current 120hz arrival-in-time-rate is a better metric than a boolean that checks if the game is running at N*120 fps. The N*120fps bool would just be |
|
The 2 percentages still might confuse people. Maybe |
|
My only concern with that is how sensitive the 120hz arrival-in-time-rate is, as I can see it being confusing to see a 0% when you're running 60fps. I am fine with a single percentage though if you don't like the double ones. |
|
Another idea:
|
|
This is a good idea. Maybe just "OK" under-emphasizes things but that's a minor nit-pick. We can go with "OK" if nothing else comes to mind. |
3 participants
The perfmonitor now shows more info. It shows actual "packet-arrival-in-time"-rate instead of the old packet-arrival-rate. It also shows p95 and p99 values for packet arrival deltas. It looks like this when running the game at 144hz.
First percentage is ticks that arrived in time for a 60hz arrival rate, second one is ticks that arrived in time for a 120hz arrival rate. Running the game at a stable 120hz yields a 100% on both, 60hz yields
100%|0%and 30hz yields0%|0%. This enables you to show if RLBot is actually delivering a stable packet stream to bots. Also see related violin plot of packet arrival rate at 144hz.