hey there- anyone ever seen a bug in sar where it will start spitting out incorrect values? we're running on 32bit intels. an example: 06:40:13 PM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s 06:40:18 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 06:40:18 PM eth0 307775.86 390641.38 66821927.59 460472182.76 0.00 0.00 0.00 06:40:18 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 06:40:18 PM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 i know for a fact I'm not pushing out 3.4Gb over my 1Gb card- the box has been up for over 600 days and does streaming radio, so it pushes a lot of bits/lots of packets my questions are: 1) doesnt sar just pull directly from /proc/net/dev? i looked at the values in it, and none of the values exceeded 32bit. my initial thought was maybe the counters for /proc/net/dev were exeeding 32bit, or used 32bit unsigned, and sar was using a 32 bit signed, so it was freaking out, but the values in /proc/net/dev that i saw hadnt even exeeded 32bit signed. on top of that, we have a couple other tools that pull metrics directly off of /proc/net/dev, and those aren't having any issues- because of this, we're now relying off of those tools INSTEAD of sar. 2) which leads me to, at what point to the counters for /proc/net/dev get reset? when they've reached either 32bit unsigned or 64bit unsigned, depending on the architecture, or? a few of the people at work say it has to do with a counter rollover bug related to SAR because the box has been up for so long, but i'm trying to figure out what the bug actually is, if there is one. again, the tools we have that pull data directly from /proc/net/dev are still working normally.. it's just sar that we're having issues with. probably not a good thing :D i'm running the latest sysstat package (sysstat-5.0.5-16.rhel4) that came down from our rhn satellite servers. let me know if anyone has any input. thanks! chet /* Chet Nichols III mail: <a href="mailto:chet.nichols@gmail.com">chet.nichols@gmail.com</a> (aim: chet / twitter: chet) */