Hello everyone,
We are working implementing the new rate calculation methods in an old connector (NuGet Gallery | Skyline.DataMiner.Utils.Rates.Protocol 1.0.0.5), but for some reason we are getting some negative rate results:
",
We suspect that this is due to wraparounds that normally happen when counters reach the maximum UInt32 value in this case, as you can see in the rate data stored:
{
"bufferedDelta": "00:00:00",
"rateOnTimes": {
"minDelta": "00:00:30
"maxDelta": "00:10:00",
"counters": [
{
"TimeSpan": "00:05:20.3550000",
"Counter": 3447138410 (previous value)
},
{
"TimeSpan": "00:06:00.0700000",
"Counter": 2730053612 (currentvalue)
}
],
"RateBase": 0
}
}
I understood that these classes/methods already had the required logic to handle this cases automatically, but I'm not sure about it now.
Could any one help me with this?
In case any other detail is required, let me know.
I'm not a 100% aware of exact numbers, but negative rates have been added as an option in the Rates nuget as a result of multiple cases where devices can have decreasing counters. I believe the code has logic to decide which case is more likely (an overflow, which would lead to a positive rate or the counter going down, meaning a negative value). I also believe this is done by checking which of the 2 cases has the smallest absolute difference.
Let's assume a counter that goes to 5. When the last value is 4, and the new value is 3, it will take the smallest difference (-1 instead of +4).
This should make sense since we don't expect a counter to increase with more than half it's value over the duration of calculation window, otherwise how can we be sure the counter did not do multiple overflows instead of just 1. If a counter goes really fast, it's rate should be calculated more frequently. If this is not possible because of the device setting or other reasons, I'm not sure if there is an option to turn off negative calculations as a whole if you are sure the counters only increase (otherwise this could be requested)