I'm trying to debug an ntp issue, and these two commands return inconsistent results. For instance, in queries to the same server, here are a few fields that don't match.
Specifically, the reference time doesn't match, the filter delay appears to be off by an order of magnitude, and the offsets don't match, and dispersion seems to have no relation.
ntpq> rv ####
status=963a
rootdelay=19.272
rootdisp=155.930,
refid=97.107.129.217,
reftime=db6319d2.3731b8d0 Sat, Aug 20 2016 18:02:58.215,
rec=db631d65.4f5ed180 Sat, Aug 20 2016 18:18:13.310
offset=-36.337
delay=0.229
dispersion=67.086
jitter=50.157,
xleave=0.070,
filtdelay= 0.32 0.29 0.39 0.23 1.47 0.62 0.39 0.23,
filtdisp= 0.00 16.05 32.15 48.24 64.19 80.49 96.23 97.26
# ntpdate -d 10.42.244.182
ntpdate 4.2.6p5@1.2349-o Tue May 31 10:09:22 UTC 2016 (1)
delay 0.02579
dispersion 0.00000
reference time: db631c03.1e5e805a Sat, Aug 20 2016 18:12:19.118
filter delay: 0.02591 0.02585 0.02579 0.02579
0.00000 0.00000 0.00000 0.00000
delay 0.02579
dispersion 0.00000
offset -0.113547
Both commands are doing completely different things.
ntpq is querying a running ntp server. So, the values returned are the current state of the association between this server and the related peer.
ntpdate is running ntp protocol handshake with the specified server.
So usually, ntpq is giving values from long term observation of the peer (poll interval), while ntpdate is giving a rather short term snapshot.
Thus, even if the server given in your example (10.42.244.182) exactly is the peer that is returned with assoc id 0 from ntpq, the values need not be identical.