[SOLVED] Large offset and jitter in ntpq on rhel 6.5

james000 · 09-01-2020, 07:29 PM

Hello,
I have RHEL 6.5 VM. There are two time servers configured on this. Both time-servers are also not real master, but they have further 4 GPS clocks, which are real time servers.
I got an alert from monitoring team that there was a difference of 5 seconds detected on this REHL VM. When I logged in, time was already good, it may have been synched by that time. But I am trying to understand, what would have caused it. ntpq output shows very large offset, I am not sure what would it mean. Can somebody suggest on this, if I need to check something else? I see no information for ntp or drift in /var/log/messages
Both servers are at same location

Code:

root@rhel-client33 $> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp-serv-1-prod. 192.168.70.16    2 u  663 1024  377    0.573   22.821  22.260
*ntp-serv-2-prod. 192.168.70.17    2 u  458 1024  377    0.787    3.341   2.186
 LOCAL(0)        .LOCL.          10 l 496d   64    0    0.000    0.000   0.000
root@rhel-client33 $> ntpq
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 20690  941a   yes   yes  none candidate    sys_peer  1
  2 20691  961a   yes   yes  none  sys.peer    sys_peer  1
  3 20692  8043   yes    no  none    reject unreachable  4
ntpq> rv 20690
associd=20690 status=941a conf, reach, sel_candidate, 1 event, sys_peer,
srcadr=ntp-serv-1-prod.mederd.com, srcport=123, dstadr=192.168.254.165,
dstport=123, leap=00, stratum=2, precision=-24, rootdelay=1.266,
rootdisp=45.624, refid=192.168.70.16,
reftime=e2f95d8c.2787b329  Tue, Sep  1 2020 16:53:48.154,
rec=e2f95f81.caf4d7e2  Tue, Sep  1 2020 17:02:09.792, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=22.821, delay=0.573, dispersion=15.377, jitter=22.260,
xleave=0.213,
filtdelay=     0.57    0.58    0.37    0.65    0.44    0.59    0.41    0.61,
filtoffset=   22.82   22.42   20.85   18.04   11.66    3.67   -7.68  -22.12,
filtdisp=      0.00   16.14   31.67   47.73   63.62   79.08   95.06  111.09
ntpq>
ntpq> rv 20691
associd=20691 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
srcadr=ntp-serv-2-prod.mederd.com, srcport=123, dstadr=192.168.254.165,
dstport=123, leap=00, stratum=2, precision=-14, rootdelay=0.229,
rootdisp=10.391, refid=192.168.70.17,
reftime=e2f9603b.70a20000  Tue, Sep  1 2020 17:05:15.439,
rec=e2f9604e.c9ee02c4  Tue, Sep  1 2020 17:05:34.788, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=3.341, delay=0.787, dispersion=19.008, jitter=2.186,
xleave=0.212,
filtdelay=     0.85    0.79    0.74    1.07    0.94    0.64    0.66    0.87,
filtoffset=    2.00    3.34    5.12    6.36    5.21    4.59    3.23   -0.44,
filtdisp=      0.06   15.66   31.22   46.89   62.40   78.03   93.74  109.52
ntpq>

Thanks in advance

TB0ne · 09-08-2020, 08:03 AM

Quote:

Originally Posted by james000

Hello,
I have RHEL 6.5 VM. There are two time servers configured on this. Both time-servers are also not real master, but they have further 4 GPS clocks, which are real time servers.
I got an alert from monitoring team that there was a difference of 5 seconds detected on this REHL VM. When I logged in, time was already good, it may have been synched by that time. But I am trying to understand, what would have caused it. ntpq output shows very large offset, I am not sure what would it mean. Can somebody suggest on this, if I need to check something else? I see no information for ntp or drift in /var/log/messages
Both servers are at same location

Code:

root@rhel-client33 $> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp-serv-1-prod. 192.168.70.16    2 u  663 1024  377    0.573   22.821  22.260
*ntp-serv-2-prod. 192.168.70.17    2 u  458 1024  377    0.787    3.341   2.186
 LOCAL(0)        .LOCL.          10 l 496d   64    0    0.000    0.000   0.000
root@rhel-client33 $> ntpq
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 20690  941a   yes   yes  none candidate    sys_peer  1
  2 20691  961a   yes   yes  none  sys.peer    sys_peer  1
  3 20692  8043   yes    no  none    reject unreachable  4
ntpq> rv 20690
associd=20690 status=941a conf, reach, sel_candidate, 1 event, sys_peer,
srcadr=ntp-serv-1-prod.mederd.com, srcport=123, dstadr=192.168.254.165,
dstport=123, leap=00, stratum=2, precision=-24, rootdelay=1.266,
rootdisp=45.624, refid=192.168.70.16,
reftime=e2f95d8c.2787b329  Tue, Sep  1 2020 16:53:48.154,
rec=e2f95f81.caf4d7e2  Tue, Sep  1 2020 17:02:09.792, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=22.821, delay=0.573, dispersion=15.377, jitter=22.260,
xleave=0.213,
filtdelay=     0.57    0.58    0.37    0.65    0.44    0.59    0.41    0.61,
filtoffset=   22.82   22.42   20.85   18.04   11.66    3.67   -7.68  -22.12,
filtdisp=      0.00   16.14   31.67   47.73   63.62   79.08   95.06  111.09
ntpq>
ntpq> rv 20691
associd=20691 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
srcadr=ntp-serv-2-prod.mederd.com, srcport=123, dstadr=192.168.254.165,
dstport=123, leap=00, stratum=2, precision=-14, rootdelay=0.229,
rootdisp=10.391, refid=192.168.70.17,
reftime=e2f9603b.70a20000  Tue, Sep  1 2020 17:05:15.439,
rec=e2f9604e.c9ee02c4  Tue, Sep  1 2020 17:05:34.788, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=3.341, delay=0.787, dispersion=19.008, jitter=2.186,
xleave=0.212,
filtdelay=     0.85    0.79    0.74    1.07    0.94    0.64    0.66    0.87,
filtoffset=    2.00    3.34    5.12    6.36    5.21    4.59    3.23   -0.44,
filtdisp=      0.06   15.66   31.22   46.89   62.40   78.03   93.74  109.52
ntpq>

Thanks in advance

The same answers apply as they did last year:
https://www.linuxquestions.org/quest...nd-4175651980/

Red Hat's knowledgebase:
https://access.redhat.com/solutions/278273

...and their suggestions: https://www.redhat.com/en/blog/avoiding-clock-drift-vms If you're paying for RHEL and have applied the updates, that should address the known issues with RHEL 6 and VM's. If not, contact Red Hat support, since something isn't working right. If this was an intermittent issue, it could have been something as simple as a network problem, which resolved itself before you could get to it. What do the logs say??