Installed the latest version of nidas (revision 5771M) today, with the new process running at 19:49 UTC.
The new nidas has some improvements in the serial handling efficiency. Don't see any effect on the number of "spurious interrupts" though.
Also restarted ntp daemon. Added a "server ral" entry in /etc/ntp.conf so that we can compare our local GPS time source with the ral server.
ntpq -p shows good agreement (-8.285 millisecond offset) with the ral server:
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
xral 208.75.88.4 3 u 7 64 377 0.368 -8.285 1.249
oGPS_NMEA(0) .GPS. 2 l 15 16 377 0.000 -0.028 0.031
Querying the ral ntp server, with ntpq -p ral shows that it has offsets with its servers, probably related to the big delays over its wifi connection:
ntpq -p ral
remote refid st t when poll reach delay offset jitter
==============================================================================
+64.6.144.6 128.252.19.1 2 u 300 1024 177 43.800 -32.309 12.143
*208.75.88.4 192.12.19.20 2 u 997 1024 377 56.151 16.212 0.321
+64.73.32.134 192.5.41.41 2 u 502 1024 377 42.897 7.307 110.558
Later, Oct 16, 15:24 MDT, saw smaller offsets all around:
root@manitou root# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
xral 208.75.88.4 3 u 39 64 377 0.354 1.108 0.390
oGPS_NMEA(0) .GPS. 2 l - 16 377 0.000 0.003 0.031
root@manitou root# ntpq -p ral
remote refid st t when poll reach delay offset jitter
==============================================================================
+64.6.144.6 128.252.19.1 2 u 135 1024 373 41.912 0.464 74.268
*208.75.88.4 192.12.19.20 2 u 840 1024 357 56.112 2.963 1.735
+64.73.32.134 192.36.143.150 2 u 317 1024 377 39.507 1.365 64.459