Xposed-NetworkSpeedIndicator
Xposed-NetworkSpeedIndicator copied to clipboard
chiehmin
Can it ignores the lo traffics?
When I use ShadowSocks, it will also collect the lo interface's traffic. Can the software ignores the lo interface?
Like this, only the wlan0 interface is the valid internet traffic
root@D6503:/ # ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:393592 errors:0 dropped:0 overruns:0 frame:0
TX packets:393592 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:430081434 (410.1 MiB) TX bytes:430081434 (410.1 MiB)
wlan0 Link encap:Ethernet HWaddr 44:D4:E0:82:8C:87
inet addr:192.168.1.18 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::46d4:e0ff:fe82:8c87/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:150874 errors:0 dropped:485 overruns:0 frame:0
TX packets:114157 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:211721446 (201.9 MiB) TX bytes:8636489 (8.2 MiB)
What do you mean by ShadowSocks? Anyway I can't find a way to gather statistics for a specific interface. If you can find one, please pitch it forward!! :smile:
shadowsocks will use the lo interface to forwarding network traffic, and this software will collect it too.
This is a common problem when using any app or function that uses the lo interface. Not related to ShadowSocks itself. As said, I haven't found a way to filter out the loopback interface.
maybe look at this , it's ture speed. https://play.google.com/store/apps/details?id=com.internet.speed.meter.lite
#93 is duplicate of this.
It may be possible to exclude the lo interface by reading the actual stat files:
/sys/class/net/lo/statistics/tx_bytes
/sys/class/net/lo/statistics/rx_bytes
Any idea how to actually read and parse these files and read them in Java? But I think it might be horribly inefficient to do this, maybe not even possible at all, since TrafficStats itself uses native C to read the statistics.
See http://agolovatyuk.blogspot.com/ncr/2012/04/android-traffic-statistics-inside.html
So I tried the above, and it seems to work... in a way. It seems to exclude the lo traffic, but in my device there was only 31597 bytes lo traffic both ways since boot and it never changed after that. I don't see any obvious inefficiency, but we can strike out the impossibility.
See commit below for actual code doing this. Comments and suggestions for a better way to do this most welcome.
Is there any simple app that I can use to jack up the lo traffic and see if it makes any difference? Or any volunteers to test?
@codexss Here it is
When testing, enable logging for a while when you increase the lo traffic. Then send the generated log file. You can disable logging after that.
It's seems not, here is log
http://paste.ubuntu.com/10483351/
As per the log, it is filtering out the increasing lo traffic, so the original intention to ignore the lo traffic is working.
D/2015-03-01 16:30:17/0 total: 16440969, lo: 13705297
D/2015-03-01 16:30:17/1 total: 39329404, lo: 13705297
D/2015-03-01 16:30:17/2725311,2735672;25458843,25624107;208219,209225;10299,164278
D/2015-03-01 16:30:18/0 total: 16444520, lo: 13707672
D/2015-03-01 16:30:18/1 total: 39332358, lo: 13707672
D/2015-03-01 16:30:18/2735672,2736848;25624107,25624686;209225,210241;1157,569
D/2015-03-01 16:30:19/0 total: 16453655, lo: 13711527
D/2015-03-01 16:30:19/1 total: 39338466, lo: 13711527
D/2015-03-01 16:30:19/2736848,2742128;25624686,25626939;210241,211252;5222,2228
Can you say why you think it's not working?
Btw, the screenshot is just a download of the speed test app. It's not an actual speed test.
Contrast that with another app, I look at it over a period of time, thanks to the developer
I put the upload and download figures in some charts and I can tell that that the lo traffic is being excluded correctly. It is still accounting for all other network interfaces that are active.
This is the upload chart. The blue line is the total upload bytes (since boot) and the red one is the lo traffic (since boot).
As you can see, they are pretty close together and most of the total traffic is lo traffic, which is filtered out (and hence your upload speed will not dramatically increase due to loopback when you're downloading something).
This is the download chart. Here you can see that lo traffic is only about one-third of the total traffic. The rest comes from whatever download you were doing during the time of logging.
To me this is correct and how it should be. Evidently, your screenshot shows that this app's upload speed report is just 34 KB/s while the download speed is 1.4 MB/s (because you're downloading the speedtest app for installation).
I'm not sure what app is showing 697 KB/s and how it came up with that figure. :smile:
It's still have problem at shadowsocks vpn mode ,but it's works at shadowsocks nat mode.
What does it do in VPN mode? I suspect it creates a new network interface for the VPN and this traffic is included, while the native mode uses the loopback lo interface. I think this is the best that can be done by me. We need someone more knowledgeable to provide hints about this, but I'll include this in the next release.
I may have to change the approach to only counting a limited set of valid interfaces (such as ethernet and wifi) instead of excluding a non-exhaustive set of invalid interfaces (such as proxy loopback lo and tunnel devices).
Would that work?
left is the output of ip a when shadowsocks enabled, and right is when shadowsocks disabled.
On my device, it add a interface named "tun0".
@nagae-memooff tun0 is on not rooted android 5.0+ devices when using vpn mode. If you are using 4.4 or lower or using shadowsocks with root permission, it will use iptables to forward the network transport.
@wzhy90
my device is already rooted.
on 5.0+ devices, shadowsocks will use VPN mode by default, and the NAT mode is hidden and deprecated.
SO, if we want a more accurate net speed rate, not only lo but also tun0 should be excluded, I think.