Skip to content

Conversation

@daerSeebaer
Copy link

Why was this changed

The scoring system currently has four "ranges" depending on the time offset between the monitored server and the monitor:

  • <75ms : The server is considered "good" and receives one point in the scoring, improving its reputation
  • 75 - 250ms: The server is still considered as viable, but not as good. In this range, a sliding scale is applied, granting a lesser score for a higher offset. At 250ms offset, 0 points are granted.
  • >250ms: The same sliding scale is still applied, but returns negative values, resulting in a loss of reputation for the server. The higher the offset, the higher the loss. At 750ms, the scale reaches -2 points.
  • >750ms: The monitor returns -2 points
  • >3000ms: The monitor returns -4 points. Additionally, the server reputation is capped at -20 points, removing it from the pool immediately if it had been above 10 points before.

grafik

The colouring scheme in the graphs of the management sites had three "ranges":

  • <50ms : Green
  • 50 - 100ms : Orange
  • >100ms : Red

My suggestion is to unify both systems. This increases transparency for pool operators and users. The graph already is the direct feedback what the monitoring system thinks about the server in terms of current reputation. Adding in the colouring scheme adds the layer of how the reputation is currently changing.

To keep the current traffic light scheme with red-yellow-green, I've decided to map everything in the negative point range to "red" since this indicates that the server will lose points and drop out of the NTP Pool eventually. The yellow range is adjusted to the slow gain range where the server is generally considered viable, but gets a penalty for inaccuracy. Indicating this with yellow should also give the server operator the feedback that the accuracy of the server should be improved. The range where the server gets the full score is indicated in green.

What was changed

I simply edited the threshold that determine the colors.

Impact

Expected advantages have been outlined above.
Since this is a purely visual change, I do not expect any negative side effects.

I look forward to constructive feedback and reviews.

@daerSeebaer daerSeebaer changed the title graphs: Make coloring consistent with scoring Make server page graph coloring consistent with scoring Dec 29, 2024
@abh
Copy link
Owner

abh commented Dec 30, 2024

This is great. Thank you for working on this. I agree the graphs should align best as possible with the scoring algorithm.

It might also be an opportunity to tighten the requirements for how accurate the servers are expected to be.

In your "how many points are awarded?" chart did you take into account that the scoring system subtracts 5% of your score on each calculation? (So if we base the colors on "if the score is 11 right on the edge of being active" that'd be a baseline of -0.55).

Another option would be to change the colors to just reflect if the score went up or down (or stayed flat; if so probably special casing that a perfect score close to 20 is "flat").

@daerSeebaer
Copy link
Author

daerSeebaer commented Dec 31, 2024

Thanks for your input.

In your "how many points are awarded?" chart did you take into account that the scoring system subtracts 5% of your score on each calculation? (So if we base the colours on "if the score is 11 right on the edge of being active" that'd be a baseline of -0.55).

No, i did not. Thanks for making me aware of that. In the current model, this changes the maximum offset to stay in the pool down to 125ms ( 10 points * 0.95 = 9.5 points, at 125ms offset 0.5 points are gained back).

Another option would be to change the colours to just reflect if the score went up or down (or stayed flat; if so probably special casing that a perfect score close to 20 is "flat").

I agree that that is an interesting piece of information, however I would encode it into the points-graph rather than into the offset graph. The score can go down for reasons beyond the offset (for example if a server sends a correct time but with an "INIT" KoD-header).

It might also be an opportunity to tighten the requirements for how accurate the servers are expected to be.

I agree, 125ms seems rather high to me. I'll ask for input to this in the forum.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR updates the server page graph coloring thresholds to align them with the scoring system. The key changes include modifying the green threshold from 50ms to 75ms and the orange threshold from 100ms to 250ms, ensuring that colors now correspond better to the scoring ranges.

Comments suppressed due to low confidence (2)

docs/shared/static/js/graphs.server.js:188

  • Consider adding an inline comment explaining why the threshold 0.075 is used for the green color, linking it to the scoring system requirements.
if (offset < 0.075) {

docs/shared/static/js/graphs.server.js:191

  • Include a comment to clarify that the threshold 0.250 corresponds to the upper bound for the orange color given the updated scoring ranges.
else if (offset < 0.250) {

@abh abh force-pushed the main branch 3 times, most recently from b215a04 to 1ab7f20 Compare July 25, 2025 03:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants