Date: Wed, 08 May 2024 07:05:53 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John Hay <john@sanren.ac.za> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD driver for the OCP TAP Time Card Message-ID: <202405080705.44875rwT067082@critter.freebsd.dk> In-Reply-To: <CAGv8uaoQn_XMB4=4%2B0ZLvyDd9BaZO=1KC1xDvnOpWLVKXDvoXw@mail.gmail.com> References: <CAGv8uar=CmAXowLUS1H2hEHk3OPJPifgXSy3Ru9VodRcoy4yPA@mail.gmail.com> <202405080535.4485ZFN9066673@critter.freebsd.dk> <CAGv8uaoQn_XMB4=4%2B0ZLvyDd9BaZO=1KC1xDvnOpWLVKXDvoXw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- John Hay writes: > The other is that the conversion from the above value to bintime and lat= er > 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=3D>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_ca= pture > (). It uses the time at which it handled the interrupt. The card latch t= he > counter values when the pps happens, so it knows the correct time. Curre= ntly 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= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202405080705.44875rwT067082>