Re: FreeBSD driver for the OCP TAP Time Card
- Reply: John Hay : "Re: FreeBSD driver for the OCP TAP Time Card"
- In reply to: John Hay : "Re: FreeBSD driver for the OCP TAP Time Card"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 08 May 2024 07:05:53 UTC
-------- 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. 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. 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.) > 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 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.