|
|
Post by watercooled on Nov 5, 2015 17:45:22 GMT
I'm just looking at the traffic counters on the status_interfaces.php page. Is this not what the update refers to?
|
|
|
|
Post by Lee Sharp on Nov 5, 2015 17:50:14 GMT
No, but I will look into it.  It is for outside snmp monitoring. |
|
|
|
Post by watercooled on Nov 5, 2015 18:36:11 GMT
Oh OK I misunderstood.
Thanks
|
|
|
|
Post by watercooled on Apr 10, 2016 17:02:55 GMT
Hope you don't mind the thread bump, but have the 64 bit traffic counters made any progress? I understand there are other things that need working on more importantly, but if not, is there anything you'd recommend for a fairly lightweight SNMP client to lag/graph traffic? Ideally something I could run either inside Smallwall or on another headless system. Something able to produce an output like this would be great (I believe this is from pfSense), to get an idea of usage per month as I currently have no real way of logging it: i.imgur.com/V9PtFTV.pngRegards. |
|
|
|
Post by Lee Sharp on Apr 11, 2016 0:12:34 GMT
Lost track of it. Moved to bugs so I can find it again...
|
|
gderf
Junior Member
Posts: 14
|
Post by gderf on Apr 19, 2016 17:23:17 GMT
|
|
|
|
Post by watercooled on Apr 28, 2016 20:48:14 GMT
Cheers I'll give it a go. With regards to the database mangling, how severe is that e.g. does it just miss out a time period from the logs or is it worse than that?
m0n0/Smallwall tend to run for many months at a time for me so it's likely not such a big deal though.
|
|
gderf
Junior Member
Posts: 14
|
Post by gderf on Apr 28, 2016 21:02:43 GMT
Router reboots cause very large negative values to be injected into the IOG database for the one hour period where the router reboot happened. This has the effect of spoiling the output for that hour, that day, and even the entire month if the the monthly total up to that point was small compared to the magnitude of the erroneous data.
I contacted the author about this and he didn't seem terribly interested in fixing it. The code hasn't been updated in nearly 13 years, and the last update was supposed to solve this problem, but apparently not.
MRTG has a similar problem, but it is possible to make adjustments to its database to at least mitigate the damage to be barely noticeable.
|
|
|
|
Post by watercooled on Apr 28, 2016 21:39:45 GMT
I'm not sure if the problem has a similar cause but I've noticed if I'm watching the m0n0/smallwall interface traffic graph when it crosses the ~4GB rollover point it shows a huge negative value for throughput.
Thanks for the heads-up though I'll be sure to keep an eye out for it.
|
|
|
|
Post by Lee Sharp on Apr 28, 2016 23:55:58 GMT
I have a large backlog of patches to put in. I may just have to make a bunch of beta releases as I go... Look for some soon.
|
|
|
|
Post by Lee Sharp on Apr 28, 2016 23:58:24 GMT
MRTG has a similar problem, but it is possible to make adjustments to its database to at least mitigate the damage to be barely noticeable. If you tell MRTG to look at the 64 bit interface counters (that we do support) you can get better traffic graphs. I am not sure if that would work for IOG. |
|
gderf
Junior Member
Posts: 14
|
Post by gderf on Apr 29, 2016 22:53:06 GMT
MRTG has a similar problem, but it is possible to make adjustments to its database to at least mitigate the damage to be barely noticeable. If you tell MRTG to look at the 64 bit interface counters (that we do support) you can get better traffic graphs. I am not sure if that would work for IOG. IOG has always supported 64 bit counters and MRTG has supported their use for almost forever. m0n0wall never supported 64 bit counters and neither did smallwall or t1n1wall at first. But that isn't what causes the spikes. None of this software can differentiate between counter wraps (single or multiple) or counter resets due to router reboots. Google "mrtg spikes" and read some of it. |
|
|
|
Post by Lee Sharp on Apr 29, 2016 23:59:47 GMT
Ooops... I get what you are saying now. With the newly supported 64bit counters in SmallWall we no longer get the counter wraps that we used to, but we still do get reboot resets. But if you set the bandwidth counter to never allow a negative value, it will only spike to zero.
|
|
gderf
Junior Member
Posts: 14
|
Post by gderf on May 2, 2016 16:56:59 GMT
The problem with negative values is that they are not entirely illegitimate and can not be just ignored in all cases. They can show up when a counter does legitimately wrap when the calculated difference between the current reading and last reading could properly be negative. This says that a counter did wrap, or the device was rebooted. But it can't say how many times it wrapped or rebooted. Thus an assumption has to be made. This is one of the reasons this problem has never been really solved, and likely won't be solved unless wraps and reboots are tracked and recorded elsewhere (off device).
MRTG's database can be told to ignore overly large values, but doing so can also hurt accuracy if discarded values were in fact legitimate.
No idea why IOG is still broken, even after allegedly being fixed. Maybe a perl wizzard can look it over. The author seemed disinterested.
|
|
|
|
Post by Lee Sharp on May 2, 2016 18:07:30 GMT
This is an "every dog has flees" moment. The truth is that wrapping, which is an expected event, is not "expected" by the monitoring software, so you have to decide which wrong behavior you prefer. |
|
It is for outside snmp monitoring.