Re: FreeBSD driver for the OCP TAP Time Card

Hi Poul-Henning,

On Wed, 8 May 2024 at 09:05, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> John Hay writes:
>
> > The other is that the conversion from the above value to bintime and
> later
> > back to what is used elsewhere, seems to lose a little precision. The
> > comments in sys/kern/kern_tc.c also note that.
>
> Yes once the /resolution/ of the hardware gets into the nanosecond
> domain, some of that resolution is lost, because a 64x64=>128
> multiplication would have been both surplus to requirements and
> beyond the pale.
>

Yes, resolution is what I meant.


> Getting rid of 32bit platforms moves the needle, but it may still
> not be warranted.
>
> I will also note that most people who think they are approaching
> nanosecond /precision/ are wrong about that:  Only a few of the
> institutions listed in Circular T manage it.
>
> The important thing is to make sure the added noise is bias free.
>

I have 3 machines with Time Cards installed. If I use the TimeCard as
timecounter and do not discipline the kernel time, it will slowly drift
away. If I use ntpd to discipline it, all three machines settle on a pll
frequency of 1.52588e-05 (ppm) according to ntpq -c kerninfo:

<snip>
> ntpq -c kerninfo
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
pll offset:            0
pll frequency:         1.52588e-05
</snip>

So just from that perspective, it feels that there is some bias.


> You should capture some millions of the the difference between the
> HW counter and the hw->timecounter->bintime->timespec result, and
> run that through the usual battery (Histogram, MVAR, FFT etc.)
>

I'll have a look at that.


>
> > In the pps code, I wished that one could provide a timestamp with
> pps_capture
> > (). It uses the time at which it handled the interrupt. The card latch
> the
> > counter values when the pps happens, so it knows the correct time.
> Currently I
> > hack around it by twiddling sc->sc_pps_state.capcount directly.
>
> That is not hacking around, that is how it is done :-)
>
> See for instance i386/i386/elan-mmcr.c
>

Ah, I forgot about that one and did not look there. :-) Thanks for the
reminder.

Regards

John