LOL, you are the first on the display topic.
The biggest problem we have is not getting enough input, feedback, on the things we build. In email, members tell us they love this, that but we need more input like this so that we can know what to focus our energies on.
I'm sure you've noticed that we've been extremely busy upgrading, making changes, trying to simplify the entire service and there is a huge improvement coming in the next few days.
Also, the new look of this site, version 1, and we can see some things already need attention but it's much better than it was. Definitely need to make that side bar width smaller so we have more message space :).
I'll update the Local status board to include displays. We didn't want to have a new section for that because we don't know how many will ask questions about it. I'll move your topic there.
In terms of your input...
That makes sense, and I agree. A connection can technically be “up” but still be poor for real use if there is packet loss, jitter, or speed degradation.
This is documented in many posts and articles we've put on our blog.
We have experimented with packet loss and jitter before, and the challenge is that those measurements are only reliable when testing against a known target. We don't own the switches that packets travel on so cannot know if packets are being lost of being rate limited.
Also, random internet targets can block, rate-limit, or deprioritize probes, which can make the results misleading. So the best approach we had was to test against ISP Tracker-controlled test points.
We do like the idea of adding a simple quality scores, possibly including MOS-style or VoIP/video readiness indicators. Something color-coded like Good / Degraded / Poor would make it much easier to see at a glance whether the connection is healthy, not just online. In fact, if you look at the new display, it starts touching on these things. The display has it's own built in basic monitoring while the agent is doing the major work and reporting its findings back to the display, as if it was your dashboard summaries.
The problem is always the same. We can build things that run against our own resources but we cannot control anything in between so your agent would only know a some, not truly verifiable things.
Definitely on our radar and appreciate you suggesting it.
One small issue is that until everyone upgrade to the 2.1.4x version, it's difficult to put out new versions because the old method meant manually having to update while the new agents auto update themselves. For Linux users, so long as they use the new install script, they too get auto updates.
Hope this helps.
