Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] smoother bandwidth monitoring #2

Open
Doosty opened this issue Jan 29, 2022 · 1 comment
Open

[Suggestion] smoother bandwidth monitoring #2

Doosty opened this issue Jan 29, 2022 · 1 comment

Comments

@Doosty
Copy link

Doosty commented Jan 29, 2022

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.

example

@rwasef1830
Copy link
Owner

rwasef1830 commented Jan 29, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants