hi, I’m having a significant decrease in the speed of my internet. I have 3MB and the speed reported by speedtest.net goes around 1.4 MB while if I go to my ‘gaming’ partition that has XP, the same page reports 2.9 MB.
I don’t have any background service that uses the internet such as automatic updates or any other service like the desktop search, all desktop effects are turned off.
I use OpenSuse 12.3, KDE 4.10.5
Suggestions ?
On 08/06/2014 09:56 AM, mhunt0 wrote:
>
> hi, I’m having a significant decrease in the speed of my internet. I
> have 3MB and the speed reported by speedtest.net goes around 1.4 MB
> while if I go to my ‘gaming’ partition that has XP, the same page
> reports 2.9 MB.
>
> I don’t have any background service that uses the internet such as
> automatic updates or any other service like the desktop search, all
> desktop effects are turned off.
>
> I use OpenSuse 12.3, KDE 4.10.5
You need to report your net device and driver before anyone can offer any
suggestions.
right. This info:
1: PCI 20c.0: 0200 Ethernet controller
[Created at pci.319]
Unique ID: rBUF.rbKoCKmo5xF
Parent ID: 6NW+.eDbWAYN5SdB
SysFS ID: /devices/pci0000:00/0000:00:1e.0/0000:02:0c.0
SysFS BusID: 0000:02:0c.0
Hardware Class: network
Model: “3Com 3c905C-TX/TX-M [Tornado]”
Vendor: pci 0x10b7 “3Com Corporation”
Device: pci 0x9200 “3c905C-TX/TX-M [Tornado]”
SubVendor: pci 0x1028 “Dell”
SubDevice: pci 0x010d
Revision: 0x78
Driver: “3c59x”
Driver Modules: “3c59x”
Device File: eth0
I/O Ports: 0xd880-0xd8ff (rw)
Memory Range: 0xff6ff800-0xff6ff87f (rw,non-prefetchable)
Memory Range: 0xff700000-0xff71ffff (ro,non-prefetchable,disabled)
IRQ: 18 (119191 events)
HW Address: 00:06:5b:01:66:51
Link detected: yes
Module Alias: “pci:v000010B7d00009200sv00001028sd0000010Dbc02sc00i00”
Driver Info #0:
Driver Status: 3c59x is active
Driver Activation Cmd: “modprobe 3c59x”
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #16 (PCI bridge)
On 08/06/2014 01:26 PM, mhunt0 wrote:
>
> right. This info:
>
> 1: PCI 20c.0: 0200 Ethernet controller
> [Created at pci.319]
> Unique ID: rBUF.rbKoCKmo5xF
> Parent ID: 6NW+.eDbWAYN5SdB
> SysFS ID: /devices/pci0000:00/0000:00:1e.0/0000:02:0c.0
> SysFS BusID: 0000:02:0c.0
> Hardware Class: network
> Model: “3Com 3c905C-TX/TX-M [Tornado]”
> Vendor: pci 0x10b7 “3Com Corporation”
> Device: pci 0x9200 “3c905C-TX/TX-M [Tornado]”
> SubVendor: pci 0x1028 “Dell”
> SubDevice: pci 0x010d
> Revision: 0x78
> Driver: “3c59x”
> Driver Modules: “3c59x”
> Device File: eth0
> I/O Ports: 0xd880-0xd8ff (rw)
> Memory Range: 0xff6ff800-0xff6ff87f (rw,non-prefetchable)
> Memory Range: 0xff700000-0xff71ffff (ro,non-prefetchable,disabled)
> IRQ: 18 (119191 events)
> HW Address: 00:06:5b:01:66:51
> Link detected: yes
> Module Alias: “pci:v000010B7d00009200sv00001028sd0000010Dbc02sc00i00”
> Driver Info #0:
> Driver Status: 3c59x is active
> Driver Activation Cmd: “modprobe 3c59x”
> Config Status: cfg=no, avail=yes, need=no, active=unknown
> Attached to: #16 (PCI bridge)
That is an old driver, and it should be running at full speed. You can see the
settings with 'ethtool eth0". In particular, check for half duplex, or 10 Mpbs.
it says it supports those modes, but apparently set up at Duplex:Full:
Settings for eth0:
Supported ports: TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 24
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x00000001 (1)
drv
Link detected: yes
linux-h4yw:~ #
On 08/06/2014 03:26 PM, mhunt0 wrote:
>
> it says it supports those modes, but apparently set up at Duplex:Full:
>
>
> Settings for eth0:
> Supported ports: TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
>
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 24
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Current message level: 0x00000001 (1)
> drv
> Link detected: yes
> linux-h4yw:~ #
Full duplex at 100 Mb/s is as good as that device will do. Any slowdown must be
somewhere else.
If you ping your router, what is the delay time. You can find the address with
/sbin/route -n. You will see a table that looks like
finger@larrylap2:~/linux-firmware> /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 enp0s10
192.168.2.0 0.0.0.0 255.255.255.0 U 1 0 0 enp0s10
Your router’s address is the one listed under “Gateway” in the line with “UG”
flags. For my case, I get something like
finger@larrylap2:~/linux-firmware> ping -c10 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2.77 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.810 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.808 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.916 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.817 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=0.864 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=0.869 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.838 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.840 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=0.968 ms
--- 192.168.2.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 0.808/1.050/2.773/0.576 ms
On speedtest.net, my ping time is 51 ms, and my download speed is 16.11 Mbps. By
selecting a different server with a ping time of 217 ms, my download speed is
cut to 8.43 Mbps.
… it says… unknown host
linux-h4yw:~ # /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
linux-h4yw:~ # ping -c10 192,168.0.1
ping: unknown host 192,168.0.1
linux-h4yw:~ # ping 192,168.0.1
ping: unknown host 192,168.0.1
but the pc connects directly to a ARRIS TOUCHTONE Cable Modem, no other device between.
That’s because of typos. It should be
ping -c 10 192.168.0.1
BTW, please use
[/CO..] tags when posting command output; (refer to the '#' icon in the editor).mhunt0 wrote:
*********** To reply by e-mail, make w single in address **************
… oops… sorry… didn’ noticed the typos…
linux-h4yw:~ # ping -c 10 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.489 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.483 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.484 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.461 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.469 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.452 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.465 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.454 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.492 ms
--- 192.168.0.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.452/0.681/2.561/0.626 ms
… it seems to give better results at the moment…
You may want to allocate more of your system’s resources for TCP/IP networking and for the type of traffic… So, for instance if your game configures a <very> large number of simultaneous network connections.
The starting point to understand is that by default openSUSE like most Linux distros come with defaults that run on a wide assortment of hardware and for different uses, so default settings are set to be able to run on machines with limited resources.
I wrote an article how to increase the size of your TCP/IP buffers, modify the TCP/IP Congestion Control algorithm and more. All information you need to make custom decisions should be included.
https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection
Applies to every version of openSUSE I know that exists and existed kernel 2.6.30 and later.
HTH,
TSU
Thank I just hope is not another symptom of the ‘system froze’ that I have, that would be periods of reduced general speed + total system halt.
On 08/07/2014 08:36 AM, mhunt0 wrote:
>
> Thank I just hope is not another symptom of the ‘system froze’ that I
> have, that would be periods of reduced general speed + total system
> halt.
That would have been good information to have posted in the first message. If
the system has response issues, it will obviously affect your throughput.
In any case, your internal ping times are good. You might try increasing the
count to 1000 to see if there are any long times that show up, or if any packets
are being dropped. In addition, you need to try the pings with longer data packets.
Use ‘ping -c 1000 -s 1492 192.168.0.1’. Report only the ping statistics lines.
true, I just didn’t knew that there was such general performance decrease in the system, it was not evident, the only symptom that I had detected (and still happens) is a random full system froze (including the cursor).
That’s too bad, I’ll buy a new system soon, still considering from buying a Dell or build my own, if I build my own then I won’t install Windows since for the type of games that I use the current XP partition is more than enough, but with a new Dell that comes with Windows 8.1 I’ll have to consider if it worth the hassle of a dual boot on a brand new system.
Anyway, tried the ping command form above, after 3 minutes I cancelled:
linux-h4yw:~ # ping -c 1000 -s 1492 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 1492(1520) bytes of data.
^C
--- 192.168.0.1 ping statistics ---
365 packets transmitted, 0 received, 100% packet loss, time 366894ms
On 08/07/2014 11:46 AM, mhunt0 wrote:
>
> true, I just didn’t knew that there was such general performance
> decrease in the system, it was not evident, the only symptom that I had
> detected (and still happens) is a random full system froze (including
> the cursor).
>
> That’s too bad, I’ll buy a new system soon, still considering from
> buying a Dell or build my own, if I build my own then I won’t install
> Windows since for the type of games that I use the current XP partition
> is more than enough, but with a new Dell that comes with Windows 8.1
> I’ll have to consider if it worth the hassle of a dual boot on a brand
> new system.
>
> Anyway, tried the ping command form above, after 3 minutes I cancelled:
>
>
> Code:
> --------------------
>
> linux-h4yw:~ # ping -c 1000 -s 1492 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) 1492(1520) bytes of data.
> ^C
> — 192.168.0.1 ping statistics —
> 365 packets transmitted, 0 received, 100% packet loss, time 366894ms
Your system is blowing up on long packets. Use the ifconfig command to determine
the MTU value for eth0. You might also try changing the number after the “-s”
between 56 and 1492 to see where it breaks.
it breaks on -s 1473
linux-h4yw:~ # ping -c 1000 -s 1472 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 1472(1500) bytes of data.
1480 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.838 ms
1480 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.823 ms
1480 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.827 ms
1480 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.827 ms
1480 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.843 ms
1480 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.832 ms
1480 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.841 ms
1480 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.832 ms
1480 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.832 ms
1480 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.820 ms
1480 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=0.828 ms
1480 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=0.833 ms
1480 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=0.842 ms
1480 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=0.844 ms
1480 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=0.831 ms
^C
--- 192.168.0.1 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 13998ms
rtt min/avg/max/mdev = 0.820/0.832/0.844/0.038 ms
and ifconfig returns 1500 for MTU:
linux-h4yw:~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:06:5B:01:66:51
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::206:5bff:fe01:6651/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11296 errors:0 dropped:0 overruns:23 frame:0
TX packets:9448 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11558738 (11.0 Mb) TX bytes:1530101 (1.4 Mb)
Interrupt:18 Base address:0xc800
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:65536 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1280 (1.2 Kb) TX bytes:1280 (1.2 Kb)
Perhaps the MTU issue is upstream, eg your router hardware?
Edit: Actually, I though I’d check my laptop NIC and it fails at 1473 packet size too. (It doesn’t concern me at all though.)
On 08/07/2014 04:26 PM, deano ferrari wrote:
>
> Perhaps the MTU issue is upstream, eg your router hardware?
But it should not drop all packets longer than MTU. For example, my system can
ping with 4K packets.
Try ‘sudo ifconfig eth0 mtu 3000’, and then retest with speedtest.net.
On 2014-08-08 01:41, Larry Finger wrote:
> On 08/07/2014 04:26 PM, deano ferrari wrote:
>>
>> Perhaps the MTU issue is upstream, eg your router hardware?
>
> But it should not drop all packets longer than MTU. For example, my system can
> ping with 4K packets.
But the reported MTU is 1500, and it breaks on 1473. I think that the
MTU is wrong :-?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))