| Re: [chrony-dev] SOCK refclock system time resolution |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] SOCK refclock system time resolution
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Wed, 13 Sep 2023 15:52:26 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694613150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EJnr42D1IB3gNV2yAppk+Fji1/iX7hJBpCozCrAGLAA=; b=NX9ygW6crD0tlNtazqRPFU1LWkgkT6t7pJDpDFlwdyVIRYPm2f2ELtRNwsWpS/qv12OLg8 0Ww3GyFHGVrPyELGbT8Wxoyb/j4zt/gafl07vHzXT123GDzC8Q7H5XV3qog+D14borAaU8 0yAwDw3L93PHWl1KP+nUr4wh/XLazL4=
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, combine_selected_samples
> makes use of ->time to calculate various things. So, it looks like any
> error due to ns->us truncation will affect the math here. At a glance, I
> can't tell if the effect is so small that it can be ignored or if there is
> any benefit to avoiding the [0,999] ns error.
It's so small that it can be ignored. The time at which the offset was
measured is not that important. The frequency error between the
reference and current clock is minimized by the control loop, usually
to less than a ppm. Even if it was 1000 ppm, over a 1 microsecond
interval that would still make only 1 nanosecond of phase error. It's
well hidden in the noise. The main purpose of that timestamp is
detection of stale and out-of-order samples.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.