* Tom Feiner (feiner....@gmail.com) wrote: > As matthias mentioned in the upstream ticket you filed, the if_ plugin > in the 1.3 series should do the right thing now.
No, it doesn't. *.max is *still* set to 1,000,000,000, which is wrong. This is a counter since *boot* (or last overflow), not since the last second. Sure, the interface can only do 1Gb per second, but a per-second amount isn't what's being sent to rrdtool. What happens, however, is that *.max is translated to a maximum value that rrdtool will accept, and so it starts throwing away values which are larger than that. Reality is that on a 64bit kernel you're not going to get an overflow until 2^64 (or so), so as soon as you've transferred over 1Gb since booting a system, the if plugin blows up. > Can you check if the latest if_ plugin solves your problem? Ther latest if_ > plugin from the munin trunk can be found at: > http://munin.projects.linpro.no/browser/trunk/plugins/node.d.linux/if_.in As long as *.max is set to what the interface per-second speed is, and *.max translates to the max value for rrdtool, it's going to be busted. rrdtool can generally handle wrap-arounds, it might be as simple as removing the .max settings. Alternatively, have a check to figure out if it's a 32bit or 64bit machine and set the max value based on eight-times 2^32 or 2^64 respectively (since it's reported in bytes anyway by /proc/net/dev...). By the way, because of that, you've actually got around 34 seconds on a gigabit interface which is going at full gigabit speeds before you get a roll-over with 32bit counters. Over 5 minutes with a 100Mbps interface. No clue who came up with the idea to set the max value here to the interface speed, but it's just plain wrong. Thanks, Stephen
signature.asc
Description: Digital signature
