rwasef1830
commented
2 years ago A pattern like this usually means that your snmp counter is slow in updating and your polling interval is too short, so by the time we ask again for how many bytes were transferred since the last time we asked, the counter didn't change, so the rate is calculated as 0. I had to modify my router's firmware to patch net-snmp to disable caching of the interface snmp tables so that the counter updates instantly instead of every 3 or 5 seconds.
I considered implementing some kind of auto-guessing or auto-correction of the poll interval in case that situation happened, but I didn't get the time to do it.
How that could possibly work, is that we would ask the router once and measure how long it took to respond. Then we start asking quickly in succession with increasing interval in multiples of this interval until we stop getting a complete 0 reading (or something like that). It would probably need some tuning and adjustment to work correctly in different network conditions.
I watch a lot of video livestreams and it seems that the way they transfer data is in small groupings of data, not in a continuous connection because the bandwidth graphs look like this, see below. One second i would look at the deskband and it would be 15.7 Mbps, and the next second it would be 0.0 Mbps and so on. I've used your MonBand for awhile but i remember that some other software adds a bit of a delay before the current bandwidth speed decays back to zero thus creating a bit of a smoother graph. I suggest a user option thats off by default which would artificially make the graph a bit more fluid. Maybe something like "decay rate in X ms". I know that would essentially make the bandwidth monitor less accurate but what can i say, i just like a prettier graph and i dislike seeing 0.0mbps when i am clearly watching a network intensive livestream. Just an idea, thanks for this useful tool, i love it.