AFAIK, the times are different because one is your local clock
(hich is bouncing around as ticks get dropped) and the other
is the time from your peer's clock when it was last polled.

One machine I have says:

ntpq> rv  
status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg
system="NetBSD", leap=00, stratum=3, rootdelay=61.68,
rootdispersion=49.35, peer=27404, refid=mjh-gateway.DSG.Stanford.EDU,
reftime=b8c41a39.d5cce000  Wed, Mar 25 1998 16:05:13.835, poll=10,
                                           ^^^^^^^^^^^^^
clock=b8c41c21.8f51b000  Wed, Mar 25 1998 16:13:21.559, phase=2.613,
                                          ^^^^^^^^^^^^^
freq=19870.47, error=27.47

which matches nicely to  the interval since the last poll:


ntpq> peers
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*mjh-gateway.DSG time.nist.gov    2 u  494  512  377    -0.15    2.613    3.19
[rest snipped]

Comp.protocols.time.ntp is a good place to ask, but the HTML files in
the standard distribution are very good if you have the time and
patience to read them through.  Possibnly twice, once ot understand
whats going on and another time to get the details.

I also checked the xntp3-5.90.3 docs; a PPS signal is ignored unless
xntpd thinks it has locked to within 500ms. 

So, maybe, just maybe the inkernel hybrid PLL/FLL would work with PPS
if you switched to FLL mode.  Your mac would be chiming at a different
point than your other tickers but it least the difference wouldnt be
changing as drastically ;)