NRPE NTP check differs from system ntpq

[gregg_hughes_ISC]

Good afternoon, all!

I'm implementing NRPE on some of our servers and have run across some discrepancies in the check_ntp_time command results.

For instance, the results reported by check_ntp_time show this: NTP OK: Offset 3.049673978e-06 secs. However, ntpq run at the same time on the same server shows this:
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp.exampl 144.92.20.100 2 u 702 1024 377 0.885 -0.417 0.115

I'm trying to build realistic warning and critical levels into the checks, but with discrepancies like this, it's kind of hard to say what's correct.

If anyone has insight into this discrepancy, I'd be very grateful.

Thanks to all for looking!

Gregg

[jdalrymple]

For instance, the results reported by check_ntp_time show this: NTP OK: Offset 3.049673978e-06 secs. However, ntpq run at the same time on the same server shows this:
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp.exampl 144.92.20.100 2 u 702 1024 377 0.885 -0.417 0.115

Code: Select all

[jdalrymple@localhost ~]$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+cheezum.mattnor 24.56.178.140    2 u  725 1024  377   38.513   -0.606   2.201
*clock.team-cymr 204.123.2.72     2 u  439 1024  377   21.327   -2.917   2.602
 50.7.72.4       130.173.91.58    2 u  66d 1024    0   57.451   -1.531   0.000
+mirror          173.230.149.23   3 u  598 1024  377   18.704    2.079   1.643

I'm seeing 2.311 ms of difference between 2 stratum 2 servers. You are experiencing .417 ms of difference between the check results and ntpq - no doubt run at different times. Is that truly an intolerable amount of error on your end? If so I have to wonder what business it is you're in

[gregg_hughes_ISC]

Hello, j jdalrymple!

If I'm reading this correctly, I'm experiencing a 3 and a whisker millisecond offset with my NTP server. That's well within tolerance for the database writes we're doing. Management will probably want to know how Nagios arrives at this delay.

Thanks!

g

[jdalrymple]

Note that ntpq measures offset in milliseconds, not seconds.

-0.417 - .000003 = -0.417 milliseconds. This is 417 microseconds of difference, or is my math haywire?

I guess the thing I'm saying is that from one verifiable time source to another I'm seeing much greater skew than you are from one ntp check to another. I would suggest that if that level of error is pretty typical, especially if any of the systems (the server monitored, the Nagios server or the NTP server) are virtualized. Even with hardware systems I wouldn't be stunned to see that much skew. Also if you have strict needs for very strong and reliable synchronization I suggest at a minimum 2 stratum 1 sources on your LOCAL area network.