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
[-- Attachment #1 --] 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 [-- Attachment #2 --] <div dir="ltr"><div>Hi Poul-Henning,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 May 2024 at 09:05, Poul-Henning Kamp <<a href="mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 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 later<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=>128<br> multiplication would have been both surplus to requirements and<br> beyond the pale.<br></blockquote><div><br></div><div>Yes, resolution is what I meant. <br></div><div><br></div><blockquote class="gmail_quote" style="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: 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></blockquote><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 kerninfo:</div><div><br></div><div><snip><br></div><div>> ntpq -c kerninfo<br>associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,<br>pll offset: 0<br>pll frequency: 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="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-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></blockquote><div><br></div><div>I'll have a look at that.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-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. Currently 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 reminder.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards</div><div class="gmail_quote"><br></div><div class="gmail_quote">John</div><div class="gmail_quote"><br></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGv8uao_c%2BaTxm9ynq0N0ebaHk_bSA1nzsZ4gp1DswzGwsDtuQ>