Hi helo, new here and hoping for your opinion;
CSV mode is documented for consumption by scripts, but print_report() in
client.c applies the human-readable precision to frequency fields: 'F' and
'P' set prec = 3, while offsets ('O' and 'S') get prec = 9. A format meant
for parsing therefore rounds frequency to 1e-3 ppm while giving offsets
1e-9 s.
On a rubidium-referenced stratum-1 host this makes the field unusable.
Measured offset here is -3.55e-10 (-0.000355 ppm) with skew 2.4e-11.
"chronyc -c tracking" reports:
...,0.000000002,-0.000000002,0.000000001,-0.000,-0.000,0.000,...
|___ offsets, 9 decimals ___| |_ freq/resid/skew, 3 _|
The whole frequency error is about a third of one printed LSB, and skew is
five orders below it.
chronyd already carries more precision elsewhere: the drift file writes 6
decimals of ppm, and the adjtimex freq field it drives resolves 2^-16 ppm
(1.53e-11). Reading the kernel directly is currently the only way to get a
value chronyd already knows.
Would a change to give 'F' and 'P' the same precision as offsets in CSV
mode be acceptable -- prec = 9, or 6 to match the drift file? Column width
is not a concern for a parsed format, and extra digits do not affect float
parsers. I am happy to send a patch if so.
Tested on 4.9; the constants are unchanged in master.
Thanks for your time!
Br
Markus Kovero
mui@xxxxxx