Add an option to display the whole history of times in the graph

[myarcana]

Now passing --buffer 0 will scale the graph's x axis so that the entire history is always visible.

I made this option the new default, because I expect most users want a graphical ping plotter when they're dealing with network connection issues, and want to start figuring out why — this is why I came across gping at least. Keeping the entire history in frame lets you see at a glance whether the issues appear to be periodic or not.

[orf]

I'm off two minds: I think it's useful in some cases, but in others it isn't. After running for a minute this is what I get with your change:

Whereas this is what you get currently:

To me, personally, the second one is much more useful for diagnosing issues, and part of the reason I made it not buffer indefinitely is that large one-off spikes can really make the graph hard to read. I also thought most people would prefer recency over an entire history.

However, we might be able to have it both ways. We could toggle this behaviour on a keypress? i.e pressing the Enter key will start to buffer the history indefinitely, and pressing it again would revert back to a fixed-size buffer? We would do this by keeping a very large fixed buffer but only displaying the most recent portion of it, allowing a you to toggle between "live" and "historic" views?

What do you think? I'd rather go this route than changing the default I think.

[myarcana]

I think those are fair points.

My own personal history of wanting to solve sporadic network latency has always been with wifi, and was because of interference or bufferbloat. At those times, and why I wrote this feature, the periods of high-latency vs low-latency were much wider than a few seconds each, so I hadn't considered that a growing buffer would obscure the information like your example shows. My graphs looked more like square waves. For a first-look at network issues in the future, I would still reach for the growing-window, but I've never used ping plotters for reasons other than "what is wrong with my wifi?"

You're dead right that one-off spikes make the whole graph less useful. Maybe just add an option for setting max (and min?) bounds on the graph's y-axis?

Anyway, the point of my request is not to convince anyone that growing-windows are more useful. I just believe gping should have a growing-window feature, so any way you choose to include it would make me happy :)

With the change I wrote, you can still of course pass --buffer 60 to get the 60-second window you found more useful. I just special-cased --buffer 0 to function as a growing-buffer. Surely more useful than a real 0-second buffer! After merging you could change the default back to whatever you want too of course.

I also do think it would be useful idea to have live configuration in gping in general, however I wouldn't have thought about adding live configuration without you mentioning it; last time I used gping, the only "missing feature" I felt was the growing buffer. But it would surely be neat if you could switch from a currently-growing-window to a sliding-window of the same size for example. The most basic—and most useful—feature in this vein would probably simply be a prompt to adjust many of the graph's options including buffer size.

[huyz]

I came just for this feature. I definitely need both cases, but I would not change the default of showing recent pings, which is useful 90% of the time.

I need this these days so much that I won't be waiting for a merge. I'll get your version @myarcana and run that separately. Thanks for that!

pressing the Enter key will start to buffer the history indefinitely

@orf This is a bit ambiguous to me. Should the history start at the time the Enter key is pressed or when gping was launched? Once again, I think you could make an argument either way. I personally think we should make history go back to the point of launch by default (so that toggling between recent and historical doesn't wipe any history) and we should have another key to signal "clear history" or maybe a "trim history" (which trims everything to the last hour—an arbitrary default that I don't know would be most appropriate to set)

Btw, how long would it take before RAM usage becomes an issue? days, weeks, months? This is where the "clear history" comes in.

[huyz]

In the historical view, what is displayed for each interval (which progressively grows cost time), the max ping time for that interval or the average?

[huyz]

@myarcana I ran it for a few hours and now it's pegged at 100% CPU and it won't let me quit.

[myarcana]

@huyz Great minds think alike!

I don't use this ping plotter anymore though, and unfortunately I have no idea what might be causing it to hang in your case. Probably has something to do with how the plotter renders its data, I guess it doesn't support long PlotData.data very well.