Eth0 download not calculated correct


I have a dedi setup with a .nl provider with a fresh debian 8 install on it and the latest Quickbox. I have installed Quickbox on multiple seedboxes before and never encountered any problems, however on this particular box download speeds are not calculated correct, resulting in the actual downloaded amount is way off in the overview and the speed graph.

Is there anything i can do/check to make sure download speeds through eth0 is on the money? Upload seems to be spot on.


It’s possible that it is measuring internal traffic data, i.e; traffic moving from the host to the machine. Additionally, if you are running any rsync processes, acd_cli processes, etc. It will read those stats as well to be traffic on the adapter.

Check it with the vnstat command vnstat -l to ensure that it matches that of the displayed graph on the dashboard. By default vnstat live via cli measures in Mbits, so just keep that in mind when running it for comparisons. More than likely though, there is some sort of internal traffic happening between host and machine; however, this usually happens on l0 and not eth0.

Install the utility called nethogs for further digging. This can be installed with apt-get install nethogs. Then run it with nethogs eth0. This will give you a very clear rundown of what processes are using how much bandwidth.

Thanks for the prompt answer. It does indeed seem like it is monitoring internal traffic on eth0, and the stats being shown on QB dash is the same as vnstat -l is reporting. I cannot get nethogs to run though, even using su nethogs eth0 i get “creating socket failed while establishing local IP - are you root?”

Any other tricks i can try to understand why eth0 would be way off?

Do sudo su and see if you can enter root that way to run nethogs. Or you can type sudo nethogs eth0

Same result unfortunately :confused:

Update: Fixed Nethogs by using this (→-creating-socket-failed-while-establishing-local-ip-are-you-root)

I am not sure what to look for in Nethogs exactly?

FYI eth0 in QB is reporting around 1/5 of what rutorrent is reporting.

Okay. So i have done some more digging, what is really weird is that eth0 in the QB dash reports the correct download numbers, but it does not seems to aggregate correctly in the dash. How can that be? See attached screenshot.

ruTorrent only calculates data processed by the rtorrent daemon, whereas the Dashboard is doing the arithmetic for the total amount of server traffic. Additionally, when you see number peak very high and then dip very low, this is normal behavior of internet traffic on any given server. It’s actually measuring the burst speeds.

I get that. But why is eth0 reporting correct download speeds when the “view addtional bandwith details” pane is reporting completely different values? Are those numbers aggregated differently?

Those numbers are only updated hourly, daily and monthly. I’m not sure what other info I can provide. Are the numbers for total in/out less than that of what the ruTorrent plugin is showing?

Yup, they are completely different, but only for download, upload is right on the money in both instances. Rutorrent reports 185gb downloaded and QB dash reports 17.61gb download. The eth0 live data seems to be spot on though, so i don’t really understand why the aggregation can be off.

Have you done any reboots of the server after install? It’s possible that the vnstat database dump got corrupted and/or reset during a reboot. It’s hard to say without me knowing much about the particular provider you are using for this machine.

Out of curiosity, what is the result of uname -a

Yeah, i have done a couple of reboots after upgrading. uname -a returns Linux zenith 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux

Provider is worldstream btw.

Very possible that is the case. That kernel is a bit old honestly, more than likely they have it there due to some sort of customization on the OS for the provisioning they use.

What available kernels are there for install? Type in…

sudo apt-cache search --names-only linux-image

See if that gives you a list of kernels with something greater than 3.16. The lowest I see on many of the servers I work on is 3.4 with the now standard 4.4 being the ideal update.

Cool. Would make sense. Here is the list. Which kernel should i install and how do i do it?

linux-image-3.16.0-4-amd64 - Linux 3.16 for 64-bit PCs
linux-image-3.16.0-4-amd64-dbg - Debugging symbols for Linux 3.16.0-4-amd64
linux-image-amd64 - Linux for 64-bit PCs (meta-package)
linux-image-amd64-dbg - Debugging symbols for Linux amd64 configuration (meta-package)
linux-image-4.7.0-0.bpo.1-amd64-dbg - Debugging symbols for Linux 4.7.0-0.bpo.1-amd64
linux-image-4.7.0-0.bpo.1-amd64-unsigned - Linux 4.7 for 64-bit PCs
linux-image-4.7.0-1-grsec-amd64 - Linux 4.7 for 64-bit PCs, Grsecurity protection
linux-image-grsec-amd64 - Linux image meta-package, grsec featureset
linux-image-4.7.0-0.bpo.1-amd64 - Linux 4.7 for 64-bit PCs (signed)

It actually looks like on their platform you are using the most readily available kernel. You’ll want to avoid any kernels with grsec compiled as they are a nightmare to systems such as QuickBox.

You can run:

sudo apt-get update
sudo apt-get install linux-image-amd64 linux-headers-amd64

See if that pulls and install any “latest” kernels.

Hmpf. That sucks. Uname -a still returns the same output, so it really didn’t do anything. Maybe i will just have to live with it being off or change my dedi provider :wink:

Thanks for the great support and product, i thoroughly enjoy it!

Oh, the change wouldn’t go into effect for the kernel until after reboot. Assuming it picked up new images.

Rebooted and seems like there was a minimal upgrade Linux zenith 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

Oh wow… minimal indeed. looks like they may had simply updated their base OS with some pre-updates and that’s about it. Do you see anything with the stats on the dashboard changing after the update? less or more.

So i actually managed to get it to update to a backport 4.7. But i do not know whether this is good or bad?

Linux zenith 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.5-1~bpo8+2 (2016-10-01) x86_64 GNU/Linux

Will check if the dash readouts improve.