Seemingly poor quality of NTP time synchronization using a GPS clock

The value that ntpstat displays after "time correct to within" is the root dispersion + root delay / 2. ntpq -p doesn't show the "root dispersion" run ntpq -c rl instead.

Notwithstanding, it is clear that the main source of the lack of accuracy is the dispersion rather than the delay (which is only 0.964).

The dispersion is the "nominal error relative to the primary reference source." I've briefly looked through the NTPv4 RFC and this is what it has to to say:

The dispersion (epsilon) represents the maximum error inherent in the measurement. It increases at a rate equal to the maximum disciplined system clock frequency tolerance (PHI), typically 15 PPM. 1 PPM is equal to 10^(-6) seconds/second.

To use rrdtool terminology dispersion isn't a gauge but rather a counter. Seeing a large value may not indicate anything is wrong.

Alas, I wasn't able to understand the ntp algorithm well enough to see how to make this number smaller. I've noticed this value is reset occasionally. I don't know why.

The reason I asked about the hardware above is because many GPS devices (stratum 0, the 'root' source) connect to the computer that then acts as the NTP server via a serial link.

Serial connections often have 1-5ms jitter on the line due to signalling overheads/interrupt waits. Hence, I'm guessing your NTP source is reading from a serial source.

There are some tweaks you may be able to perform on the serial connection to reduce jitter. Primaily, disabling FIFO may gain you decent results.

http://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.5. http://www.febo.com/time-freq/ntp/jitter/index.html

Time correct within 5 ms IS GREAT!!! 5 ms is 5 / 1000 of a second. Anything under 100 ms is easily acceptable for anything other than a small handful of situations in that case you would not be using GPS but a local atomic clock and two external reference clocks. We get within 10 ms with the ntp pool.