brndnmtthws / brndnmtthws/conky
[Bug]: Network speed graphs shared scaling
- Dominant language
- C++
- Stars
- 8.5k
- Forks
- 666
- PR merge metrics
- No merged PRs in 30d
Description
### What happened?
Recent (82bfeba9bf82b4325463842b7ed00de44734e9db) changes to network speed graphs scaling forced uniform scaling for up/down speed graphs (both sharing the same maximum) in order for the graphs to "not appear the same".
Problem with this is that many people have much slower up link than down link which makes the up speed graph look empty (eg reaching only 1/10th of what it could when reaching max speeds) which makes it useless most of the time.
I think people will generally see much more download than upload traffic and its very hard to notice anomalies in upload traffic when eg you are watching youtube/whatever videos most of the time with minimal upload. I understand that we want the widgets to look good and symmetric but in my opinion it shouldn't hurt the usability of what is being shown for actual monitoring.
It also introduces another bug which causes the upspeedgraph (the graph which doesn't contain the max value) to use max value from its own data for 1 update when the max value rolls out of the downspeedgraph - this makes the upspeed graph values appear for 1 update frame and then disappear in next update when the maximum gets updated from the other graph.
Apart from that while I was trying to figure out why my upspeedgraph almost always looked empty I took a quick look at the implementation of this which introduces global variable maxspeedval which seems like it should cover all speed graphs (eg. disk speeds) too but that would of course be very bad as those shouldn't share max value with network (they don't afaik it was just surprising to see this implemented like that). From what I've seen current implementation will also share max between all intefaces if you are monitoring multiple interfaces.
I think this feature should be optional and default behavior should treat every graph separately. And in my personal opinion from what I've seen this feature should be postponed until it is implemented properly.
### Version
conky 1.22.2-pre-49cd8556 compiled for Linux x86_64
### Which OS/distro are you seeing the problem on?
Fedora
### Conky config
```Lua
${upspeedgraph eno2 30,142 804020 a06040} ${alignr}${downspeedgraph eno2 30,142 204080 4060a0}
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by inspecting the network graph scaling changes from commit 82bfeba9bf82b4325463842b7ed00de44734e9db and the upspeedgraph/downspeedgraph entry points. Reproduce the eno2 configuration from the report, then verify that each graph scales independently and that upload, download, disk, and multiple-interface graphs do not share an unintended maximum.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux, lua
- Domain
- observability-sre
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100