Display median ping time

[goeiecool9999]

Calculate the median ping using a public domain algorithm
Usually the median and mean times are close to each other

But as you can see here the mean is heavily skewed by outliers and the median can be more useful.

[cnlohr]

Wow. I really like this. It also points out a sad we have, which is I think we should be using float, not double to reduce the L1 cache footprint, which was never an issue until now, with your algo for computing median.

@dreua how do you feel about this. I am pretty happy with it.

Also, I feel like we're getting very close to a cnping 1.5!

Then after that we might want to go a little more buck-wild, and have the multi-ping tool be a first class citizen.

[cnlohr]

One other thought - we should make the horizontal green lines include median.

[goeiecool9999]

I'm glad you like it. Another idea that occurred to me was to draw a boxplot (possibly behind a keybind and/or on the histogram view) so you can see even more percentiles. But since the quickselect algorithm probably already takes orders of magnitude more time than the current calculations maybe that would be overdoing it?

[cnlohr]

I would be happy for it to be a second toggle that can go "on top" of the graph optionally. Still something I'd want @dreua 's opinion on.

[cnlohr]

I'm gonna give dreua a day or two more. Then, just go for it.

[cnlohr]

One other thought - I wonder if we should do something like only calculate median every few frames?

[dreua]

Hi, I'm sorry I can't say much about this right now. For me personally multiping is the more interesting feature but I absolutely see the point in median calculation, its just not something that I have missed or feel like I would need it in my use cases. Now multiping is waiting far too long for a final review :/ Let's hope I can dedicate some time to this in december...

I'd say just go for it and we can always iterate and improve if something turns out to be a problem.
As the median calculation seems to be a stand alone algorithm, maybe that could go into a separate (header) file instead of blowing up the main cping.c file eve more. (Feel free to skip that if it causes any trouble.)

[cnlohr]

@dreua Whenever you end up having some free time, let's meet for a call so we can really make this the best ping tool.

I agree the multi-ping is higher priority.

Additionally, this change makes me a little nervous, I feel like we should profile it. If it has a real tangible difference in CPU usage, it makes me think maybe we shouldn't.

@goeiecool9999 - give us a few weeks to see if we can drive this forwards.

[goeiecool9999]

I feel like we should profile it.

@cnlohr
On this graph it shows that it's 10% of DrawFrame. That is with the windows stretched across my 1080p monitor. So it calculates the median for ~1920 values. This is also on a Ryzen 3900X. So it has quite large caches. Not sure if that's representative of all targets you have in mind.

Though zooming out a bit you can see there are calls to drawing functions with an incorrect backtrace, even though I added -fno-omit-frame-pointer as instructed here
Seeing as they're probably from DrawFrame the 10% metric is probably incorrect. To contextualize it another way: Perf reports 54 million samples for GetWindMaxPingTime and 247 million samples for GetMedianPing. So GetMedianPing is about 4.5 times slower than that existing function.

[cnlohr]

Comparing to the CNFGFunctions is not a good comparison, since they are waiting a lot. I am more curious about absolute code time taken per frame. I don't see everything in terms of that. I.e. how many us per frame are taken computing median?

[goeiecool9999]

Comparing to the CNFGFunctions is not a good comparison, since they are waiting a lot.

Ah. I didn't know about that.

how many us per frame are taken computing median?

Printf'd the measured duration to a CSV and made a spreadsheet. This includes me resizing to width ~1920 and the list slowly getting bigger as more pings are gathered so I chose a reasonable cutoff point in the data (sample 300). I didn't adjust my frequency scaling settings so I can't guarantee that the code was running at a stable clock frequency. Hopefully this gives some insight though. Seems manageable to me personally.

EDIT: Went back and changed my linux scaling governor to performance and it gave me comparable results. About one microsecond less on average and a little less spread out, which makes sense.