The next beta update will have a format that, I think, combines getting the year included and keeping the format compact (as the old version still in production did)
This is sorta a worst case scenario with the new logic:
When there’s just one midnight it’s pretty clear, and when there are mostly midnights.
Would this make sense? (and only if the development isn’t too much work)
Alternative to the above: On page load, use dark green plots for Active monitors and light green plots for Testing and Candidate monitors. Unless hovering over a specific monitor, which would change the plots to dark/light green plots as it works now.
When hovering over specific monitor, I think the plots of the overall score should not be displayed (or displayed only with more transparent, lighter plots).
I implemented a variation of these suggestions yesterday.
The overall score is more heavily “dimmed” (it was before too, but since many monitors have the same score the aggregate made them not look dimmed).
Hovering over a “status” dims monitors in the other statuses. The dimming effect is more pronounced here as well; the previous settings were better when the dots were bigger and we didn’t have so many monitors (the first version of all this just had the one as you all recall).
For those of you with an account page, I only show the legend of the active/testing monitors to make the page length reasonable (I think the candidate measurements are on the chart, but there are usually not too many of those).
Thanks for all these wonderful changes. I notice the account page often throws timeouts from Chrome as the javascript churns through all the monitors for each graph. If possible, graphing only the active monitors on the account page would speed the rendering quite a bit and avoid the ‘wait’ or ‘close’ prompts.
Oh, that’s surprising! Is it the network calls timing out, or something else? How many charts are on the page you see this on?
I did not see any messages indicating a timeout – it was simply a popup from the browser indicating the page was taking an extraordinary amount of time to finish loading, offering choices to continue waiting for it or to close it.
I have six production NTP servers listed on my account summary page https://www.ntppool.org/a/davehart. I tried to reproduce the issue just now and the page loaded quite quickly.
Oh! That’s not good. I haven’t seen that, but it’s possible my computers are all “too fast” or that when I test I end up reloading the same pages a lot so the CDN often has the chart data cached if that’s what’s slow. Let me know if it’s recurring more often and I can implement something so the charts don’t load until they are needed; or don’t load all at once at least.
As I was having similar issues with my device for day-to-day operations not being the most powerful, I built my own page pulling in static images pre-rendered on my own infrastructure, using the screensnap container. Though that stopped working now. While the URL for the image that the container tries to “snap” renders ok in a browser even with the new optics/layout, the “snapping” itself doesn’t seem to work as before anymore, i.e., doesn’t return an image.
Any plans to adapt the screensnap container to the new system?
I guess the new layout/dimensions, or the brief “loading” canvas being shown before/while the graph loads/is being rendered might confuse the snapper.
I am in a hotel tonight and was able to reproduce the “Page Unresponsive” popups browsing my account page. My requests came from 72.45.51.227.
I switched to the inactive tab about 05:10:07 UTC. It showed just a white background and a number of popups before the page text appeared at least 30 seconds later. The graphs were all visible around 05:14:50. Hovering over individual monitors immediately updated the graph view by 05:17:10.
