I used this guide to achieve what I want: http://wiki.mikrotik.com/wiki/Graphing_Client_Signal_Strength which was to graph initiator signal strength/remote signal strength/initiator noise/remote noise of 16 Proxim Tsunami’s. It’s all working well, but when for what ever reason they can’t get an SNMP reading, the charts appear to default for 0.
Is there a way with a function/something that I can make it use the last reading rather than defaulting to 0? I’m not interested in the spikes, I’m looking for trends over weeks rather than minutes.
The only way I could think to do this is to increase your cache time longer than your retry interval, Simple to test but may not give desired result. While you are at it set the negative cache lower than your retry interval.
If you read how the function OID works you will find that it has a cache value and a negative cache value. So maybe you poll every 30 seconds? Then set the cache value to 60 seconds or maybe even 90 but still poll every 30. That way the last good reading should still be cached. I just don’t know if it will “re-cache” the cache value. The negative cache value is not “re-cached”.
Also you might want cache value to be one second less than your retries. So if you are polling 3 times in 30 seconds use 89 and 29 for cache and negative cache respectively.
if(oid(“1.3.x.x.x.x.x”,89,29)<>“”, “”, “failed”)
You might try to be tricky by putting different cache and negative cache times on the Error and Value entries.
Error: if(oid(“1.3.x.x.x.x.x”,10,29)<>“”, “”, “failed”)
Value: oid(“1.3.x.x.x.x.x”,89,29)
I don’t know what would happen here either…
This is probably a really noobish question, but where for the life of me do I find information on the functions? I did try and find out more information on the oid() before trying this.
I do poll every 30 seconds, so I changed the datasource on one of the devices signal strength to a function with the following:
If you check the attached file, the blue line is the one with that function, the rest are just set to snmp oid. When it dips right off, that’s when I was setting it, and you can see to the right when I wasn’t able to get a reading. The stats that are still snmp oid defaulted to 0, where as this new function did a kinda up and down thing, which is good, as that’ll average itself out perfectly. I haven’t tested an extended outage, although in theory I shouldn’t have one.
Open up the functions list and on each built in function the description is contained there…
Like the if function description “first parameter - condition, second - returned if condition yields logical true, third - returned otherwise”
You will find some extended things in some functions do not work… like the 5th parameter in OID or something like that… forget now
Anyhow you wont know for sure with out a few days of testing.
That little up/down on the right is a timing error and a strange one, They are usually down then up… Where a read is not made in time to add it to the correct point in the graph. EDIT oh right you are reading a negative value… so the up down is the same as reading a positive value just reversed. And yes it is clear that it might have worked compared to the other probes…
That cache value and negative cache value is not factory so remember that you are out of spec with some of your probes
I run 10, 29 for cache and negative cache on all the probes I modify to eliminate false positives. The problem could simply be the default negative cache time of 300 seconds. There is a bug/feature when a device fails the first read it will fail all subsequent reads for the next 300 seconds. That is why a negative cache of 29 is much better. The experimental caching for a long time to hold a previous value is extremely experimental so make sure you post back with your results . And you could just try a normal cache time and 29 negative cache if your graphing goes haywire
have you an idea how to fix this. I have tried to change the cache time but the negativ Spikes allways appaers, I think this is allways when the SNMP counter is full and go to the begin.
