[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: FreeBSD driver for the OCP TAP Time Card
From: John Hay <john () sanren ! ac ! za>
Date: 2024-05-08 12:27:04
Message-ID: CAGv8uao_c+aTxm9ynq0N0ebaHk_bSA1nzsZ4gp1DswzGwsDtuQ () mail ! gmail ! com
[Download RAW message or body]
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 #3 (text/html)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic