SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So you are using eth0 which probably is a wired connection (can be verified by studying the output from dmesg) and you are getting as good network speed as can be expected on a 1 Gb/s network connection.
My guess is that your complaint might be related to your internet connection. Do you know for sure that you have bandwidth problems with internet or could it be that you have latency problems, maybe related to slow DNS lookups?
If you are waiting long for something like a DNS lookup that can be shown in the output of:
Try plugging your network cable into the other socket and reboot.
I've tried using both ethernet connections available to this desktop, but they are both showing the same slow results
Quote:
Originally Posted by henca
So you are using eth0 which probably is a wired connection (can be verified by studying the output from dmesg) and you are getting as good network speed as can be expected on a 1 Gb/s network connection.
My guess is that your complaint might be related to your internet connection. Do you know for sure that you have bandwidth problems with internet or could it be that you have latency problems, maybe related to slow DNS lookups?
If you are waiting long for something like a DNS lookup that can be shown in the output of:
Code:
strace -f -t -T ping -c 1 www.google.com
regards Henrik
Code:
PING www.google.com (142.250.81.228) 56(84) bytes of data.
64 bytes from lga25s74-in-f4.1e100.net (142.250.81.228): icmp_seq=1 ttl=58 time=19.1 ms
--- www.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.094/19.094/19.094/0.000 ms
Seems like okay speeds for the DNS lookup. I know for certain the internet connection allowed for this device is being throttled somewhere, but the internet connection itself is fine. Other connected devices to the router do not have this problem.
The only thing I can think of is this desktop is connected to a VLAN, something I set up a couple of months ago. The router is a mikrotik that's handling the VLANs and so far it's worked well except for this case. The desktop is wired into a dumb Netgear switch that is not capable of handling VLANs so the router is marking the port this switch is connected to as untagged. Does this shed any light to anyone providing assistance in the matter? From my understanding Linux is pretty strict when it comes to VLANs and I can't help but wonder if this is the issue. Being that the port this desktop and switch is connected to is untagged I should not need to make any changes in Linux to be able to use this port right?
Hmmm. If there is a vlan involved in your network, as root run iwconfig. Look for PowerManagement. It should be off. If it is on, you'll need to add something in /etc/NetworkManager/conf.d that runs this bit of script:
# File to be place under /etc/NetworkManager/conf.d
[connection]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
wifi.powersave = 2
I ran into this problem a few weeks ago about the time that I had to switch to wifi to connect my network boxes at home, and when I did that, a ping time to something on the network ranged from 45 to over 200 ms, which it really bad. A bit of sluthing on the net found the code snippet.
PING www.google.com (142.250.81.228) 56(84) bytes of data.
64 bytes from lga25s74-in-f4.1e100.net (142.250.81.228): icmp_seq=1 ttl=58 time=19.1 ms
--- www.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.094/19.094/19.094/0.000 ms
Seems like okay speeds for the DNS lookup.
The above shows that once you have done the DNS lookup you get a decent latency. However, the interesting part to see would have been how long time it would take to perform the DNS lookup which the (rather big) output of strace would have shown. When I run the suggested command on my system I get:
In the example above I ran the command as root to be able to successfully perform the ping, the icmp in ping will not be allowed when run together with strace as a normal user. However, even when running as a normal user you will be able to see the time a DNS lookup takes. In my example above, the ping itself showed 4.6 ms which is rather decent and you get slightly worse results with your 19.1 ms.
The timestamps to the left above shows when each call was started, the times to the right show how long time each call took. If so you wish, you can have better resolution on the timestamps to the right if you run "strace -tt" instead of "strace -t".
At row 99 above you can see that my system connects to my internal caching DNS server 192.168.43.3 and that only took 0.000009 seconds.
At row 101 a question about www.google.com is sent to the DNS server, sending that question took 0.000010 seconds.
At row 102 a reply is received, getting that reply took 0.000441 seconds.
I repeat those rows again to make it easier to read:
If you want to know why the ping package takes longer time for you traceroute is a good command:
Code:
nazgul:~> traceroute www.google.com
traceroute to www.google.com (172.217.21.164), 30 hops max, 60 byte packets
1 trollet.lkp.se (192.168.43.1) 0.217 ms 0.259 ms 0.257 ms
2 dd-wrt (192.168.67.1) 0.587 ms 0.816 ms 0.972 ms
3 10.4.255.252 (10.4.255.252) 2.832 ms 3.225 ms 3.224 ms
4 10.2.253.1 (10.2.253.1) 2.843 ms 2.888 ms 2.934 ms
5 10.1.254.245 (10.1.254.245) 3.274 ms 3.273 ms 3.323 ms
6 62.119.101.241 (62.119.101.241) 3.369 ms 3.097 ms 3.135 ms
7 ti3163c360-ae67-0.ti.telenor.net (146.172.20.250) 5.715 ms 3.922 ms 4.208 ms
8 ti3002b400-ae3-0.ti.telenor.net (146.172.105.57) 4.383 ms 4.384 ms 4.430 ms
9 148.122.10.54 (148.122.10.54) 4.990 ms 5.109 ms 5.162 ms
10 * * *
11 142.251.48.38 (142.251.48.38) 7.749 ms 142.251.48.40 (142.251.48.40) 5.948 ms 142.251.65.80 (142.251.65.80) 6.864 ms
12 142.250.56.92 (142.250.56.92) 5.940 ms 108.170.233.10 (108.170.233.10) 4.963 ms 142.250.56.92 (142.250.56.92) 4.468 ms
13 192.178.73.203 (192.178.73.203) 5.852 ms 5.900 ms 142.251.250.251 (142.251.250.251) 4.525 ms
14 fra07s64-in-f164.1e100.net (172.217.21.164) 4.994 ms 108.170.233.41 (108.170.233.41) 6.192 ms arn11s03-in-f4.1e100.net (172.217.21.164) 5.163 ms
In my case above I can see that the big time addition (3.224 ms) is at my fibre connection between my outer firewall (dd-wrt) and my ISP internal network (10.4.255.252).
Could your VLAN configuration be a problem? Perhaps if you have configured your /etc/resolv.conf to use a DNS server on another VLAN which you are unable to reach. Any unreachable DNS server listed in /etc/resolv.conf will make DNS lookups slower.
not much of a difference with this change unfortunately
Quote:
Originally Posted by jkh2cpu
Hmmm. If there is a vlan involved in your network, as root run iwconfig. Look for PowerManagement. It should be off. If it is on, you'll need to add something in /etc/NetworkManager/conf.d that runs this bit of script:
# File to be place under /etc/NetworkManager/conf.d
[connection]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
wifi.powersave = 2
I ran into this problem a few weeks ago about the time that I had to switch to wifi to connect my network boxes at home, and when I did that, a ping time to something on the network ranged from 45 to over 200 ms, which it really bad. A bit of sluthing on the net found the code snippet.
HTH.
unfortunately my WiFi NIC is not even showing up - another mystery I'll have to look into solving once I get this wired issue resolved.
Quote:
Originally Posted by henca
The above shows that once you have done the DNS lookup you get a decent latency. However, the interesting part to see would have been how long time it would take to perform the DNS lookup which the (rather big) output of strace would have shown. When I run the suggested command on my system I get:
In the example above I ran the command as root to be able to successfully perform the ping, the icmp in ping will not be allowed when run together with strace as a normal user. However, even when running as a normal user you will be able to see the time a DNS lookup takes. In my example above, the ping itself showed 4.6 ms which is rather decent and you get slightly worse results with your 19.1 ms.
The timestamps to the left above shows when each call was started, the times to the right show how long time each call took. If so you wish, you can have better resolution on the timestamps to the right if you run "strace -tt" instead of "strace -t".
At row 99 above you can see that my system connects to my internal caching DNS server 192.168.43.3 and that only took 0.000009 seconds.
At row 101 a question about www.google.com is sent to the DNS server, sending that question took 0.000010 seconds.
At row 102 a reply is received, getting that reply took 0.000441 seconds.
I repeat those rows again to make it easier to read:
If you want to know why the ping package takes longer time for you traceroute is a good command:
Code:
nazgul:~> traceroute www.google.com
traceroute to www.google.com (172.217.21.164), 30 hops max, 60 byte packets
1 trollet.lkp.se (192.168.43.1) 0.217 ms 0.259 ms 0.257 ms
2 dd-wrt (192.168.67.1) 0.587 ms 0.816 ms 0.972 ms
3 10.4.255.252 (10.4.255.252) 2.832 ms 3.225 ms 3.224 ms
4 10.2.253.1 (10.2.253.1) 2.843 ms 2.888 ms 2.934 ms
5 10.1.254.245 (10.1.254.245) 3.274 ms 3.273 ms 3.323 ms
6 62.119.101.241 (62.119.101.241) 3.369 ms 3.097 ms 3.135 ms
7 ti3163c360-ae67-0.ti.telenor.net (146.172.20.250) 5.715 ms 3.922 ms 4.208 ms
8 ti3002b400-ae3-0.ti.telenor.net (146.172.105.57) 4.383 ms 4.384 ms 4.430 ms
9 148.122.10.54 (148.122.10.54) 4.990 ms 5.109 ms 5.162 ms
10 * * *
11 142.251.48.38 (142.251.48.38) 7.749 ms 142.251.48.40 (142.251.48.40) 5.948 ms 142.251.65.80 (142.251.65.80) 6.864 ms
12 142.250.56.92 (142.250.56.92) 5.940 ms 108.170.233.10 (108.170.233.10) 4.963 ms 142.250.56.92 (142.250.56.92) 4.468 ms
13 192.178.73.203 (192.178.73.203) 5.852 ms 5.900 ms 142.251.250.251 (142.251.250.251) 4.525 ms
14 fra07s64-in-f164.1e100.net (172.217.21.164) 4.994 ms 108.170.233.41 (108.170.233.41) 6.192 ms arn11s03-in-f4.1e100.net (172.217.21.164) 5.163 ms
In my case above I can see that the big time addition (3.224 ms) is at my fibre connection between my outer firewall (dd-wrt) and my ISP internal network (10.4.255.252).
Could your VLAN configuration be a problem? Perhaps if you have configured your /etc/resolv.conf to use a DNS server on another VLAN which you are unable to reach. Any unreachable DNS server listed in /etc/resolv.conf will make DNS lookups slower.
regards Henrik
I am using AdGuardHome as a DNS server, which is reachable from this Slack machine. I've even tried disabling that and using Google's 8.8.8.8 and while the ping and traceroute results are much better, the speed of the connection is still lacking. While DNS resolution may be slower with AdGuardHome, that should not affect download speeds? Once the DNS is resolved for a download it should not matter from what I understand, or am I incorrect here?
I am using AdGuardHome as a DNS server, which is reachable from this Slack machine. I've even tried disabling that and using Google's 8.8.8.8 and while the ping and traceroute results are much better,
Did ping and traceroute give shorter latency by switching to another DNS server? The DNS server should not affect those values.
It would be nice to see such numbers both from your slow machine and some good working machine.
Quote:
Originally Posted by dimm0k
While DNS resolution may be slower with AdGuardHome, that should not affect download speeds? Once the DNS is resolved for a download it should not matter from what I understand, or am I incorrect here?
No, thats right, once the IP address has been resolved your choice of DNS server should not affect the download speed.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.