Hi,
The variance, which is used to calculate the stdev, is stored in a
64-bit integer.
However, what we store there are the squares of the difference from
the average. So if you have 70 second ping time (sometimes), the
square of 70000 miliseconds becomes 4900 million! Quite a lot, but
unlikely to overflow a 64-bit value.... However the calculation is
done in microseconds.... Thus your 70 seconds is 70 million
microseocnds, giving 4900 trillion (4.9 * 10^15) added to the running
total every second or so, (as long as the average remains around
zero). This can overflow a 64-bit variable in human-observable time.
I've modified the code to do the calculations in miliseconds from now
on. This should buy us a factor of a million of margin. :-)
Roger.
On Sun, Dec 16, 2012 at 08:30:28AM -0500, The Wanderer wrote:
> Package: mtr
> Version: 0.82-3
> Severity: minor
>
> Dear Maintainer,
>
> As part of an effort to diagnose - and later to confirm the fix of - an
> ongoing network problem, I have maintained an mtr session running for
> several weeks straight.
>
> The current overall summary for one hop in that session presently reads
> as follows:
>
> Hostname Loss Rcv Snt Last Best Avg Worst StDev
> 73.223.7.1 0.3% 4028069 4039341 68 7 12 60593 -2147483.75
>
> The standard deviation value is negative, which is meaningless AFAIK,
> and therefore should not be possible. The specific negative value in
> question looks at a glance like the result of an overflow.
>
> I am not clear on exactly what it would take to reproduce this problem.
> Presumably, unreasonably high worst-case ping times in what is otherwise
> a normal network environment would be at least a contributing factor.
> However, I am relatively certain that I recall past sessions where this
> hop has shown a Worst value of over 70000 milliseconds, but the StDev
> value has remained positive; as such, I am not sure whether that would
> be sufficient.
>
> This bug is of course extremely minor, as even if it does occur
> reproducibly, the circumstances for it are rare and it is unlikely to
> have more than a cosmetic effect even when it does occur. However, as it
> is still a bug, I felt it worth reporting anyway.
>
> If there is anything I can do to help to track this down, please don't
> hesitate to let me know.
>
>
> -- System Information:
> Debian Release: wheezy/sid
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages mtr depends on:
> ii libatk1.0-0 2.4.0-2
> ii libc6 2.13-35
> ii libcairo2 1.12.2-2
> ii libfontconfig1 2.9.0-7
> ii libfreetype6 2.4.9-1
> ii libgdk-pixbuf2.0-0 2.26.1-1
> ii libglib2.0-0 2.33.12+really2.32.4-3
> ii libgtk2.0-0 2.24.10-2
> ii libncurses5 5.9-10
> ii libpango1.0-0 1.30.0-1
> ii libtinfo5 5.9-10
>
> mtr recommends no packages.
>
> mtr suggests no packages.
>
> -- no debconf information
>
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
