[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