Hello,

I am hereby forwarding Debian bug: 922427

https://bugs.debian.org/922427

In a nutshell: The initial linear scale of the bandwidth is often much wider than the actual available network bandwidth, leading to bar graphs that are quite narrow. There are existing options like -L and -m that can mitigate the problem but still the initial scaling can assume much more bandwidth than is actually available. Maybe avoiding to resize the scale to more than 120% of the max bandwidth seen, would solve the problem.

Regards,

Markus

Here is the complete bug report for your convenience:

The way iftop calibrates its linear scale, it seems to often make the scale much wider than the actual available network bandwidth, leading to bar graphs that are quite narrow, often 1 character wide or 0 characters wide, for network connections that are pushing relatively a lot of traffic. This makes it not very useful to spotting at a glance what is eating bandwidth.

I generally press L to switch to log scale, which avoids the problem, showing big wide bars.

For example, I've started iftop when the network is nearly completely idle. It picked a scale 1KB-8KB, which is fine. Then I started a download, which ran at 300-615KB/s. This causes the scale to change to 2MB-12MB. Since my wifi connection happens to be limited to around 1MB/s, this guarantees bars will never be more than a few characters wide.

Here's how that displays after downloading for several minutes:

2.38MB 4.77MB 7.15MB 9.54MB 11.9MB └───────────────┴───────────────┴────────────────┴───────────────┴──────────────── darkstar.kitenet.:51000 => kitenet.net:ssh 849KB 6.87KB 5.68KB 5.95KB ### <= 57.7MB 478KB 381KB 410KB ────────────────────────────────────────────────────────────────────────────────── TX: cum: 1.10MB peak: 9.33KB rates: 7.07KB 4.95KB 6.71KB RX: 72.0MB 648KB 466KB 325KB 457KB TOTAL: 73.1MB 657KB 473KB 330KB 463KB

("RX:" is highlighted and I've marked the top highlight using "###".)