[ntp:questions] Re: 'summary.in' and 'plot_summary.in
Richard B. Gilbert
rgilbert88 at comcast.net
Mon Jan 24 18:24:22 UTC 2005
Nigel Smith wrote:
>I am looking for ways to analyze and graph the statistics generated by
>NTP and came across the two perl files 'summary.in' and
>'plot_summary.in' in the scripts directory of ntp-4.2.0.tar.gz
>
>Is any one else using these scripts? What is your experience with them?
>
>When I try analyzing my statistics, with 'summary.in', I am getting a
>few error lines like this:
>Can't take sqrt of -384.314 at /root/summary.pl line 326.
>Can't take sqrt of -427.51 at /root/summary.pl line 326.
>Can't take sqrt of -1.63582e+08 at /root/summary.pl line 326.
>
>How worried should I be by these errors? What could be causing them?
>Has any one got a fix for the code?
>
>Can anyone recommend any other good ways to analyze and graph the
>statistics file, both on a daily basis and also more long term
>analysis?
>
>Thanks
>Nigel Smith
>
>
>
I just had a *very* quick look at that code. It looks as if the author
fell into a relatively well known trap.
Variance is defined as "the square root of the sum of the squares of the
sample deviations from the mean divided by the number of samples. The
safe way to calculate this requires that you first find the mean of the
samples and then calculate the sum of the squares of the deviations from
the mean. Many programmers use a shortcut that is mathematically
equivalent but is not "computationally equivalent" when using floating
point numbers.
That shortcut looks like this (in pseudo code)
a=0
for i = 1 to N
{
s +=x**2
t+=x
}
sigma = s/N - (t/N)**2
Computations using a limited number of significant figures can result
in a mathematically impossible result of a negative variance. When you
then try to calculate the standard deviation by finding the square root
of the variance, the program blows up in your face.
It looks as if the code does something similar. The only sure fix is
to rewrite the code to do the calculation in a way that is both
mathematically and computationally correct! If perl supports "double
precision" the additional significant figures might alleviate the
problem somewhat but probably not eliminate it completely.
More information about the questions
mailing list