Community Forum

Bane
Bane
Offline
Resolved
0 votes
I have a gigabit fiber connection that requires PPPoE. When I enable the PPPoE connection on clear, it reduces me to 100 megabits per second. When I go back to a regular interface and let centurylink's modem do the bridging, I am able to get 800 too 900 megabits down. Is there anyway to fix this? Is this a known bug?
Monday, April 09 2018, 12:48 AM
Share this post:
Who is viewing this page
Responses (23)
  • Accepted Answer

    Tuesday, May 22 2018, 09:26 AM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    Please can you let me know if this issue is the same as ticket 558584 at Clearcenter?
    No it isn't but coincidentally the thread got bumped at about the same time as the ticket after both had been dormant for a while!

    It is looking unlikely that the kmod-e1000e driver or even the latest non-kmod one will give you any gain but they are worth trying.

    The 7.5 kernel, when it comes out, will come with the same driver as the current kernel, unfortunately. But I believe this kernel comes with other very significant changes which may help if it is not a driver bug but is a kernel bug. I notice the new kernel is available now in the updates-testing repo. I have no idea how safe it is but you can try installing it with a:
    yum update kernel --enablerepo=clearos-updates-testing
    You will need to reboot for the new kernel to take effect. Note that during boot up it will default to the latest kernel but you get about 5s during the boot to select a different one if necessary. If you try it please report back.

    The only other option is to try a USB3 NIC (USB2 has a max speed of 480Mbps). I have absolutely no idea of which USB3 NICs are good in ClearOS.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 22 2018, 02:41 AM - #Permalink
    Resolved
    0 votes
    OK - CPU load and MTU not a problem - sorry, not sure what else to suggest...
    Be sure to try the updated driver offered by Nick.

    Hmm, so it's a synchronous fibre connection - so even using the modem to do the PPPoE your upload is still way down - 10%, so all is not good even there. Interestingly, the upload is better using the J1900 for PPPoE. Do you happen to know the PCI Express width of the slot the NIC is in - 1x 4x or 8x? My understanding is the Intel 82583V uses the older PCIe v1.0a bus (it was released in 2009 and is a "home" not server product and therefore will not perform the process offloading that the server NICs provide). Just wondering if the bus is a bottleneck. You should be getting close to 1G both ways with a suitable system...
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Tuesday, May 22 2018, 01:34 AM - #Permalink
    Resolved
    0 votes
    The centurylink supploed C300Z has an MTU of 1492, but setting that on ClearOS made no difference.

    Bane wrote:

    I thought you were talking about a setting in the PPPoE software on clear. My connection is synchronous, 1gig ( 1 gb up and 1gb down).

    Here is a top while running PPPoE and doing a speed test.

    op - 14:38:15 up 3:44, 2 users, load average: 0.53, 0.41, 0.24
    Tasks: 165 total, 3 running, 162 sleeping, 0 stopped, 0 zombie
    %Cpu0 : 15.9 us, 18.5 sy, 0.0 ni, 39.2 id, 0.0 wa, 0.0 hi, 26.4 si, 0.0 st
    %Cpu1 : 8.2 us, 7.5 sy, 0.0 ni, 82.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
    %Cpu2 : 11.0 us, 22.7 sy, 0.0 ni, 53.5 id, 0.0 wa, 0.0 hi, 12.7 si, 0.0 st
    %Cpu3 : 6.6 us, 16.1 sy, 0.0 ni, 69.4 id, 0.0 wa, 0.0 hi, 7.9 si, 0.0 st
    KiB Mem : 8081976 total, 6048784 free, 1159764 used, 873428 buff/cache
    KiB Swap: 6254588 total, 6254588 free, 0 used. 6596256 avail Mem


    Tony Ellis wrote:

    Bane asked "if it is sync or async mode?"

    What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

    The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

    Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?
    Tony Ellis wrote:

    Bane asked "if it is sync or async mode?"

    What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

    The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

    Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Monday, May 21 2018, 09:41 PM - #Permalink
    Resolved
    0 votes
    I thought you were talking about a setting in the PPPoE software on clear. My connection is synchronous, 1gig ( 1 gb up and 1gb down).

    Here is a top while running PPPoE and doing a speed test.

    op - 14:38:15 up 3:44, 2 users, load average: 0.53, 0.41, 0.24
    Tasks: 165 total, 3 running, 162 sleeping, 0 stopped, 0 zombie
    %Cpu0 : 15.9 us, 18.5 sy, 0.0 ni, 39.2 id, 0.0 wa, 0.0 hi, 26.4 si, 0.0 st
    %Cpu1 : 8.2 us, 7.5 sy, 0.0 ni, 82.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
    %Cpu2 : 11.0 us, 22.7 sy, 0.0 ni, 53.5 id, 0.0 wa, 0.0 hi, 12.7 si, 0.0 st
    %Cpu3 : 6.6 us, 16.1 sy, 0.0 ni, 69.4 id, 0.0 wa, 0.0 hi, 7.9 si, 0.0 st
    KiB Mem : 8081976 total, 6048784 free, 1159764 used, 873428 buff/cache
    KiB Swap: 6254588 total, 6254588 free, 0 used. 6596256 avail Mem


    Tony Ellis wrote:

    Bane asked "if it is sync or async mode?"

    What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

    The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

    Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 21 2018, 06:57 PM - #Permalink
    Resolved
    0 votes
    Bane asked "if it is sync or async mode?"

    What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

    The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

    Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Monday, May 21 2018, 05:37 PM - #Permalink
    Resolved
    0 votes
    Below is the ifconfig output. I do not have PPPoE turned on right now. I can send another after I update the drivers and try PPPoE again.

    enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 192.168.2.234 netmask 255.255.255.0 broadcast 192.168.2.255
    inet6 fe80::2ba:abff:fe10:2460 prefixlen 64 scopeid 0x20<link>
    ether 00:ba:ab:10:24:60 txqueuelen 1000 (Ethernet)
    RX packets 1315135 bytes 1620145302 (1.5 GiB)
    RX errors 0 dropped 1293 overruns 0 frame 0
    TX packets 1220650 bytes 1377451410 (1.2 GiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    device interrupt 16 memory 0xd0900000-d0920000

    enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 192.168.3.7 netmask 255.255.255.0 broadcast 192.168.3.255
    inet6 fe80::2ba:abff:fe10:2463 prefixlen 64 scopeid 0x20<link>
    ether 00:ba:ab:10:24:63 txqueuelen 1000 (Ethernet)
    RX packets 1243405 bytes 1382261019 (1.2 GiB)
    RX errors 0 dropped 390 overruns 0 frame 0
    TX packets 1312026 bytes 1620684828 (1.5 GiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    device interrupt 19 memory 0xd0600000-d0620000

    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
    inet 127.0.0.1 netmask 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid 0x10<host>
    loop txqueuelen 1 (Local Loopback)
    RX packets 13365 bytes 1472037 (1.4 MiB)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 13365 bytes 1472037 (1.4 MiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
    inet 10.8.10.1 netmask 255.255.255.255 destination 10.8.10.2
    inet6 fe80::3d6a:b4a:401c:8f5c prefixlen 64 scopeid 0x20<link>
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
    RX packets 0 bytes 0 (0.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 3 bytes 144 (144.0 B)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
    inet 10.8.0.1 netmask 255.255.255.255 destination 10.8.0.2
    inet6 fe80::dbe1:8cd0:266:be2f prefixlen 64 scopeid 0x20<link>
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
    RX packets 0 bytes 0 (0.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 3 bytes 144 (144.0 B)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



    Nick Howitt wrote:

    Can you give me the output of:
    ifconfig


    Also have you tried the latest kmod-e1000e driver available from here. You will need to reboot afterwards.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 21 2018, 05:05 PM - #Permalink
    Resolved
    0 votes
    Can you give me the output of:
    ifconfig


    Also have you tried the latest kmod-e1000e driver available from here. You will need to reboot afterwards.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Monday, May 21 2018, 04:42 PM - #Permalink
    Resolved
    0 votes
    I have tried multiple cables and changed interfaces. The second I turn off PPPoE my bandwidth goes up to 800 to 900 mbps. I am seeing the degradation no matter what interface I use for PPPoE. I am not seeing high CPU or high memory usage when enabling PPPoE.

    Nick Howitt wrote:

    You could try a different port first off, but I did mean a completely different NIC using different drivers.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Monday, May 21 2018, 04:40 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    Please can you let me know if this issue is the same as ticket 558584 at Clearcenter?


    I can't see that ticket, so I am not sure if it is the same issue or not.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Monday, May 21 2018, 04:39 PM - #Permalink
    Resolved
    0 votes
    Here's my CPU info. I it has four codes, but I have left out the other 3 sets of info, for brevity sake. My clearos box has 8gb of RAM. I am using the default PPPoE settings in clearOS. ow can I tell if it is sync or async mode?

    [root@gateway ~]# cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 55
    model name : Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
    stepping : 8
    microcode : 0x829
    cpu MHz : 1332.826
    cache size : 1024 KB
    physical id : 0
    siblings : 4
    core id : 0
    cpu cores : 4
    apicid : 0
    initial apicid : 0
    fpu : yes
    fpu_exception : yes
    cpuid level : 11
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
    bogomips : 3993.60
    clflush size : 64
    cache_alignment : 64
    address sizes : 36 bits physical, 48 bits virtual
    power management:






    Nick Howitt wrote:

    Please can you let me know if this issue is the same as ticket 558584 at Clearcenter?
    Tony Ellis wrote:

    PPPoE has an additional overhead of 8 bytes per packet. This will reduce the speed slightly but not enough to account for the difference you are seeing of itself i.e. a loss of about 0.53%

    Incidentally is is interesting from your tests that the upload speed was somewhat faster while the upload was way down. The test results would be more valid if both tests used the same destination within a few minutes of each other. I know that Wyoming is adjacent to Colorado, but that does not necessarily mean the internet paths are equivalent and comparable.

    However - those 8 extras bytes may be causing fragmentation and thus packet re-transmission. What happens if you try with a MTU of 1492 or slightly lower,assuming here, of course, it is by default 1500? Are you using synchronous or asynchronous mode for PPPoE? Synchronous mode requires a fast CPU - nut sure a J1900 would qualify...

    Lastly, your link shows a system with an Atom E3845 which is not a J1900... though suspect your unit looks similar - just a newer model?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 17 2018, 08:01 PM - #Permalink
    Resolved
    0 votes
    Please can you let me know if this issue is the same as ticket 558584 at Clearcenter?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 17 2018, 02:15 AM - #Permalink
    Resolved
    0 votes
    PPPoE has an additional overhead of 8 bytes per packet. This will reduce the speed slightly but not enough to account for the difference you are seeing of itself i.e. a loss of about 0.53%

    Incidentally is is interesting from your tests that the upload speed was somewhat faster while the upload was way down. The test results would be more valid if both tests used the same destination within a few minutes of each other. I know that Wyoming is adjacent to Colorado, but that does not necessarily mean the internet paths are equivalent and comparable.

    However - those 8 extras bytes may be causing fragmentation and thus packet re-transmission. What happens if you try with a MTU of 1492 or slightly lower,assuming here, of course, it is by default 1500? Are you using synchronous or asynchronous mode for PPPoE? Synchronous mode requires a fast CPU - nut sure a J1900 would qualify...

    Lastly, your link shows a system with an Atom E3845 which is not a J1900... though suspect your unit looks similar - just a newer model?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 16 2018, 05:30 PM - #Permalink
    Resolved
    0 votes
    You could try a different port first off, but I did mean a completely different NIC using different drivers.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Wednesday, May 16 2018, 05:26 PM - #Permalink
    Resolved
    0 votes
    All the interfaces on the unit are the same intel card. It is a four port NIC. So, do you mean another port or a completely different card.

    Since the unit is a small form factor unit with four ports built in, I would have to use a USB Ethernet adapter to change NIC manufacturers, etc.

    The unit itself is a quad core intel j1900D, I have never seen the unit use more than one code with clear OS. (https://www.amazon.com/dp/B072ZTCNLK/ref=sspa_dk_detail_5?psc=1&pd_rd_i=B072ZTCNLK&pd_rd_wg=9FgCI&pd_rd_r=453SYX5DAPFXG1P9P341&pd_rd_w=uVtqR)

    Nick Howitt wrote:

    Do you have another NIC you can test with?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 16 2018, 03:08 PM - #Permalink
    Resolved
    0 votes
    Do you have another NIC you can test with?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 16 2018, 02:59 PM - #Permalink
    Resolved
    0 votes
    Sorry I can't do any more. I don't have a DSL connection or your hardware to test with - and 1Gb connections don't exist here! I don't know what version of the e1000e driver will come with the ClearOS 7.5 kernel which is due soon.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Wednesday, May 16 2018, 02:38 PM - #Permalink
    Resolved
    0 votes
    Is there any update on this? I won't be renewing my clearOS subscription if this can't be fixed. Without this, ClearOS doesn't have a lot of value to me.

    Bane wrote:

    That made no difference. Below are screen shots of the speed tests.




    Nick Howitt wrote:

    As a thought, there has been an issue with the e1000e driver, but it tended to crash it rather than slow it. Can you try:
    ethtool -K your_interface tso off
    For the interface, use the underlying interface name and not ppp0. You can try it for all four since they use the same driver. It won't survive a reboot but that can be fixed if it works.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Thursday, May 03 2018, 03:19 PM - #Permalink
    Resolved
    0 votes
    That made no difference. Below are screen shots of the speed tests.




    Nick Howitt wrote:

    As a thought, there has been an issue with the e1000e driver, but it tended to crash it rather than slow it. Can you try:
    ethtool -K your_interface tso off
    For the interface, use the underlying interface name and not ppp0. You can try it for all four since they use the same driver. It won't survive a reboot but that can be fixed if it works.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 11 2018, 08:21 AM - #Permalink
    Resolved
    0 votes
    As a thought, there has been an issue with the e1000e driver, but it tended to crash it rather than slow it. Can you try:
    ethtool -K your_interface tso off
    For the interface, use the underlying interface name and not ppp0. You can try it for all four since they use the same driver. It won't survive a reboot but that can be fixed if it works.
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Tuesday, April 10 2018, 07:38 PM - #Permalink
    Resolved
    0 votes
    Sorry, had ifconfig on the brain. Ethtool shows:

    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
    Advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: off (auto)
    Supports Wake-on: pumbg
    Wake-on: g
    Current message level: 0x00000007 (7)
    drv probe link


    Nick Howitt wrote:

    Your NIC drivers are OK.

    I am not aware that ifconfig can give link speeds. "ethtool your_interface_name" will show it as the "Speed" value
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 10 2018, 03:14 PM - #Permalink
    Resolved
    0 votes
    Your NIC drivers are OK.

    I am not aware that ifconfig can give link speeds. "ethtool your_interface_name" will show it as the "Speed" value
    The reply is currently minimized Show
  • Accepted Answer

    Bane
    Bane
    Offline
    Tuesday, April 10 2018, 02:46 PM - #Permalink
    Resolved
    0 votes
    Here's my lspci output.

    [root@gateway ~]# lspci -k | grep Eth -A 3
    01:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection
    Subsystem: Intel Corporation Device 0000
    Kernel driver in use: e1000e
    Kernel modules: e1000e
    02:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection
    Subsystem: Intel Corporation Device 0000
    Kernel driver in use: e1000e
    Kernel modules: e1000e
    03:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection
    Subsystem: Intel Corporation Device 0000
    Kernel driver in use: e1000e
    Kernel modules: e1000e
    04:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection
    Subsystem: Intel Corporation Device 0000
    Kernel driver in use: e1000e
    Kernel modules: e1000e

    I haven't noticed any change indicating a drop out of gigabit. When I check it with ifconfig, it shows gigabit.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 09 2018, 09:01 AM - #Permalink
    Resolved
    0 votes
    No, it is not a known bug. I've seen complaints where the speed drops to 600Mbps which is way faster than 100Mbps.

    Just to do a quick driver check, can you please give the output to:
    lspci -k | grep Eth -A 3


    Also you you notice any lights on your NIC or modem indicating the NIC may have dropped out of gigabit mode and reverted to 10/100 mode? Often a different combination or colour of lights will show.
    The reply is currently minimized Show
Your Reply