dstat --net shows continously very high wifi speed values, especially when there is no traffic! about dstat HOT 18 CLOSED

I can't remember discussing this issue though ?

But since we get the numbers from the kernel, I would guess the kernel making mistakes. In fact, 4G seems to be the rollover max, so somehow it feels as if the counters are going backwards when there is no traffic ? Is that possible ?

You can simply try printing the numbers the plugin is using, you can even have the plugin display its values to see what is going wrong... It's just python !

from dstat.

Dag, I am not so familiar with Python, but there is a class net, where I guess the music plays??
Which function exactly calls where the info (from where, from /proc or /sys)?

What I see, is that I use Ubuntu 12.04 plain and newly installed on two machines (I have got time these weeks :-)), on one it shows correctly the number of transmitted bytes (at least it looks like correct), and one, my netbook, an Acer Aspire Timelinex 1810TZ does not show the 0 Byte transmission correctly as shown above!

In the other thread one year ago, you assumed the error to be in the wifi module, but it was neglected because at that time the bug was found somewhere differently....

I am referring to link: #4
even though this was only like an entry point into the topic...

I just wanted to find out if the wifi driver or whatelse is causing the problem....

from dstat.

Could you please do dstat -f --net so that we can find the interface giving you the erroneous numbers ?

If you add --debug you can see what file is being used for the counters. In this case it should report /proc/net/dev.

Next you can do something like: watch -n 1 -d cat /proc/net/dev and see how the counters change. They should not go backwards, but only go forward or stay the same. It would be useful to know what happens in your case as it feels as if the conuters go backwards.

from dstat.

Another possibility that I didn't discuss yet is that time is drifting backwards, which should never ever happen. Do you synchronize your time on your system ? And if so, what method is being used (ntpdate, ntpd, cron, vmware-tools, ...) ?

BTW is this a virtual machine or a physical machine ?

from dstat.

Ok, it seems to be the inactive eth0, only wlan0 is connected!!

$ dstat -f --net --debug 
Module dstat_net requires ['/proc/net/dev']
--net/eth0---net/wlan0-
 recv  send: recv  send
   0     0 :   0     0   2.63ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.60ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
--net/eth0---net/wlan0-
 recv  send: recv  send
4096M 4096M:   0     0   0.61ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.62ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.57ms
4096M 4096M:   0     0   0.66ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.57ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.69ms
--net/eth0---net/wlan0-
 recv  send: recv  send
4096M 4096M:   0     0   0.63ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:  60B    0   0.56ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.59ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.64ms
4096M 4096M:   0     0   0.53ms
4096M 4096M:   0     0   0.53ms
4096M 4096M:  42B    0   0.57ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.57ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.60ms
4096M 4096M:   0     0   0.55ms
--net/eth0---net/wlan0-
 recv  send: recv  send
4096M 4096M:   0     0   0.64ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.58ms
4096M 4096M:   0     0   0.58ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.61ms
4096M 4096M:   0     0   0.57ms
4096M 4096M:   0     0   0.57ms
4096M 4096M:   0     0   0.56ms

from dstat.

In thread4 @bertdb supposed a connection to the kernel ? Than it vanishes! ,

if I disconnect wifi, the errorneous value does not occor to wlan0:
disconnected:

--net/eth0---net/wlan0-
recv send: recv send
4096M 4096M:   0     0   0.58ms
4096M 4096M:   0     0   0.62ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.53ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.52ms
4096M 4096M:   0     0   0.56ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.55ms
4096M 4096M:   0     0   0.54ms
4096M 4096M:   0     0   0.57ms

reconnect again:

4096M 4096M: 872B  935B  0.58ms
4096M 4096M: 511B 2037B  0.56ms

from dstat.

it is a netbook: Acer Timelinex 1810TZ, not a virtual machine!!

from dstat.

lspci:
01:00.0 Ethernet controller: Atheros Communications Inc. AR8131 Gigabit Ethernet (rev c0)

from dstat.

Ok, I see a problem wit atl1c driver, I do not get any connection through eth0, I am sorry to bother you. If I find the problem, I will post the solution, otherwise we can close the case! Thank you for your help!

from dstat.

Ok the following did solve the problem:
$sudo vim /etc/default/grub
changing then
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux acpi_backlight=vendor"

After that do
$sudo update-grub

After that quit and do a reboot to take effect:
$sudo reboot

This will tell the kernel if it asks for acpi that Linux is a supported system and can use acpi.
For some reason acpi works before more or less fine, but disables or makes the driver atl1c to go wrong...

!Not recommended - Use upper described method, if you got the same issue!!
Also
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off"
also works with the big disadvantage of a disabled acpi, that means for example no battery stats and no /proc/acpi

So forget that second change! I only listed it up for completion issues...
!Not recommended - Use upper described method, if you got the same issue!!

from dstat.

Sorry I was too fast, now my ethernet is working, but if it is not connected, the error stays on...

Any more ideas, howto analyze...

from dstat.

Thanks for the detailed reports !

The problem is definitely not caused by dstat, we only report the numbers we get. Can you try my suggestion about using watch -n 1 -d cat /proc/net/dev ? I still expect the counter to go backward by one or more bytes, which is something we have to report to the atl1c driver developers.

from dstat.

Thanks, Dag,

it behaves like you said,the counter goes backward.
Do you know, who should be triggered now? Where to find?

And : actually I am not synchronizing with ntp or anything else. It is a newly installed system.

from dstat.

This is a snapshot of watch -n 1 -d cat /proc/net/dev:

Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packe
ts errs drop fifo colls carrier compressed
lo: 153110 2143 0 0 0 0 0 0 153110 21
43 0 0 0 0 0 0
wlan0: 25881580 20085 0 0 0 0 0 0 1808407 12
968 0 0 0 0 0 0
eth0: 4294901392 4294901393 4294571872 4294835488 4294901392 17179539664
0 4294901392 4294901392 4294901392 4294703680 0 4294901392 4294637776 858
9802784 0

a few seconds later:

Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packe
ts errs drop fifo colls carrier compressed
lo: 153370 2147 0 0 0 0 0 0 153370 21
47 0 0 0 0 0 0
wlan0: 26291313 20400 0 0 0 0 0 0 1826760 13
133 0 0 0 0 0 0
eth0: 4294899194 4294899195 4294558684 4294831092 4294899194 17179528674
0 4294899194 4294899194 4294899194 4294694888 0 4294899194 4294626786 858
9798388 0

from dstat.

By the way: What is the nature of the counter, and why shouldn't it count backwards? What does it do?

from dstat.

Hi Dag,

did you forward the request to the atl1c driver developers?
Because: It seems to be solved since a few days!

If you did do so, I would like to thank you, because I did not have the
time to figure out, how to contact them.

Greetings Peter

from dstat.

Upstream fixed this themselves :-)

from dstat.

Sorry — referenced this issue by accident.

from dstat.