On Tue, Apr 19, 2011 at 05:01:54PM +0100, Ed W wrote:
> On 18/04/2011 12:23, Miroslav Lichvar wrote:
>
> > It would be interesting to try to apply only the bugfixes made since
> > 1.24 to a 1.24.1 branch and see how far it would go without conflict.
>
> I think my follow on caveat was something l
On 18/04/2011 12:23, Miroslav Lichvar wrote:
> It would be interesting to try to apply only the bugfixes made since
> 1.24 to a 1.24.1 branch and see how far it would go without conflict.
I think my follow on caveat was something like: if it doesn't apply
reasonably cleanly, then probably it's no
On Fri, Apr 15, 2011 at 06:06:40PM +0100, Ed W wrote:
> > Yes, git is very good at branching, but sometimes the patch can't be
> > applied cleanly and has to be backported. The time I can spend on
> > chrony is quite limited, I'd rather keep working only in one branch.
> > Are you willing to mainta
On Fri, Apr 15, 2011 at 11:02:21AM -0700, Bill Unruh wrote:
> On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
> >Hm, I have run few more simulations and it seems the overall accuracy
> >is about 10% worse than with the weighted variance.
>
> Not sure what you mean by this. Do you mean that the std de
On Fri, Apr 15, 2011 at 09:08:44AM -0700, Bill Unruh wrote:
> On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
>
> >On Fri, Apr 15, 2011 at 05:30:28AM -0700, Bill Unruh wrote:
> >>The problem with using the unweighted variance is that it sort of obviates
> >>the
> >>use of the weights.
> >
> >It does
On Fri, Apr 15, 2011 at 03:23:46PM +0200, Miroslav Lichvar wrote:
> On Fri, Apr 15, 2011 at 05:30:28AM -0700, Bill Unruh wrote:
> > The problem with using the unweighted variance is that it sort of obviates
> > the
> > use of the weights.
>
> It does, but it's used only for the weight calculation
Hi
>> Create a new branch for the next version and
>> hack away on new confidence calculations in there. Remember that if you
>> checkin a bug fix it's trivial to "pull" that to all release branches
>> (ie git makes it easy to maintain 1.1.x and 1.2.x and 1.3.x, where bug
>> fixes get easily pull
On Fri, Apr 15, 2011 at 05:30:28AM -0700, Bill Unruh wrote:
> The problem with using the unweighted variance is that it sort of obviates the
> use of the weights.
It does, but it's used only for the weight calculation.
> It certainly is an overestimate of the variance, but
> probably not too bad
On Thu, Apr 14, 2011 at 11:53:58AM +0100, Ed W wrote:
> However, getting back to release schedules - we have git - it's
> WONDERFUL for branching... Can I please suggest a feature freeze on the
> current code, revert anything which could be controversial and stabilise
> (urgently?) for a release.
On Fri, Apr 15, 2011 at 02:00:50AM -0700, Bill Unruh wrote:
> Just been looking at one of the latest chrony's and I do not
> understand the get_buf_index function. In theoriginal, min_distance
> is the minimum distance
> in the set of samples for this particular source. What is your
> min_distance?
On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
On Fri, Apr 15, 2011 at 03:23:46PM +0200, Miroslav Lichvar wrote:
On Fri, Apr 15, 2011 at 05:30:28AM -0700, Bill Unruh wrote:
The problem with using the unweighted variance is that it sort of obviates the
use of the weights.
It does, but it's used
On Fri, Apr 15, 2011 at 01:45:08AM -0700, Bill Unruh wrote:
> How the hell can it diverge? Is it possible to get the values of w[i]
> for this divergent example?
I think it's the distribution of the weights what makes it unstable
and it has to stay that way long enough to reach the inf (e.g. the
e
On Thu, Apr 14, 2011 at 09:19:47PM -0700, Bill Unruh wrote:
> I will try to write this up and send it to you (have a colloquium to give
> tomorrow, so it might take a day or two).
Ok, thanks.
> But the fact that the current
> precedure leads to and instability and in particular can badly underest
On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
On Fri, Apr 15, 2011 at 05:30:28AM -0700, Bill Unruh wrote:
The problem with using the unweighted variance is that it sort of obviates the
use of the weights.
It does, but it's used only for the weight calculation.
Not sure what you mean? Is the
On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
On Fri, Apr 15, 2011 at 01:45:08AM -0700, Bill Unruh wrote:
How the hell can it diverge? Is it possible to get the values of w[i]
for this divergent example?
I think it's the distribution of the weights what makes it unstable
and it has to stay tha
Just been looking at one of the latest chrony's and I do not understand the
get_buf_index function. In theoriginal, min_distance is the minimum distance
in the set of samples for this particular source. What is your min_distance?
Why is this get_buf_index needed?
---
To unsubscribe email c
On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
On Thu, Apr 14, 2011 at 09:19:47PM -0700, Bill Unruh wrote:
I will try to write this up and send it to you (have a colloquium to give
tomorrow, so it might take a day or two).
Ok, thanks.
But the fact that the current
precedure leads to and insta
On Fri, 15 Apr 2011, Miroslav Lichvar wrote:
On Thu, Apr 14, 2011 at 09:19:47PM -0700, Bill Unruh wrote:
Even the very latest code which uses the unweighted variance? I
haven't seen any problem with it yet.
Skew and hi/lo are from the sd of the slope, which I believe wasn't
affected by this p
On Thu, 14 Apr 2011, Miroslav Lichvar wrote:
On Thu, Apr 14, 2011 at 09:24:28AM -0700, Bill Unruh wrote:
On Thu, 14 Apr 2011, Miroslav Lichvar wrote:
weights2 are same for both sources, but weights1 are very different.
Agreed, but then I at least would have a lot less confidence in 2 rather
On Thu, Apr 14, 2011 at 09:24:28AM -0700, Bill Unruh wrote:
> On Thu, 14 Apr 2011, Miroslav Lichvar wrote:
> >weights2 are same for both sources, but weights1 are very different.
>
> Agreed, but then I at least would have a lot less confidence in 2 rather than
> 1 because of the longer delay.
Yes
On Wed, Apr 13, 2011 at 07:55:26PM -0700, Bill Unruh wrote:
> Ok I think I have figured out what is happening. The way in which the weights
> are used in the program is as if a set of w_i measurements were made at the
> point x_i, with each of them yielding the value y_i. But the estimate of the
>
On Thu, Apr 14, 2011 at 11:55:33AM +0200, Miroslav Lichvar wrote:
> source1:
> peer distances (ms):11.013.012.014.0
> min dist (ms): 11.0
> last sd (ms): 3.0
> weights1: 1.000 1.397 1.190 1.620
> weights2: 1.000 2.778 1.778
On Wed, Apr 13, 2011 at 02:28:40PM -0700, Bill Unruh wrote:
> On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
> >Why? A significant part of the distance is static delay corresponding
> >to the length of the path which the signal has travel through. I just
> >wanted to remove that from the weight calcu
On 14/04/2011 03:55, Bill Unruh wrote:
> Ok I think I have figured out what is happening. The way in which the
> weights
> are used in the program is as if a set of w_i measurements were made at the
> point x_i, with each of them yielding the value y_i. But the estimate of
> the
> standard deviatio
On Thu, 14 Apr 2011, Miroslav Lichvar wrote:
On Wed, Apr 13, 2011 at 02:28:40PM -0700, Bill Unruh wrote:
> On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
> >Why? A significant part of the distance is static delay corresponding
> >to the length of the path which the signal has travel through. I jus
On Wed, Apr 13, 2011 at 11:16:48AM -0700, Bill Unruh wrote:
> Adding a constant to the
> distance (assuming this did not change the min_distance) still changes the
> weights in yours (and a lot if sd gets small) .
I meant adding a constant to all distances.
> If you wanted you
> could put in sd+m
Ok I think I have figured out what is happening. The way in which the weights
are used in the program is as if a set of w_i measurements were made at the
point x_i, with each of them yielding the value y_i. But the estimate of the
standard deviation goes as 1/sqrt(N) where N is the total number of
On Wed, Apr 13, 2011 at 09:48:46AM -0700, Bill Unruh wrote:
> On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
> >sd = sqrt(inst->variance)
> >sd_weight = 1.0 + SD_TO_DIST_RATIO * (peer_distances[i] - min_distance) / sd;
> >weights[i] = sd_weight * sd_weight;
>
> That use of sd in the weights is new i
On Wed, Apr 13, 2011 at 09:01:43AM -0700, Bill Unruh wrote:
> Hm, whether one used normalised or unnormalised weights should not make a
> difference to the fit, or the variance in the slope. I looked at
> that code a few years ago, but have forgotten it by now. Will have
> to look again.
It doesn'
On Wed, Apr 13, 2011 at 01:30:28PM +0100, Ed W wrote:
> On 13/04/2011 12:10, Miroslav Lichvar wrote:
> > It seems the problem is that in the weights calculation is used
> > weighted variance, which can create the positive feedback. Using
> > unweighted variance instead should fix it nicely.
> >
>
On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
On Wed, Apr 13, 2011 at 11:16:48AM -0700, Bill Unruh wrote:
Adding a constant to the
distance (assuming this did not change the min_distance) still changes the
weights in yours (and a lot if sd gets small) .
I meant adding a constant to all distanc
On 13/04/2011 12:10, Miroslav Lichvar wrote:
> On Tue, Apr 12, 2011 at 09:32:31PM +0100, Ed W wrote:
>> On 12/04/2011 15:05, Miroslav Lichvar wrote:
>>> Hm, I just had a crash while I was messing with the tick value outside
>>> chronyd. The sourcestats stddev ended up as -nan which caused assert
>>
On Tue, Apr 12, 2011 at 09:32:31PM +0100, Ed W wrote:
> On 12/04/2011 15:05, Miroslav Lichvar wrote:
> > Hm, I just had a crash while I was messing with the tick value outside
> > chronyd. The sourcestats stddev ended up as -nan which caused assert
> > failure in find_best_sample_index. It seems to
On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
On Wed, Apr 13, 2011 at 09:48:46AM -0700, Bill Unruh wrote:
On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
sd = sqrt(inst->variance)
sd_weight = 1.0 + SD_TO_DIST_RATIO * (peer_distances[i] - min_distance) / sd;
weights[i] = sd_weight * sd_weight;
Th
On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
On Wed, Apr 13, 2011 at 09:01:43AM -0700, Bill Unruh wrote:
Hm, whether one used normalised or unnormalised weights should not make a
difference to the fit, or the variance in the slope. I looked at
that code a few years ago, but have forgotten it by
On Wed, 13 Apr 2011, Miroslav Lichvar wrote:
On Wed, Apr 13, 2011 at 01:30:28PM +0100, Ed W wrote:
On 13/04/2011 12:10, Miroslav Lichvar wrote:
It seems the problem is that in the weights calculation is used
weighted variance, which can create the positive feedback. Using
unweighted variance i
On 12/04/2011 15:05, Miroslav Lichvar wrote:
> On Sat, Apr 09, 2011 at 10:00:36PM +0100, Ed W wrote:
>> Been running this for a few days. Not particularly thrashing it, but
>> nothing untoward happened...
>>
>> How are we looking for a release?
>
> Hm, I just had a crash while I was messing with
On Sat, Apr 09, 2011 at 10:00:36PM +0100, Ed W wrote:
> Been running this for a few days. Not particularly thrashing it, but
> nothing untoward happened...
>
> How are we looking for a release?
Hm, I just had a crash while I was messing with the tick value outside
chronyd. The sourcestats stddev
On Mon, Apr 11, 2011 at 03:09:54PM -0700, Bill Unruh wrote:
> On Mon, 11 Apr 2011, Ed W wrote:
> >This probably seems rash since you are obviously in the conservative
> >release category: however, I would have preferred this release to be
> >(say) 1.29 with a bunch of prior releases plus bug fixes
On 11/04/2011 17:44, Miroslav Lichvar wrote:
> On Sat, Apr 09, 2011 at 10:00:36PM +0100, Ed W wrote:
>> Been running this for a few days. Not particularly thrashing it, but
>> nothing untoward happened...
>>
>> How are we looking for a release?
>
> Maybe at the end of this week? Should we go with
On Sat, Apr 09, 2011 at 10:00:36PM +0100, Ed W wrote:
> Been running this for a few days. Not particularly thrashing it, but
> nothing untoward happened...
>
> How are we looking for a release?
Maybe at the end of this week? Should we go with 1.25-pre2 first, or
final 1.25?
I definitely want to
On Mon, 11 Apr 2011, Ed W wrote:
On 11/04/2011 17:44, Miroslav Lichvar wrote:
On Sat, Apr 09, 2011 at 10:00:36PM +0100, Ed W wrote:
Been running this for a few days. Not particularly thrashing it, but
nothing untoward happened...
How are we looking for a release?
Maybe at the end of this w
Been running this for a few days. Not particularly thrashing it, but
nothing untoward happened...
How are we looking for a release?
:-)
Ed W
On 07/04/2011 17:36, g...@tuxfamily.net wrote:
> This is an automated email from git. It was enerated because a ref
> change was pushed to the repositor
This is an automated email from git. It was enerated because a ref
change was pushed to the repository "chrony/chrony.git".
The branch, master has been updated
via 20a43409c66d28d699f4c80bdf4157495898af77 (commit)
via 4699f7ca0b8f089cf07075f1a57a47118d07c3fd (commit)
via bc
44 matches
Mail list logo
