Re: [chrony-dev] [PATCH] Allow to override build date

2017-10-05 Thread Miroslav Lichvar
On Wed, Oct 04, 2017 at 09:12:24PM +0200, Bernhard M. Wiedemann wrote: > in order to make builds reproducible. > See https://reproducible-builds.org/ for why this is good > and https://reproducible-builds.org/specs/source-date-epoch/ > for the definition of this variable. That looks useful. > -

Re: [chrony-dev] Runtime refclock management

2017-10-05 Thread Miroslav Lichvar
On Wed, Oct 04, 2017 at 03:10:15PM -0400, Will Miles wrote: > On 2017-10-04 6:15 AM, Miroslav Lichvar wrote: > > On Tue, Oct 03, 2017 at 02:30:09PM -0400, Will Miles wrote: > > > What is the best way to submit a patch sequence?   Currently I've got it > > > up > > > on github at > > > https://gith

[chrony-dev] [PATCH] enable stratum setting for refclocks

2017-10-05 Thread Andreas Steinmetz
The attached patch allows the setting of the stratum for refclocks. This is missing as e.g. a PHC refclock may not be stratum 0 (actual timesource -> qemu host -> guest with chronyd using PHC). Example configuration with patch applied: refclock PHC /dev/ptp0 poll 3 dpoll -2 offset 0 stratum 2 Re

[chrony-dev] [PATCH] Allow to override build date

2017-10-05 Thread Bernhard M. Wiedemann
in order to make builds reproducible. See https://reproducible-builds.org/ for why this is good and https://reproducible-builds.org/specs/source-date-epoch/ for the definition of this variable. --- version 2 using if+else to match style of the remainder of the script --- configure | 6 +- 1 f

[chrony-dev] [contrib] unidled: a linux idle management daemon for chronyd/gpsd

2017-10-05 Thread Andreas Steinmetz
cronyd in combination with gpsd (using a gps receiver with a pps output) is well capable of sub microsecond precision. Unfortunately modern x86 (and possibly other) CPUs use aggressive power management which reduces the precision to high one digit and even lower two digit microsecond precision. Ef

Re: [chrony-dev] [PATCH] Allow to override build date

2017-10-05 Thread Miroslav Lichvar
On Thu, Oct 05, 2017 at 02:13:53PM +0200, Bernhard M. Wiedemann wrote: > in order to make builds reproducible. > See https://reproducible-builds.org/ for why this is good > and https://reproducible-builds.org/specs/source-date-epoch/ > for the definition of this variable. > > --- > version 2 using

[chrony-dev] [GIT] chrony/chrony.git branch master updated. 3.2-2-g6f54210

2017-10-05 Thread git
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 6f54210db29db71fd84e0e880435840a9b76da3c (commit) from f6539449c5332b9fb79a7dff844ef5b006445f56 (commit) Those revisi

Re: [chrony-dev] [PATCH] enable stratum setting for refclocks

2017-10-05 Thread Miroslav Lichvar
On Thu, Oct 05, 2017 at 02:12:49PM +0200, Andreas Steinmetz wrote: > The attached patch allows the setting of the stratum for refclocks. > This is missing as e.g. a PHC refclock may not be stratum 0 (actual > timesource -> qemu host -> guest with chronyd using PHC). > > Example configuration with

Re: [chrony-dev] [PATCH] enable stratum setting for refclocks (take 2)

2017-10-05 Thread Andreas Steinmetz
On Thu, 2017-10-05 at 18:35 +0200, Miroslav Lichvar wrote: > On Thu, Oct 05, 2017 at 02:12:49PM +0200, Andreas Steinmetz wrote: > > The attached patch allows the setting of the stratum for refclocks. > > This is missing as e.g. a PHC refclock may not be stratum 0 (actual > > timesource -> qemu host

Re: [chrony-dev] Runtime refclock management

2017-10-05 Thread Will Miles
On 2017-10-05 5:05 AM, Miroslav Lichvar wrote: On Wed, Oct 04, 2017 at 03:10:15PM -0400, Will Miles wrote: I think I saw a missing Free() for the driver name and parameter when adding refclock failed. Aha!  Actually the parameter string and inst struct itself also need to be Free()d there.   

[chrony-dev] NTP "extended information" draft WIP implementation

2017-10-05 Thread Will Miles
Hi, Attached is a patch sequence for implementing Harlan Stenn's draft "Extended Information" NTPv4 extension as a mechanism to distribute TAI offsets between nodes.   This should be considered beta quality at best - it hasn't been thoroughly debugged, and there is undoubtedly significant roo