From nobody Wed May 08 12:27:04 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 4VZDtJ3LzMz5J1qT for ; Wed, 08 May 2024 12:27:20 +0000 (UTC) (envelope-from john@sanren.ac.za) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VZDtH3PXCz4L5y for ; Wed, 8 May 2024 12:27:18 +0000 (UTC) (envelope-from john@sanren.ac.za) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2b338460546so3255041a91.1 for ; Wed, 08 May 2024 05:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sanren-ac-za.20230601.gappssmtp.com; s=20230601; t=1715171237; x=1715776037; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0Nac6YtuCYDUXrC3MQf9Hc2zfDL4wtPoV55a5akAw/w=; b=YFeMPYtJl1VWveicg1eALnRAWOkwZA78beSIYrXa4wBTUB+8FUP6BM73l3LHu9yr7o aG+t8NYxQKz3GmmMQrGsWv4Nf3Q/o5wiTbFc1Jc/8ViTmYicyeuBf8gMwWpjVKBMJgkg EQ/Uy3FQV+ILcR8M16gKCg8SDqD8SzSkM0bMHHB8xaX2Md0EOvNyodnO2jBKvnKZSxKR bUFEOpC7W0qIN0r2ge0zYbsTUT5nLfICoAc+bjiZSDir/9EK478l1CYIbQ+1w/5RTT2T 7wK+N2efXLmX21avmutbAzerGKgAwNiYc7LTmAfuP+hPq2Ak+f8oolrcxVxBz4wxH6Rz B6lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715171237; x=1715776037; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0Nac6YtuCYDUXrC3MQf9Hc2zfDL4wtPoV55a5akAw/w=; b=pB9ERAde7tIGVQemks4bB/stNDyWeahJHbuXoHRLjs4l1qY7ei+9JWb4TwLZYfQdXE h31xiQscfVeCZ8TE0IyW6NQS+2FGIgeeB1JysiygfbIXcH1o3c+CFhtZLc6YvmUIa9wW bpOdQvqu+e3aA/9P/zTjxlCQkaFDJnVrcgNjjaymztG6uHzS/pO3+EpNs1ezBE3awBfJ VPytdQ8tyWQNkQYbsi54GK0xipFQEJNblmZzctMZyez39iZSzUL9bL6iaduHNDxetIXN RAgasXYbtZbLo/Phuq1ihnSaySgUwZ8V5QCgo706z5I+6VV/nHaHV1lLDvcc9QyzmQsm BPqw== X-Gm-Message-State: AOJu0YwWf1OziJfjtfq5pbDryJoynkgo8yWh/HIsz11qQ9BxVFC4HNdc P8bmEJ/qLNLi+dWvF7cRT0iHqt90E/tyRRoW8GpEBae17Ge9r+Rj+sZb4qvN3gSXfj6cr77EGBk sGVI+x18/e43ZuC2hIAuqIWsCz1cuBkk4F126QEvQfsL/vs1U X-Google-Smtp-Source: AGHT+IEL6857HsHKUbRJcoHY+kf1rRqgOGf8szsvfPdZQZJpPwdQwKauSNSngwPL5c82i/CWpRPF77vqonE27zAk+fk= X-Received: by 2002:a17:90b:46d2:b0:2b0:e2cf:118b with SMTP id 98e67ed59e1d1-2b6169db57fmr2332636a91.33.1715171236804; Wed, 08 May 2024 05:27:16 -0700 (PDT) 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 References: <202405080535.4485ZFN9066673@critter.freebsd.dk> <202405080705.44875rwT067082@critter.freebsd.dk> In-Reply-To: <202405080705.44875rwT067082@critter.freebsd.dk> From: John Hay Date: Wed, 8 May 2024 14:27:04 +0200 Message-ID: Subject: Re: FreeBSD driver for the OCP TAP Time Card To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004c9a140617f06cc9" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VZDtH3PXCz4L5y --0000000000004c9a140617f06cc9 Content-Type: text/plain; charset="UTF-8" Hi Poul-Henning, On Wed, 8 May 2024 at 09:05, Poul-Henning Kamp 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: > ntpq -c kerninfo associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, pll offset: 0 pll frequency: 1.52588e-05 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 --0000000000004c9a140617f06cc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Poul-Henning,

On Wed, 8 May 2024 at 09:05, Poul= -Henning Kamp <phk@phk.freebsd.dk<= /a>> wrote:
-= -------
John Hay writes:

> The other is that the conversion from the above value to bintime and l= ater
> back to what is used elsewhere, seems to lose a little precision. The<= br> > 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:=C2=A0 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 kernin= fo:

<snip>
> ntpq -c kernin= fo
associd=3D0 status=3D0415 leap_none, sync_uhf_radio, 1 event, clock_s= ync,
pll offset: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
pll frequ= ency: =C2=A0 =C2=A0 =C2=A0 =C2=A0 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<= br> run that through the usual battery (Histogram, MVAR, FFT etc.)

I'll have a look at that.
=C2=A0
<= /div>

> 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. Cur= rently 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 remi= nder.

Regards

John

--0000000000004c9a140617f06cc9--