Re: FreeBSD driver for the OCP TAP Time Card
- In reply to: Poul-Henning Kamp: "Re: FreeBSD driver for the OCP TAP Time Card"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 08 May 2024 12:27:04 UTC
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