On Mon, Dec 05, 2016 at 02:35:22PM -0800, Denny Page wrote:
>
> > On Dec 05, 2016, at 01:05, Miroslav Lichvar wrote:
> >
> > If I understand your change correctly, it increases the minimum
> > acceptable delay, which increases the number of combined readings and
> > makes the offset more stable.
This is an automated email from git. It was generated because a ref
change was pushed to the "chrony/chrony.git" repository.
The branch, master has been updated
via 68039e0d14376d443c70e94de8f7d24a05cc3d80 (commit)
via 65fd30a5473f0a13a216e2d481236ebe54058b41 (commit)
via 2
Yes, the general server that I refer to, and which the graphs are from, is
fairly active on the primary nic. It’s the network log server, does some DB,
etc.
On the quiet system, the change has much less impact. But it was the general
server that I was frequently seeing small spikes on.
I can c
After 7 days: https://dan.drown.org/odroid/run5.7/tempcomp.png
It looks like tempcomp is helpful but maybe my reference is drifting.
I want to try this again with a better TCXO.
Temperature vs tempcomp is an interesting graph:
https://dan.drown.org/odroid/run5.7/tempcomp-temps.png
Clock
Not sure what you meant here. The current code bases all its calculations of
intervals base on the begin time of slot zero. Even if slot zero is bad, it’s
total window is used in each time interval calculation. In the new code, a bad
slot is never used in any way even if it is slot zero.
Denny
On Tue, Dec 06, 2016 at 10:00:40PM -0800, Denny Page wrote:
> Not sure what you meant here. The current code bases all its calculations of
> intervals base on the begin time of slot zero. Even if slot zero is bad, it’s
> total window is used in each time interval calculation. In the new code, a
On Tue, Dec 06, 2016 at 09:54:41PM -0600, Dan Drown wrote:
> After 7 days: https://dan.drown.org/odroid/run5.7/tempcomp.png
>
> It looks like tempcomp is helpful but maybe my reference is drifting. I
> want to try this again with a better TCXO.
Ok, thanks for the data.
> I setup a quick benchma
