Offset graph Y axis blown out by unsynced response

I noticed the graph for had the offset Y axis blown out by a 765ms offset reported by a monitor after a restart, when ntpd had not yet synced and was properly reporting as much with leap=011 (3). It seems to me that either the monitor should log a zero offset when leap is 3, and/or the graph should ignore such log entries:

1693664726,“2023-09-02 14:25:26”,0.765410161,-4,-12.4847275531701,39,twtpe1-2kg9ezv,3,INIT

1 Like

Not sure how servers populate time-related fields in responses when they are unsynchronized, whether offset derived from them might make some sense in some circumstances so it would be worthwhile recording. But for practical reasons, the graphing system should ignore offset values in these cases on its end, whatever they are:

While the handling of RATE KoDs has been updated a few days back already, zeroing the offset value in log entries corresponding to such KoDs, not all monitors seem to have been updated yet, continuing to report bogus offset values, which in turn blow up the graphs:

1693833286,“2023-09-04 13:14:46”,-1948901762.5947,-3.5,15.4839818951976,20,usewr2-1a6a7hp,3,RATE


Though I understand from a separate thread that changing the JavaScript-based graphing system might be more challenging than changing the monitor implementation…