snmp bug

johnpoz

@lukecage still not seeing anything here other than a 2 watch problem.. Which one is correct?

Maybe your mikrotik smooths the data more than tnsr. Maybe its a difference in whatever your using to graph that, and its polling, or smoothing settings.

Even if using settings same, take reading every 2 seconds and average last 30 seconds.. if they are not looking at the data at exact same time your going to see differences..

If you don't like the data your seeing because it doesn't "match" up exactly with some other system doesn't mean there is a snmp bug.. These are 2 different systems.. 2 different OSes, 2 different nics I assume, 2 different drivers, etc. etc..

Looking at your graphs to me - just looking like one is smoothing more than the other. Or sample time slightly off.. I see increase in data that lines up with increase in data on the other one, I see area that could just be different smoothing applied

jimp

It could also be a difference in how the two handle the data. For example the Mikrotik may be taking longer to process things and queuing up traffic, where TNSR is pushing it out as soon as it gets it.

The totals are so close I find it hard to believe there is a problem with the data.

There are also statistics available via prometheus, which you could try logging instead of SNMP, to see if that makes a difference.

LukeCage

@johnpoz

still not seeing anything here other than a 2 watch problem.. Which one is correct?
mikrotik device showing true data

On the tnsr side, there are too many graphic defects

i tried to install a new tnsr and get data
dont have any problem https://prnt.sc/26d8tzs

why i living this problem my main tnsr router i dont know
https://prnt.sc/26d8ugs

both tnsr working on reading every 30 seconds

note: my traffic is progressing stable, as in the screenshot I mentioned on the tnsr side, there is an imbalance in my traffic.

LukeCage

i changed scanning interval on both devices

tnsr -> 30 seconds to 60 seconds
mikrotik 30 seconds to 5 seconds

i will share results with you in 40-50 minutes

jimp

I'm not seeing any defects, just differences in how the traffic is being processed at higher volumes in your environment.

TNSR uses VPP which does vector processing which handles multiple packets at the same time, most other things process only one packet at a time (scalar processing). So it makes sense that it would handle large chunks of traffic at once (the peaks) as they come in.

https://wiki.fd.io/view/VPP/What_is_VPP%3F