proposal for sntp program: include 'delay' in json output

[Fred Wright]

On Mon, 2 Jan 2023, folkert via devel wrote:

[...]
>> It makes it include the delay in the json output.

Note that the delay is not the full story in the time uncertainty.  A 
long-standing ntpdig bug is that it fails to include the dispersion.  The 
delay gives the uncertainty in the server->client time transfer, while the 
dispersion gives the uncertainty on the server itself.  Note that the 
dispersion is a one-sided error, while RTT is a two-sided error.  I.e., 
the total uncertainty is +/- (RTT/2 + dispersion).

In principle, this would be trivial to fix, but when I looked into it, it 
didn't appear that the dispersion field was plumbed through the Python 
packet interface.  I'm not sure why the latter is being so stingy.

A side effect of this bug is this allows truly insane dispersion values 
reported by ntpd to go mostly unnoticed, such as when the pps driver is 
the primary time source.  In that case, it seems to have a base value of 
400 *milliseconds*.  E.g.:

MacPro:~ fw$ ntpdig time
2023-01-04 14:34:46.267351 (-0800) -0.000029 +/- 0.000304 time 172.24.0.30 s1 no-leap
MacPro:~ fw$ msntp time
2023 Jan 04 14:34:50.172 - 0.000 +/- 0.400 secs

(note msntp only reports millisecond resolution in its usual modes)

I did a brief search in the source to see if there was an obvious source 
of the 400ms value and didn't find one.  But I do note that the doc says 
that the PPS source needs to be within 400ms of the primary source to be 
considered, and that may not be a coincidence.

Fred Wright