On Wed, Sep 13, 2023 at 15:52:26 +0200, Miroslav Lichvar wrote:
> On Wed, Sep 13, 2023 at 09:28:34AM -0400, Josef 'Jeff' Sipek wrote:
> > However, I also see that cooked_time (i.e., sys_ts+correction) is fed into
> > SPF_AccumulateSample as sample->time. Later on, combin
On Wed, Sep 13, 2023 at 14:02:48 +0200, Miroslav Lichvar wrote:
> On Wed, Sep 13, 2023 at 07:13:04AM -0400, Josef 'Jeff' Sipek wrote:
> > Just to make sure I understand, the "proper" way is to adjust the offset to
> > compensate for any rounding? IOW, something like
On Mon, Sep 11, 2023 at 16:46:07 +0200, Miroslav Lichvar wrote:
> On Mon, Sep 11, 2023 at 08:03:49AM -0400, Josef 'Jeff' Sipek wrote:
> > On Mon, Sep 11, 2023 at 10:29:30 +0200, Miroslav Lichvar wrote:
> > > That timestamp doesn't need much resolution. It just says when the
>
On Mon, Sep 11, 2023 at 10:29:30 +0200, Miroslav Lichvar wrote:
> On Fri, Sep 08, 2023 at 11:21:08AM -0400, Josef 'Jeff' Sipek wrote:
> > I'm playing with feeding data to the SOCK refclock with GPS time myself
> > (without using gpsd, etc.). I saw that the samples contain
On Fri, Sep 08, 2023 at 09:13:24 -0700, Bill Unruh wrote:
> Are you sure there is any point in nanosecond reporting?
Am I sure? No :)
> Ie, I would suspect that the uncertainty in those times is at best
> microsecond anyway, so nanosecond reporting is unwarrented accuracy. (Ie,
> it takes a
I'm playing with feeding data to the SOCK refclock with GPS time myself
(without using gpsd, etc.). I saw that the samples contain the host/system
timestamp as a struct timeval. I changed it to allow nanosecond time of
measurements but before I try to polish it and send it for inclusion, I
