Date: Wed, 8 May 2024 14:27:04 +0200 From: John Hay <john@sanren.ac.za> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD driver for the OCP TAP Time Card Message-ID: <CAGv8uao_c%2BaTxm9ynq0N0ebaHk_bSA1nzsZ4gp1DswzGwsDtuQ@mail.gmail.com> In-Reply-To: <202405080705.44875rwT067082@critter.freebsd.dk> References: <CAGv8uar=CmAXowLUS1H2hEHk3OPJPifgXSy3Ru9VodRcoy4yPA@mail.gmail.com> <202405080535.4485ZFN9066673@critter.freebsd.dk> <CAGv8uaoQn_XMB4=4%2B0ZLvyDd9BaZO=1KC1xDvnOpWLVKXDvoXw@mail.gmail.com> <202405080705.44875rwT067082@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000004c9a140617f06cc9 Content-Type: text/plain; charset="UTF-8" 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 --0000000000004c9a140617f06cc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Poul-Henning,<br></div><br><div class=3D"gmail_quo= te"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 8 May 2024 at 09:05, Poul= -Henning Kamp <<a href=3D"mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-= -------<br> John Hay writes:<br> <br> > The other is that the conversion from the above value to bintime and l= ater<br> > back to what is used elsewhere, seems to lose a little precision. The<= br> > comments in sys/kern/kern_tc.c also note that.<br> <br> Yes once the /resolution/ of the hardware gets into the nanosecond<br> domain, some of that resolution is lost, because a 64x64=3D>128<br> multiplication would have been both surplus to requirements and<br> beyond the pale.<br></blockquote><div><br></div><div>Yes, resolution is wha= t I meant. <br></div><div><br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"> <br> Getting rid of 32bit platforms moves the needle, but it may still<br> not be warranted.<br> <br> I will also note that most people who think they are approaching<br> nanosecond /precision/ are wrong about that:=C2=A0 Only a few of the<br> institutions listed in Circular T manage it.<br> <br> The important thing is to make sure the added noise is bias free.<br></bloc= kquote><div><br></div><div>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:</div><div><br></div><div><snip><br></div><div>> ntpq -c kernin= fo<br>associd=3D0 status=3D0415 leap_none, sync_uhf_radio, 1 event, clock_s= ync,<br>pll offset: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00<br>pll frequ= ency: =C2=A0 =C2=A0 =C2=A0 =C2=A0 1.52588e-05</div><div></snip></div>= <div></div><div><br></div><div>So just from that perspective, it feels that= there is some bias.</div><div><br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-left:1ex"> <br> You should capture some millions of the the difference between the<br> HW counter and the hw->timecounter->bintime->timespec result, and<= br> run that through the usual battery (Histogram, MVAR, FFT etc.)<br></blockqu= ote><div><br></div><div>I'll have a look at that.</div><div>=C2=A0<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> > In the pps code, I wished that one could provide a timestamp with pps_= capture<br> > (). It uses the time at which it handled the interrupt. The card latch= the<br> > counter values when the pps happens, so it knows the correct time. Cur= rently I<br> > hack around it by twiddling sc->sc_pps_state.capcount directly.<br> <br> That is not hacking around, that is how it is done :-)<br> <br> See for instance i386/i386/elan-mmcr.c<br></blockquote><div><br></div><div>= Ah, I forgot about that one and did not look there. :-) Thanks for the remi= nder.</div></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q= uote">Regards</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail= _quote">John</div><div class=3D"gmail_quote"><br></div></div> --0000000000004c9a140617f06cc9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGv8uao_c%2BaTxm9ynq0N0ebaHk_bSA1nzsZ4gp1DswzGwsDtuQ>