Closed moeffju closed 3 years ago
I've found a way to add horizontal lines at the expected values with gnuplot .. I don't think the added complexity is currently worth it to expose it as configuration arguments in the script though.
You can edit the plotscript
in the container to add this section right before #plot the results
:
# add horizontal lines for expected values (in mbit/s)
expected_download = 1000
expected_upload = 50
set arrow from graph 0,first expected_download * 1000000 to graph 1, first expected_download * 1000000 nohead lw 2 dt "." lc rgb "navy" back
set arrow from graph 0,first expected_upload * 1000000 to graph 1, first expected_upload * 1000000 nohead lw 2 dt "." lc rgb "orange-red" back
These are just arrows without an arrowhead though, so they don't scale the graph if you're not at least close to the expected values already. It looks somewhat like this:
I'm looking at how to implement client-side rendering as well and it might make sense to render the expected region with a lightly colored solid fill – some deviation from the expected maximum is always to be expected.
Just in case you're still using this project @moeffju, I have implemented this now. The "complexity" wasn't really that bad. There's an if-clause in the plotscript
and the markers can be defined with environment variables MARKER_DOWNLOAD
and MARKER_UPLOAD
in the container.
The following is an example of setting them to 800
and 50
respectively:
To be fair, this only part of the issue. Now that we have a way to define expected values one might think about implementing #6 again and use different scaling for download and upload ..
Great to hear! I am still using this occasionally, but for the past few months I have been using a T-Mobile 5G Hotspot instead of the Vodafone Cable (that I'm still paying for), so the acute pain is lessened. I have also set up another measurement/plotting solution with Grafana, which relatively easily allows for multiple axes and scaling, but it's not easy to make that clear to read. On the flipside, Grafana graphs are live and interactive, so crosshairing over them is pretty nice.
With this change, if e.g. my max down speed is 1 Gbit/s, but all measurements are way below that, will it still plot the line at 1 Gbit/s so that it's visually obvious that the contractual speeds are not nearly reached?
I have also set up another measurement/plotting solution with Grafana, which relatively easily allows for multiple axes and scaling, but it's not easy to make that clear to read. On the flipside, Grafana graphs are live and interactive, so crosshairing over them is pretty nice.
Yeah, that is my main blocker about going ahead with implementing some client-side rendering with e.g. D3.js .. there are nice visualizations tools out there already that do this for you, so why bother implementing it yourself? You're already using docker anyway, so you can just sprinkle some Grafana over it .. but, you'll lose the self-containedness that this script has, as you had mentioned in #6.
I'm still not sure if and where to move on with this project. :shrug:
With this change, if e.g. my max down speed is 1 Gbit/s, but all measurements are way below that, will it still plot the line at 1 Gbit/s so that it's visually obvious that the contractual speeds are not nearly reached?
Uhhh .. I thought so but no, the horizontal lines don't affect the axes' scaling. :grimacing: I'll look into that quickly.
That was a quick one. Commit d232c9f now uses MARKER_DOWNLOAD * 1.5
as the yrange
maximum. If you set the marker to 80% of your contractual bandwidth that works out nicely with some overhead in the plot over your theoretical maximum.
The self-contained nature of this is really invaluable - getting the whole Grafana thing set up was annoying with lots of sharp corners, even when starting from a docker compose set, so IMO that is more important than client-side rendering. But if there's a relatively easy to integrate component of course... ;)
Thanks for all this work btw! Definitely the most pleasant to use of the pingers!
I am using speedtest-plotter to demonstrate to my ISP that they are not even close to delivering the bandwidth I pay for. For a stronger visualization it would be great if: