Re: [chrony-dev] chronyc: CSV output rounds frequency fields to 3 decimals

["Markus Kovero" <mui@xxxxxx>]

September 22, 2026 at 10:58, "Miroslav Lichvar" <mlichvar@xxxxxxxxxx> wrote:

> On Mon, Sep 21, 2026 at 07:22:53PM +0300, Markus Kovero wrote:
> > 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.
>
> I occasionally hit this problem with skew showing up as 0 too. More
> digits might be misleading with larger values. I think the best
> solution would be to add a new chronyc option to switch to the
> exponential %e notation with the number of digits matching the custom
> 32-bit floating-point format used in the chronyd<->chronyc protocol,
> so it will print what it actually gets from chronyd.
>
> I'll look into it.
>
> -- 
> Miroslav Lichvar

That sounds better than what I suggested — matching the digits to the

wire format handles the large-value case my fixed-precision idea would

have got wrong, and it covers skew reading 0 as well. Happy to test a

patch on a rubidium-referenced host if that is useful; the offset here

sits around 2e-11, so it exercises the small end.

Thanks for this)

Br

Markus Kovero

mui@xxxxxx