From nobody Wed May 8 07:05:53 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VZ5lV2r5Lz5KTnw for ; Wed, 08 May 2024 07:05:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VZ5lV0hylz4kwk for ; Wed, 8 May 2024 07:05:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B329389293; Wed, 08 May 2024 07:05:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.18.1/8.16.1) with ESMTPS id 44875tht067083 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 8 May 2024 07:05:55 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 44875rwT067082; Wed, 8 May 2024 07:05:53 GMT (envelope-from phk) Message-Id: <202405080705.44875rwT067082@critter.freebsd.dk> To: John Hay cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD driver for the OCP TAP Time Card In-reply-to: From: "Poul-Henning Kamp" References: <202405080535.4485ZFN9066673@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67080.1715151953.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 08 May 2024 07:05:53 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4VZ5lV0hylz4kwk -------- 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= .