Notebook, slow internet after resume

English Network/Internet
1

After resume (opening the lid of the notebook) the internet is very slow 8Mbps instead of 500Mbps. Nothing helps but reboot. I tried sudo netconfig update -f, sudo systemctl restart NetworkManager, sudo systemctl restart network but with no success; only reboot helped.

openSuse Leap 15.1, Plasma 5.17.4, Frameworks 5.64.0, Qt 5.13.1, kernel 4.12.14-lp151.28.32-default

2

@krpan:

Physical Ethernet cable or WLAN?

  • Given 500 Mb/s I’m guessing WLAN but, I need to be sure …
3

@krpan:

Testing on a Laptop – WLAN – two AVM FRITZ!WLAN 1750 Repeaters in a daisy-chain from the DSL FRITZ!Box.

  • I’m currently attached to the 2nd Repeater in the daisy-chain.
  • Data rate between the 1st and 2nd Repeater is between 205 Mbit/s and 216 MBit/s – 2.4 GHz band.
  • Data rate between this Laptop and the 2nd Repeater varies between 72 MBit/s and 1 MBit/s – it seems to cycle up and down between the upper and lower values.
  • Fairly heavy neighbourhood WLAN activity in the 2.4 GHz band – up to 16 neighbours on the channels in the middle of the band …
  • Suspending the Laptop either by closing the lid or, using the KDE Plasma program starter, doesn’t seem to affect the WLAN data rate in any way at all.
4

It is a cable not Wlan. The described malfunction occurs every time not randomly. Again, the steps are as follows.

  1. Working with notebook, Network manager, cable, speed test between 400 and 500 Mb/s.
  2. Close the lid.
  3. After a while, open the lid and resume.
  4. Speed test between 8 and 10 Mb/s.
  5. Reboot, speed test between 400 and 500 Mb/s.
5

Needless to say,
Proper benchmarking practice is to run multiple tests and also make sure after resuming that you machine has completely “spun up.”

I can imagine a multitude of possible causes both network and system that might cause a slow connection,
You might try simply doing a networking service restart which should “re-announce” your machine to the network and refresh your network settings

systemctl restart network

TSU

6

As I mentiond in my original post, I tried sudo netconfig update -f, sudo systemctl restart NetworkManager, sudo systemctl restart network, but with no success; only reboot helped.

7

You might try running a small netcat (nc) test between two machines in your LAN to see if the problem is your gateway or not…
In fact, you can use netcat to quickly and simply test the network connection between any two machines.

Of course, don’t use name resolution unless you want to include testing for that, only use IP addresses.

The things you did on your machine are generally what I would do to test if there is a problem on your machine, so next step is to see if there is a network problem…
For instance if you are running a Workgroup instead of Network based authentication (eg AD or LDAP), then depending on what’s happening there can be Browse Master issues.

As I described, the main difference I can think of when you boot a system vs. simply waking up is that your system may need to “announce” itself again on your network properly, which happens when you boot. Linux doesn’t ARP that much so other machines may “forget” your machine if it’s offline long enough for cached information about your machine expires.

TSU

8

Obviously, I would be woth mentioning my notebook is connected directly to the modem, no network is involved. And in addition, please bear in mind I am not a Linux expert, more an advance user.

9

That itself could be information, how do you connect to the Internet?
And, if you are indeed connecting directly through a real modem (not a proxy device like an Android phone which people may call a modem but really isn’t), then you should have log files for that type of connection that can be inspected.

I’ll admit that at least where I’m at… It has been a very long time since people dialed up the Internet directly. Even if you are doing PPoE on your machine itself would be unusual today. Typically all access is through an Internet Gateway device which handles the type of Internet connection, whether it’s broadband or dialup.

TSU

10

If a cable then, it’s possibly an Ethernet cable.

  • Ethernet to a modern modem should be one of 1000baseT or, 100baseT or, 10baseT.

With the user “root”, please post the following:


lspci | grep -i 'Ethernet'
lspci -s «the “number:number.number” value at the left of the previous output» -v


  - For example: “*lspci -s 02:00.0 -v*
”

Given the “Kernel driver in use:” value, please post, (user “root”) the following “r8169” is the example for my machine]:


journalctl --this-boot | grep -i '«Kernel driver in use value»'


  - For example: “*journalctl --this-boot | grep -i 'r8169'*
”

The network device will be indicated – possibly “eth0” but, it could be something else …

Please post the output of “ethtool «Network Device name»” – for example, on this machine it’s “ethtool eth0”.

  • From this output, we can determine which Ethernet speed your Laptop is using.
11

Here is the output of the commands.

lspci | grep -i 'Ethernet'
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)

lspci -s 00:19.0 -v
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
        Subsystem: Hewlett-Packard Company Device 1630
        Flags: bus master, fast devsel, latency 0, IRQ 40
        Memory at d2500000 (32-bit, non-prefetchable) [size=128]
        Memory at d252a000 (32-bit, non-prefetchable) [size=4]
        I/O ports at 5020 [size=32]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [e0] PCI Advanced Features
        Kernel driver in use: e1000e
        Kernel modules: e1000e

journalctl --this-boot | grep -i 'e1000e'
dec 16 05:26:06 krpan2002 kernel: e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
dec 16 05:26:06 krpan2002 kernel: e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
dec 16 05:26:06 krpan2002 kernel: e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
dec 16 05:26:06 krpan2002 kernel: e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock
dec 16 05:26:06 krpan2002 kernel: e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) e4:11:5b:5d:03:71
dec 16 05:26:06 krpan2002 kernel: e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
dec 16 05:26:06 krpan2002 kernel: e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
dec 16 05:26:11 krpan2002 kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
dec 16 05:26:11 krpan2002 kernel: e1000e 0000:00:19.0 eth0: Unsupported Speed/Duplex configuration

[/size][/size][/size]

12

In addition to our e-correspondence I tried the following.

  1. Boot notebook (with ethernet cable), speed 485 Mb/s
  2. entered the command ethtool eth0 with the result:
Settings for eth0:
        Supported ports:  TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: internal
        Auto-negotiation: off
        MDI-X: on (auto)
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
  1. Closed the lid
  2. After 10 minutes or so open the lid
  3. Tried speed: 8 Mb/s
  4. entered the command ethtool eth0 with the result:
ethtool eth0
Settings for eth0:
        Supported ports:  TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 10Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: off
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

The only difference I see is PHYAD.

Is this result of any value.

13

This looks as if it could be an issue.

Other people are also seeing this issue.

[HR][/HR]Bottom line:

  • It could be a broken Ethernet cable – old cable, broken conductors, broken connectors, whatever …
  • It could be the Ethernet auto-negotiation with the Modem or Router you use to connect to your ISP – the Intel interface is saying that, the Modem or Router is not supporting auto-negotiation – check the settings on that box …
14

It is a bit strange that a broken Ethernet cable – old cable, broken conductors, broken connectors, whatever has anything to do with the notebook lid open or close.
I would assume that after opening the lid and resume with work settings are somehow forgotten by Linux or Plasma or whatever. Rebooting the notebook revives high internet connection, and this has nothing to do with cable hardware.

Don’t you think so.

15

No – it seems that, the Ethernet handshaking after the Laptop has been resumed isn’t correctly setting up the Ethernet speed.

16

Perhaps the OP could try temporarily switching off auto-negotiation in Network Manager and explicitly setting the Link Speed and Duplex Mode …

https://paste.opensuse.org/view/raw/70b57491

17

Well, it looks like your tip solved the problem. I checked !Allow auto-negotiations" and it works perfectly.

Thanks.

18

OK… The question now is. Why doesn’t Network Manager auto-negotiate after resume?

I wonder if that is a problem you’ve recently experienced, following a software update perhaps. Or, is it a problem that has always been present on that hardware?

There does appear to be quite a lot of issues with Network Manager following a suspend/resume cycle, if one Googles for example:

https://www.google.com/search?q=network+manager+suspend+resume

there are quite a lot of results returned, both old and new. At a quick glance most appear to be related to wi-fi rather than a wired connection.

If you’re able to consistently reproduce the issue it may be worth a bug report.

Or you could just opt for leaving the Link Speed and Duplex Mode explicitly set…