THold current values still a mystery

[bl243]

Hi,

I am trying to set a 900Mbps threshold on traffic in and traffic out graphs. I don't understand the threshold current numbers. They are in orders of magnitude higher than the data I am seeing.

For example on a graph with an inbound current value of 10.45Mbps I get a current value reported by threshold of 696753306271.18.

Even if this is in bits, it is still massively too large:
696753306271.18 / 1000 / 1000 = 696753Mbps??

If its in bytes then its way off:
696753306271.18 / 8 / 1000 / 1000 = 87094Mbps??

I am using 64-bit counters, does this cause a problem? What is the correct math for converting this current value into Mbps?

Cheers,
Ben

[cigamit]

I will have to look into the 64 bit counters to see if they are causing the issues.

[jwheeler]

I was hoping to see an answer here as I am seeing the same thing?

[ispeed]

Me too, I don't understand thold's 'current value' for traffic at all.

I have a device with one datasource, monitoring traffic. When I first added it the number was huge, orders of magnitude higher than the current traffic. Then within one poll it refreshed itself to be within the order of magnitude, but no number that made sense given the current traffic value given on the graph.

Then one more refresh down, and it is an absurdly low number. I just don't understand it at all. I will add thresholds for a few more cable modems here and post their results on each poll, maybe that will be helpful.

I am not (as far as I know) using 64 bit counters.
The graphs are correct.

[ispeed]

Ok, I have some details.

I have attached the traffic graph for the data I am about to give. I picked a cable modem that isn't really in use much right now so there is just a solid downstream of about 17-19 kilobits per second. The graph type is interface traffic bits/sec.

On the first poll the "Current value" is: 8888.7067
On the second poll the "Current value" is: 3.7267
On the third poll the "Current value" is: 63.9967

I am not sure why the first one is always so high, but maybe it needs 2 numbers to start taking a reading. By the second reading it is already far too low for any number I can try to reconcile with the 'current' number displayed on the graph. Or any other number on there. Then the third up again (with no changes really in the target graph). A very very minor bump perhaps. (You can see this on my attached graph)

Could it be indicating the change in bits/sec or bytes/sec since the last reading? This would almost make sense (tiny bump) but the thing is barely in use so the lines are fairly solid.

No CDEFs were applied to the threshold.

Any ideas anyone ?

EDIT: I'm seeing in the php some references to the current value and looking how it is calculated:

$currentval = $item[$t_item['name']] - $t_item['oldvalue']; Or other ways depending on the type. Could it be using the wrong calculation for a bandwidth type?

[ispeed]

Like here, does this make sense to anyone ?


Current_value and the graph are very clearly at odds. Almost 10mbit for the graph and 633128 for the current value. How could it get it so wrong?

[doh!nut]

I suppose this won't help anyone as such, but can I say "me too". From what I've noticed it seems to be off by a factor of (about) 10. In a moment of madness I thought that the solution was just to set a CDEF to multiply by 1024, but then my brain flickered again (happens sometimes) and I realised I was clearly stupid!

This is on latest 4.1 thold with 0.8.7d Cacti; 32 bit counters on a "with 95th" graph template.

[cldeluna]

I've been seeing this issue as well (order of magnitude) and I've also noticed the large discrepancy in the first poll vs the next one.

Are there further discussions around this?

Using CactiEZ Version 0.8.7c

Thresholds
Directory: thold
Version: 0.4
Author: Jimmy Conner
Home Page: http://cactiusers.org
Status: Active

Thanks!

[TheWitness]

Jimmy migrated to using the poller_output table instead of using the RRDfiles directly in a recent version. However, there are issues with that. First, there is no baseline on the first poll. That's ok, we can deal with that. Second, the counters can be increasing (heading for a positive overflow), or descending (heading for an underflow). We have to detect if they are increasing or decreasing and then based upon the poller interval, come up with a rate, etc.

This behavior chanbes if it's a COUNTER vs. a GUAGE, and I don't even want to think of how we would handle DERIVE, COMPUTE, etc. I guess, IMHO, some will not be well supported.

As I have not analyzed the code, I will copy Jimmy. It may be a simple bug...

TheWitness

[temak82]

Hi guys,

Any luck with this? I am having the same exact problem. It worked perfectly on our old 0.39 version of Thold, but now we get these out of whack numbers. I'll attach a zip that contains my bytes to mbps CDEF, the Thold Current numbers and the actual Mbps usage after the CDEF is applied in the Data source which is correct.

[syscev]

Hi,

I am trying to set a 900Mbps threshold on traffic in and traffic out graphs. I don't understand the threshold current numbers. They are in orders of magnitude higher than the data I am seeing.

For example on a graph with an inbound current value of 10.45Mbps I get a current value reported by threshold of 696753306271.18.

Even if this is in bits, it is still massively too large:
696753306271.18 / 1000 / 1000 = 696753Mbps??

If its in bytes then its way off:
696753306271.18 / 8 / 1000 / 1000 = 87094Mbps??

I am using 64-bit counters, does this cause a problem? What is the correct math for converting this current value into Mbps?

Cheers,
Ben

I just installed Thold 0.4.1 (cacti 0.8.7d) and using 64bit counters for those graphs above 100M.
When creating the threshold.
1. Under 'Data Manipulation'
2. Set 'Data Type' to 'CDEF'
3. Set 'Threshold CDEF' to 'Turn Bytes to Bits'
4. Configure whatever else you want and save.

The initial polled value will be whacked high but the second one onwards will be normalised. I assume this is a calculation issue when calculating values from SNMP.

See below works fine.

Code: Select all

450000000  	50000000  	5 Minutes  	 	Every 15 Minutes  	341581965.8933  	no

[dlalaina]

Please, someone help me with the attached problem.

Thank you!

[SilverSquirrl]

I know this is an old thread, but there is no answer that I could find, so here is my posting of a possible fix.

I was experiencing this same problem when trying to use cdef. The current reported "correctly" but the last was negative.

I'm no coder, but i did figure out that in the poller.php, line 101 calls for the calculation of current value, referencing "thold_get_currentval" in thold_functions.php, that result was a giant negative number which then gets passed into the switch below and messes up my cdef, resulting in the messed up "last" value.


The following is what I did to fix the problem when it relates to using cdef.

on line 101 in the /include/poller.php file,

Code: Select all

Find:
		$currentval = thold_get_currentval($t_item, $rrd_reindexed, $rrd_time_reindexed, $item, $currenttime);

Code: Select all

Replace with:
		$currentval = get_current_value($t_item['rra_id'], $t_item['data_id'], $cdef = 0);

This resulted in passing the correct "current value" into the cdef function which for me resulted in the proper Percentage of the link that i wanted.

Again, I'm no coder, but I was able to follow the trails which led me to use the same function that is referenced for the "current" display and then figured out which values to pass into it and it worked for me. I don't recommend just apply this to a production system without first testing in a lab of your own.

Here is a picture showing it working on a 10g interface.

cdef cacti fix proof.png (14.08 KiB) Viewed 12278 times

[stevemaximus]

Hi,

I am trying to set a 900Mbps threshold on traffic in and traffic out graphs. I don't understand the threshold current numbers. They are in orders of magnitude higher than the data I am seeing.

For example on a graph with an inbound current value of 10.45Mbps I get a current value reported by threshold of 696753306271.18.

Even if this is in bits, it is still massively too large:
696753306271.18 / 1000 / 1000 = 696753Mbps??

If its in bytes then its way off:
696753306271.18 / 8 / 1000 / 1000 = 87094Mbps??

I am using 64-bit counters, does this cause a problem? What is the correct math for converting this current value into Mbps?

Cheers,
Ben

I just installed Thold 0.4.1 (cacti 0.8.7d) and using 64bit counters for those graphs above 100M.
When creating the threshold.
1. Under 'Data Manipulation'
2. Set 'Data Type' to 'CDEF'
3. Set 'Threshold CDEF' to 'Turn Bytes to Bits'
4. Configure whatever else you want and save.

The initial polled value will be whacked high but the second one onwards will be normalised. I assume this is a calculation issue when calculating values from SNMP.

See below works fine.

Code: Select all

450000000  	50000000  	5 Minutes  	 	Every 15 Minutes  	341581965.8933  	no

I know this is an old post, but being new to cacti, it just saved my bacon! Thanks!!!!

[rbarnhart]

Code: Select all

Find:
		$currentval = thold_get_currentval($t_item, $rrd_reindexed, $rrd_time_reindexed, $item, $currenttime);

Code: Select all

Replace with:
		$currentval = get_current_value($t_item['rra_id'], $t_item['data_id'], $cdef = 0);

So this change in code works for (traffic in), but traffic out reports "current" correctly, however, it is utilizing the (traffic in) data,.. see screen shot: