Posted on by Jean-Luc Aufranc (CNXSoft) - 73 Comments on Fixing performance issues with Realtek RTL8156B 2.5GbE USB dongle in Ubuntu

Fixing performance issues with Realtek RTL8156B 2.5GbE USB dongle in Ubuntu

A few days ago, I reviewed a USB 3.0 to 2.5 Gbps Ethernet adapter based on Realtek RTL8156B chip in Ubuntu 20.04, and let’s say the reliability and performance were underwhelming. I got some recommendations like changing cables, the MTU size, etc…

Playing around with cables did no help, but one comment mentioned the cdc_ncm driver could be the issue, followed by another saying that updating to Linux kernel 5.14 should install the correct r8152 driver… So I just did that:


This upgraded Linux 5.13 (shipped with Ubuntu 20.04 + HWE) to Linux 5.14, but still no luck as the system kept using the cdc_ncm driver with a half-duplex link:


But then I thought I may have to use udev rules to prevent loading the cdc_ncm driver, and there’s indeed 50-usb-realtek-net.rules in r8152 driver to do just that. So I copied the file in /etc/udev/rules.d/ folder. Since I did not want to reboot, I unloaded the modules I did not need, and restart udev to try it out:


Let’s see…


Great! It’s now using r8152 driver and we’ve got a full-duplex connection.

Let’s go through all our tests again to compare the results.

iperf2

upload


download:


There’s an improvement to the download speed (was 600 Mbps with cdc_ncm driver), but still not quite close to 2.3 Gbps.

Let’s try full-duplex for fun:


That’s actually not too bad.

iperf3

upload:


download:


About the same as iperf2.

iperf3 did not have support for full-duplex for many years, but version 3.7 reintroduced the feature. So let’s give it a go:


Oops! What happened? There are some error messages in the kernel log as well.


I’m not the only one to have this problem, and that’s an open issue in r8156 driver’s Github repo. Here’s the answer from the developer for reference:

I suspect a problem on the ethernet adapter side, as there are many reports of it working with the DS918+. (Eg. design of power line, overheat, etc.)
https://github.com/bb-qq/r8152/wiki/Compatibility

Could you try another vendor? Also using a USB Hub with an external power supply might improve the situation.

At this point, the Ethernet did not work at all, and I had to unplug and reinsert the USB dongle. The second time “worked”.


There are still retransmissions on the Rx side which could help explain the lower speed.

SAMBA

From my laptop with the RTL8156B dongle, and SATA SSD to UP Xtreme i11 mini PC with a 2.5GbE port, and a MINIX USB-C dock with a 480GB SSD.

SAMBA r8152 driver laptop to mini PC

Around 930 Mbps with r8152 driver against 750 Mbps with cdc_ncm driver.

Now from the mini PC to the laptop (aka download)…

 

SAMBA r8152 driver mini PC to laptop

It’s slower as expected at 837 Mbps, but better than the under 500 Mbps I got with the cdc_ncm driver.

scp

laptop to mini PC:


mini PC to laptop:


It’s almost the same speed between download and upload with scp which is odd. The bottleneck here looks to be my SATA SSD:


Read is limited by around 145 MB/s, while write is around 140 MB/s.

The SSD used in MINIX NEO Storage Plus USB-C dock is quite faster with, last time I tested, 379MB/s for sequential reads, and 240+MB/s for sequential writes.

So let’s see the speed we can get throwing away the data to /dev/null

download to laptop:


upload from laptop:


So that’s more like it for the upload at least. I still have a problem with the download speed, but the performance was still greatly improved with the r8152 driver.

cdc_ncm vs r8152 drivers ubuntu
Left scale in Mbps

 

Testing with NanoPi R4S

While it’s much better, it’s not optimal. I have a NanoPi R4S router with two USB 3.0 ports, so I first tried it using the latest OpenWrt (FriendlyWrt) 21.02 image with Linux 5.15:


It’s really ugly with lots of retransmissions on both sides.


Looking at the kernel log, our RTL8156B USB dongle is using that CDC NCM driver again, just like in Ubuntu… There’s an r8152 driver too, but whatever module I remove in /etc/modules.d either the CDC NCM is loaded or the eth2 interface does not show up at all. So I’ve switched to the Ubuntu 20.04-based FriendlyCore OS, also featuring Linux 5.15, that will be closer to the setup on my laptop.

As one might have expected, the RTL8156B adapter uses the CDC NCM driver by default in Ubuntu:


eth1 is not showing up with ifconfig, so I just went ahead and change udev rules to use the r8152 driver…


It’s getting depressing. Let’s update the system first.


I followed all those steps since the FriendlyCore image relies on servers from China, which are very slow from where I have (just running apt update can take 15 minutes), so the update was possibly faster that way, although it still took a couple of hours! (See Changing Ubuntu Apt Mirror from the Command Line for details).

It did not help with the firmware issue. So instead I search for that rtl_nic/rtl8156b-2.fw file. It is in the firmware-realtek Debian package, or linux-firmware Ubuntu Impish package.

I downloaded the latter, extracted rtl8156b-2.fw and copied it to /etc/firmware/rtl_nic. It now works:


Somehow the interface is still not up, and adding it manually to /etc/network/interfaces.d, does not work.

Back to the Ubuntu laptop with rtl8156b-2.fw firmware

So instead, I went back to my laptop, and copied the firmware file to /lib/firmware/rtl_nic directory. The result was the same as in NanoPi R4S:


Let’s try iperf3 upload:


Same as before, so no regression. Now for the iperf3 download:


It’s getting better, although we are not there yet, and the retransmissions are through the roof. I’m really tired now… Let me know if you have other ideas.

Realtek RTL8156BG USB 3.0 to 2.5GbE dongle to the rescue.

[Update: Realtek sent me one of their USB 3.0 to 2.5GbE adapters and it does not have the same performance issue


]

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

73 Replies to “Fixing performance issues with Realtek RTL8156B 2.5GbE USB dongle in Ubuntu”

  1. Have you already checked whether it can be related to overheating (thumb test, operating the thing open)? The RTL8156 dongles we use (Delock 65990) have a rather heavy metal enclosure allowing for good heat dissipation…

    Reply

  3. @Jean-Luc

    (1) reading this article and the previous one, I went back to testing rtl8156b on ARM (an Odroid N2+). The driver I use provides the expected max speed you can hope for: 2.35Gbits/sec in one direction and 2.05 Gbits/sec because the ARM CPU would probably need to run at 3Ghz to support 2.35Gbits/sec in reverse, meaning sending.)

    (2) To my dismay, with the driver I use plus the current ARM kernel on Odroid N2+ (4.9.277-121) hard disconnection is showing up its ugly head again (same thing using the Kernel driver too) in one direction 🙁

    See https://forum.odroid.com/viewtopic.php?f=181&t=44027 for details.

    (3) In your case, the RK3568 may not be enough (a guess) to send beyond 1.55 Gbits/sec. The Odroid N2+ OC at 2400 Ghz tops at 2.05 Gbits/sec.

    The hard disconnection reappearing is a downer. It requires a USB reset to get the adapter working back.

    Reply

    1. @Jean-Luc

      You may also want to try between the  UP Xtreme i11 and another PC. On my side, Odroid H2+ <–> an AMD r7-5700g go full speed high flying colors, no disconnection.

      I’m now going to try Armbian images on the Odroid N2+, I think I remember Igor saying at the time that he took care of integrating and testing the Realtek drivers. I’ll try Armbian_20.05.1_Odroidn2_focal_current_5.6.15 and Armbian_21.08.9_Odroidn2_focal_current_5.10.81.

      It could be that a full working Realtek driver started to appear with Kernel 5.6…

      We’ll see.

      Reply

      1. I tested Armbian on the Odroid N2+. It provides a tiny optimization in speed but I see the same pattern of hard disconnection. I posted my results on the Odroid forum whose link is in my first comment here.

        Reply

    2. (3) In your case, the RK3568 may not be enough (a guess) to send beyond 1.55 Gbits/sec. The Odroid N2+ OC at 2400 Ghz tops at 2.05 Gbits/sec.

      My laptop is using an AMD Ryzen 7 2700U processor, and the UP Xtreme mini PC is based on an Intel Core Tiger Lake processor, so the CPUs should not be the bottleneck.

      Reply

        2. a) What OS do you run on each host?
          b) What does sudo ethtool -i <nic_name_in_ip_a> show?
          c) After testing what does sudo ethtool -S <nic…> show?

          In the meantime, may be I was lucky between my H2+ and 5700g with only 300-second sessions. I’m gonna run a 3600-second session just to be sure.

          Reply

          1. Ubuntu 20.04 + HWE (Linux 5.13) on both platforms.
            I’ve just switched to another older laptop that’s running Ubuntu 20.04 with Linux 5.4. Tried iperf3 out of the box at around 250 Mbps… Currently updating it, and I’ll try again.

          2. The OS update in the other laptop is complete… This is what happens now when I insert the USB adapter (after a reboot):

            [ 8734.215897] usb 3-1: new high-speed USB device number 2 using xhci_hcd

            [ 8735.183955] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?

            [ 8736.151942] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?

            [ 8736.152067] usb usb3-port1: attempt power cycle

            [ 8737.435918] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?

            [ 8738.403794] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?

            [ 8738.403895] usb usb3-port1: unable to enumerate USB device

            The kernel output is still OK on my regular laptop. Go figure…

          3. The 1H session between a H2+ and a 5700g went fine full speed BUT and it’s a big one, both PC were unresponsive to console commands after the test. I had to reboot to get control back. So as of today, I’m no longer relying on these adapters, something is wrong with the current drivers and kernel. Two years ago, I ran 10H sessions with not a peep of an error. It’s a regression and clearly Realtek has not cleaned up its act.

          4. and

          5. Yes, whatever the actual origin of the driver, they all refer to the 2.15 version from 04/15/21 on the Realtek web site. I diffed the r8152.c from the git project you referred to and from the download from the Realtek web site, it’s the same source code with just a few additions for ASUS and Trendnet branding.

          6. Mmm… Strike that. There are differences in compatibility.h plus usage of #ifdef ACPI_TYPE_BUFFER in r8152.c. So you may want to compare your testing between the version from the RealTek web site and the git project you referred to:

            domih@trx:~/Downloads$ diff r8152-master/r8152.c r8152-2.15.0/r8152.c
            301,303d300
            < #ifdef CR_TE
            < #undef CR_TE
            < #endif
            794d790
            < #define VENDOR_ID_ASUS         0x0b05
            801d796
            < #define VENDOR_ID_TRENDNET      0x20f4
            1452d1446
            < #ifdef ACPI_TYPE_BUFFER
            1499d1492
            < #endif
            1509d1501
            < #ifdef ACPI_TYPE_BUFFER
            1521,1522d1512
            < #endif
            <
            20081d20070
            <   netif_info(tp, probe, netdev, “chip rev %d\n”, tp->version);
            20193,20195d20181
            <   /* TRENDnet */
            <   {REALTEK_USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02b)},
            <   
            20198,20200d20183
            <   
            <   /* ASUS */
            <   {REALTEK_USB_DEVICE(VENDOR_ID_ASUS, 0x1976)},
            domih@trx:~/Downloads$ diff r8152-master/50-usb-realtek-net.rules r8152-2.15.0/50-usb-realtek-net.rules
            domih@trx:~/Downloads$ diff r8152-master/compatibility.h r8152-2.15.0/compatibility.h
            11,14d10
            <
            < #include <linux/acpi.h>
            < // FIXME: Some platform do not have asm/acpi.h which is included by acpi/acpi.h
            < #ifdef ACPI_TYPE_BUFFER
            16d11
            < #endif
            38,41d32
            <   #else
            <   # if __has_attribute (__fallthrough__)
            <   # define fallthrough                   __attribute__((__fallthrough__))
            <   # endif
            43,44c34,37
            <   
            <   #ifndef fallthrough
            —
            >
            >   #if __has_attribute(__fallthrough__)
            >   # define fallthrough                   __attribute__((__fallthrough__))
            >   #else
            48,56d40
            <   // https://github.com/torvalds/linux/commit/99b60d56a35b18af267f275559a530db372bfad7
            <   #define MDIO_EEE_2_5GT      0x0001   /* 2.5GT EEE cap */
            <   #define MDIO_EEE_5GT      0x0002   /* 5GT EEE cap */
            <
            < #if LINUX_VERSION_CODE < KERNEL_VERSION(5,1,0)   
            <   // https://github.com/torvalds/linux/commit/7fd8afa8933a095a97995885740999f174e61b60
            <   #define MDIO_AN_10GBT_CTRL_ADV2_5G   0x0080   /* Advertise 2.5GBASE-T */
            <   #define MDIO_AN_10GBT_CTRL_ADV5G   0x0100   /* Advertise 5GBASE-T */
            <
            93,106d76
            <
            <   // Added for old platforms
            <   enum skb_free_reason {
            <      SKB_REASON_CONSUMED,
            <      SKB_REASON_DROPPED,
            <   };
            <   static inline void dev_consume_skb_irq(struct sk_buff *skb)
            <   {
            <      dev_kfree_skb_irq(skb);
            <   }
            <   static inline void dev_consume_skb_any(struct sk_buff *skb)
            <   {
            <      dev_kfree_skb_any(skb);
            <   }
            112d81
            <
            119,156d87
            <
            <   // Added for old platforms
            <   #ifndef CLASS_ATTR_RW
            <   #define CLASS_ATTR_RW(_name) \
            <      struct class_attribute class_attr_##_name = __ATTR_RW(_name)
            <   #endif
            <   #ifndef CLASS_ATTR_RO
            <   #define CLASS_ATTR_RO(_name) \
            <      struct class_attribute class_attr_##_name = __ATTR_RO(_name)
            <   #endif
            <   #define ATTRIBUTE_GROUPS_BACKPORT(_name) \
            <   static struct BP_ATTR_GRP_STRUCT _name##_dev_attrs[ARRAY_SIZE(_name##_attrs)];\
            <   static void init_##_name##_attrs(void)            \
            <   {                           \
            <      int i;                        \
            <      for (i = 0; _name##_attrs[i]; i++)            \
            <         _name##_dev_attrs[i] =            \
            <            *container_of(_name##_attrs[i],      \
            <                  struct BP_ATTR_GRP_STRUCT,   \
            <                  attr);            \
            <   }
            <   #ifndef __ATTRIBUTE_GROUPS
            <   #define __ATTRIBUTE_GROUPS(_name)            \
            <   static const struct attribute_group *_name##_groups[] = {   \
            <      &_name##_group,                  \
            <      NULL,                     \
            <   }
            <   #endif /* __ATTRIBUTE_GROUPS */
            <   #undef ATTRIBUTE_GROUPS
            <   #define ATTRIBUTE_GROUPS(_name)               \
            <   static const struct attribute_group _name##_group = {      \
            <      .attrs = _name##_attrs,               \
            <   };                        \
            <   static inline void init_##_name##_attrs(void) {}      \
            <   __ATTRIBUTE_GROUPS(_name)
            <
            <   #define __ATTR_RW(_name) __ATTR(_name, 0644, _name##_show, _name##_store)
            <
            160,166d90
            <
            <   // Added for armadaxp and evansport
            <   static inline void sg_unmark_end(struct scatterlist *sg)
            <   {
            <            sg->page_link &= ~0x02;
            <   }
            <
            187,190d110
            <   // Added for armadaxp and evansport
            <   #define skb_add_rx_frag(skb, i, page, off, size, truesize) \
            <      skb_add_rx_frag(skb, i, page, off, size)
            <
            580d499
            <
            633d551
            < #endif /* LINUX_VERSION_CODE < KERNEL_VERSION(5,1,0) */

          2. Just one general comment though that’s certainly not the cause of your current issue given the low rates involved, that’s a huge number of parasitic processes on your machine! The machine should be at exactly 0% CPU when the test does not run, and it should be dedicated to the test software **exclusively**. If you don’t want to kill these parasitic processes, just send them a kill -STOP before the tests, and a kill -CONT after (don’t forget to reduce your browser windows before kill -STOP as you won’t be able to move them). I’m personally used to seeing perf numbers drop by 30-40% just when a browser is opened for example due to it refreshing some ads on some pages and periodically turning from 0% to 30%, and so on. At high speeds, wasting some CPUs on heavy tasks can even result in packet loss on the Rx path when queues fill quickly and the same core is shared between the softirq and the process! And regardless of the CPUs involved, there’s always the TLB and L3 cache pollution, DRAM bandwidth, sometimes even locking inside the kernel for certain operations, etc. I’m saying this so that you waste less time on similar issues in the future, and that you can also produce undisputable numbers.

      3. > the CPUs should not be the bottleneck

        It could be if the driver is crappy or the rings are too small, resulting in lots of wakeups/sleeps or IRQs. It would be interesting to see “top” and check if you’re seeing ksoftirqd at 100% on one core, especially during the Rx tests. In this case it could be useful to enable RPS (/sys/class/net/eth1/queues/rx*/rps_cpus) to make other cores deal with the incoming traffic. Maybe the USB stack is busy enough on the receiving core.

        Reply

        1. There’s a single Rx queue, which I set to “f” this morning, but it did not seem to make a difference. I’ll check atop during the test a bit later.

          Reply

    3. > testing rtl8156b on ARM (an Odroid N2+)

      Did Hardkernel replace the Genesys Logic GL3523 hub from the N2 on the N2+ or is it still the same thing?

      Reply

      1. domih@n2pa:~$ lsusb
        Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
        Bus 002 Device 002: ID 05e3:0620 Genesys Logic, Inc. USB3.1 Hub
        Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
        Bus 001 Device 007: ID 0b95:6801 ASIX Electronics Corp.
        Bus 001 Device 006: ID 0b95:6801 ASIX Electronics Corp. USB2.1 Hub
        Bus 001 Device 005: ID 0b95:6808 ASIX Electronics Corp.
        Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
        Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
        Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

        Reply

        1. Thank you. So still ‘broken by design’ 🙁

          I really wonder why they did not use the VL817 for N2+ (as they did on the C4. But even then everything behind an USB hub is sort of ‘broken by design’. Those Amlogic SoCs have USB3 and PCIe multiplexed so why not using a PCIe attached USB3 host controller like the VL805 instead to provide four USB3 ports?).

          Reply

    1. That would indeed be good. It would rule out whether it is linux driver problems or if it has hardware/overheating issues.

      Reply

      1. Why either/or when it’s most probably about driver and hardware issues here? 🙂

        Cheap hardware is involved, one of the most crappy receptacles ever designed (USB3-A with its extra tiny SuperSpeed pins) and an OS where a user has to waste hours of his life to get at least an idea which driver to try…

        Reply

        1. thats ‘normality’ for a big part of this world (?)
          What’s the real difference between a 5Gbe for $75 and a 2.5Gbe for $15 if most around have cell phone and average global income per day is somewhere ~$25 (while that’s average (after tax) in Cuba or Venezuela for a whole month!)?
          Honestly, taking that into account means we’re still talking about Win7 drivers compatibility (guess ~2billion computers globally: Win7 (end of support 01/2020), 2020 share 31%->~22% vs. WinXp ~25million globally, Win10 >60% global coverage of Windows systems)

          Reply

          1. (just adding to that: a starlink deposit can be £89.00 or >$500 or $99(CA) means ios or android OS )

          2. I’m patiently waiting for starlink to become available at my current location.

            I recently moved from where I had gigabit download to a rural location where no ISP is available. There is a microwave based ISP who told me they were adding a tower in the next two weeks which would allow me to receive 25/5 which I will indeed use if this tower appears.

            It’s no starlink but when nothing is available it’s a life-saver.

  5. Can try on one machine through virtual systems but to connect networks in adapters among themselves by a patchcord.and keep trying. Maybe the arm driver is weak.
    Try loop.

    Reply

  6. Searching for issues with the usb ethernet chipset you have, shows it is popular for problems and driver issues. Seems you bought a world of pain.

    Reply

  7. I was contacted by Realtek, and an FAE told me to run the two commands below as I had Rx missed issues:

    It did not help in my case, but it may help others.

    Reply

    1. Please note that this large an rx-usecs is only going to increase losses at best, as it tries to deliver IRQs no more than every 250ms, i.e. it can fill the rx ring and deliver the IRQ once completely filled. I think that instead it would be useful to try with lower values (like 30 which can cause up to 33k irq/s and will trigger after no more than 108 packets in ring at 2.5 GbE). It’s also common for many chips not to use accurate timings, so another test you can make is to use “rx-frames 1” to try to provoke one irq per frame. It should eat quite a lot of CPU and should normally be slower. If it ends up being faster, it indicates that it’s one of these numerous chips which have broken timers and cannot deliver IRQs in time, letting incoming data rot in rx buffers.

      Reply

      1. Great. Is there a good documentation somewhere describing the meaning of these TX and RX parameters? I can play with these, but I need to know what I’m doing/testing. TIA!

        Reply

        1. I guess it’s in “man ethtool”, but the names look pretty natural to me: everything suffixed with “usecs” indicates a delay, others are counts.

          Reply

    2. With:

      domih@r7-5700g:~$ sudo ethtool -i enx00e04c680184
      driver: cdc_ncm
      version: 5.13.0-30-generic
      firmware-version: CDC NCM
      expansion-rom-version:
      bus-info: usb-0000:08:00.3-1
      supports-statistics: yes
      supports-test: no
      supports-eeprom-access: no
      supports-register-dump: no
      supports-priv-flags: no

      domih@r7-5700g:~$ sudo ethtool -c enx00e04c680184
      Coalesce parameters for enx00e04c680184:
      Cannot get device coalesce settings: Operation not supported

      domih@r7-5700g:~$ sudo ethtool -C enx00e04c680184 rx-usecs 250000
      Cannot get device coalesce settings: Operation not supported

      domih@r7-5700g:~$ sudo ethtool -g enx00e04c680184
      Ring parameters for enx00e04c680184:
      Cannot get device ring settings: Operation not supported

      domih@r7-5700g:~$ sudo ethtool -G enx00e04c680184 rx 1000
      Cannot get device ring settings: Operation not supported

      So I guess I’ll have to try it with the Realtek driver…

      ALSO, I will definitely take into account what @Willy wrote below.

      I also need to retrieve the IRQ table after a test to see which cores are involved.

      Finally, I don’t have @Jean-Luc issue, my speed is OK and constant. My problem is hard disconnection at some point and the PC left in an unstable condition 🙁

      Reply

    3. After back and forth testing with Realtek, they concluded it was probably a USB host issue. Since I still have NanoPi M4V2 with me, I connected the dongle, and the problem remains. It’s most likely a problem with the adapter design.

      Reply

      1. I’ve finally received another USB 3.0 to 2.5GbE adapter from Realtek, and it does not have any issue. See update at the end of the post.

        Reply

        1. What does this new RTL8156B dongle report when querying it for bcdDevice?

          Reply

          1. Friendly reminder to provide the details on the new RTL8156B dongle report.

          2. Here’s the output from the command:

          3. Thank you! That’s at least a third variant after ‘30.00’ (RTL8156) and ‘31.00’ (RTL8156B).

          5. Ok, it starts to make sense (at least from a Linux perspective):

            RTL81XX: don’t buy, doesn’t work
            RTL81XXB: barely working
            RTL81XXBG: barely working but good enough

          6. I had sent my RTL8156B dongle to Realtek Taiwan office. I’ve just asked them if they could reproduce the issue. They used a similar AMD Ryzen laptop and had no problem with either the cdc-ncm or r8152 driver.

            cdc-ncm 2.35G 2.15G
            r8152(v1.12.11) 2.35G 2.13G

            The first number is for upload and the second for download.
            No performance and no stability issue on their side. I can’t see any retransmissions either on the iperf screenshots.

          7. Hmm… strange since what remains then? AMD Ryzen means USB3/XHCI host controller being part of the CPU or some AMD chipset? Same controller in both laptops?

            If that’s the case the only remaining difference could be unstable powering triggering issues with the RTL8156B but not with the different/new RTL8156BG dongle?

          8. repost ( may have forgot to submit)

            Good to see it was not just me with these issues.

            I have multiple usb3 – 2.5GB dongles with R8156b chips. Running on Ubuntu Jammy and win 11.
            Terrible issues with performance and old drivers limiting ubuntu to 2500 / half. Using ethtool to force the speeds (or at least advertised speeds) was throwing errors.

            I even had the interface going off line overnight, (I think I fixed it by disabling power savings, still testing, I have read the driver crashes if told to sleep).
            I was also seeing huge fluctuations in performance which I initially put down to the multiple 2.5Gb switches the traffic is traveling through, and I could get better performance the closer I got to the server.
            Although I had the same 2.3gb from iperf in reverse mode but only about 1.4 – 1.6 in forward (depending on how far I was from the server.)

            My solution was a little different though I used the latest driver from Realtek, which while it would compile on Ubuntu focal would not on Ubuntu Jammy. I found some references in the code were not correct for Jammy.

            I have posted an upgrade request on Ubuntu Launch pad for an upgrade
            https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1969211
             I don’t know how Realtek can say the driver is in the linux kernel (well at least a working version), even for the latest build
             linux-5.18-rc2
            The driver version is 1.12.12, when the version on the Realtek site 2.15 !!!

            /* Information for net-next */
            #define NETNEXT_VERSION     “12”
            /* Information for net */
            #define NET_VERSION       “12”
            q#define DRIVER_VERSION     “v1.” NETNEXT_VERSION “.” NET_VERSION
            #define DRIVER_AUTHOR “Realtek linux nic maintainers <nic_swsd@realtek.com>”
            #define DRIVER_DESC “Realtek RTL8152/RTL8153 Based USB Ethernet Adapters”
            #define MODULENAME “r8152”

            Any way after changing the r8152.c v2.15 file to make it build (sort of the signing did not work, but it produced a .ko file) on Jammy (I’m not a dev so may not have made the most optimal changes), I had control over the device and could make it run at 2500/full.
            When testing from windows to ubuntu jammy I was getting 2.3Gbs ish in iperf3 reverse mode and between 1.4 ad 1.6 Gbs in iperf3 normal mode.

            I then tried windows to windows (all the windows devices had the latest drivers from Realtek) I got the same results. So may be not the linux driver at fault.
            Looking in the windows nic advanced properties there was a setting called “Miscellaneous Transfer setting” set to disabled.
            So I enabled it to see what happened.

            IT WORKED !!! 😊

            c:\iperf-3.1.3-win64>iperf3 -c testsvr
            Connecting to host testsvr, port 5201
            [ 4] local 192.168.1.6 port 51115 connected to x.x.x.x port 5201
            [ ID] Interval      Transfer   Bandwidth
            [ 4]  0.00-1.00  sec  278 MBytes 2.33 Gbits/sec
            [ 4]  1.00-2.00  sec  279 MBytes 2.34 Gbits/sec
            [ 4]  2.00-3.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  3.00-4.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  4.00-5.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  5.00-6.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  6.00-7.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  7.00-8.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  8.00-9.00  sec  280 MBytes 2.35 Gbits/sec
            [ 4]  9.00-10.00 sec  280 MBytes 2.35 Gbits/sec
            – – – – – – – – – – – – – – – – – – – – – – – – –
            [ ID] Interval      Transfer   Bandwidth
            [ 4]  0.00-10.00 sec 2.73 GBytes 2.35 Gbits/sec         sender
            [ 4]  0.00-10.00 sec 2.73 GBytes 2.35 Gbits/sec         receiver

            iperf Done.

            c:\iperf-3.1.3-win64>iperf3 -c testsvr -R
            Connecting to host testsvr, port 5201
            Reverse mode, remote host testsvr is sending
            [ 4] local 192.168.1.6 port 51119 connected to x.x.x.x port 5201
            [ ID] Interval      Transfer   Bandwidth
            [ 4]  0.00-1.00  sec  283 MBytes 2.38 Gbits/sec
            [ 4]  1.00-2.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  2.00-3.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  3.00-4.00  sec  282 MBytes 2.36 Gbits/sec
            [ 4]  4.00-5.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  5.00-6.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  6.00-7.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  7.00-8.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  8.00-9.00  sec  283 MBytes 2.37 Gbits/sec
            [ 4]  9.00-10.00 sec  283 MBytes 2.37 Gbits/sec
            – – – – – – – – – – – – – – – – – – – – – – – – –
            [ ID] Interval      Transfer   Bandwidth    Retr
            [ 4]  0.00-10.00 sec 2.76 GBytes 2.37 Gbits/sec  0       sender
            [ 4]  0.00-10.00 sec 2.76 GBytes 2.37 Gbits/sec         receiver

            iperf Done.

          9. Interesting. This option sounds very much like “workaround for known but undisclosed chip bug” :-/

          10. Hi, Andrew, Thanks a lot for your findings!

            I was able to compile the r8152.c driver on Linux Kernel 5.15 thanks to you.

            static int rtl8152_get_coalesce(struct net_device *netdev,
            struct ethtool_coalesce *coalesce,
            struct kernel_ethtool_coalesce *kernel_coal,
              struct netlink_ext_ack *extack)

            static int rtl8152_set_coalesce(struct net_device *netdev,
            struct ethtool_coalesce *coalesce,
            struct kernel_ethtool_coalesce *kernel_coal,
              struct netlink_ext_ack *extack)

            I came out with the following little script:

            sudo apt install lshw -y
            sudo cp rtl8156b-2.fw /usr/lib/firmware/rtl_nic/rtl8156b-2.fw
            make clean
            make all
            make install
            modprobe r8152
            sudo cp 50-usb-realtek-net.rules /etc/udev/rules.d/50-usb-realtek-net.rules
            sudo depmod -a
            sudo update-initramfs -u
            sudo rm -rf /usr/lib/modules/$(uname -r)/kernel/drivers/net/usb/cdc_ncm.ko

            It now works great, with full duplex and all!

          11. Update! They can reproduce it too, but not 100% of the time, and not when the USB protocol analyzer is in the way.

            It seems we can see a similar failure as yours by re-plugging USB LAN dongle before iperf3 test.

            The symptom has a fail rate at our side.

            With the USB protocol analyzer sniffer in between, the issue does not occur.

            As experienced, the USB signal quality may be concerned.

            The USB protocol log tells that there are errors when packets transfer from USB dongle (Device) to Host.

          12. > With the USB protocol analyzer sniffer in between, the issue does not occur.

            Reminds me of the situation at a former customer over a decade ago. Their ‘network department’ was never able to reproduce issues when they put their Ethernet sniffer in between. Turned out the thing was pretty old and only capable of Fast Ethernet. 🙂

          13. And final Realtek answer after additional testing:

            We check the USB 3.0 signals of the USB LAN dongle in further.

            It fails in several items and that tells the USB signal is not OK.

            In order to check the failure is related to Realtek IC or the USB dongle, we remove the IC to our QA board and run the USB 3.0 signals test again.

            The USB 3.0 signals test result is PASS.

            (The “5G Far End Differential Output Voltage” result is a little bit margin. This item may related to the quality and length of the USB cable connect to the QA board. I currently cannot find a shorter one for test. )

            The performance issue does not occur with the QA board including this RTL8156B IC too.

            The experiment we have done proves that Realtek RTL8156B IC is no problem.

            The PCB layout or the USB cable quality of the USB dongle would be the root cause.

            Thank you for your collaboration in this case.

          14. Another post where I see that RTL81xxBG is showing quietly and fixing performance issues.
            I saw the same chipset in review for DIEWU network card ASM1812 + RTL8125BG chipsets…

  8. Thanks Jean-Luc! The brand new Ubuntu 22.04 has the same problem, and the 50-usb-realtek-net.rules trick worked for me. Kernel already is at 5.15 however, so no need to upgrade that.

    Reply

  9. Hi all,

    I’ve just purchased 4 units of Alxum 2.5 Gigabit Ethernet Adapter, 2.5 Gigabit Network Adapter with RTL8156B (https://amzn.to/3k8SwKD), at one go/in the same purchase.
    Something funny (crazy?) is happening:

    • I got two RaspberryPi Model 4B, 8GB
    • The first one
    • Installed with the Beta 64bits version available on the “legacy” download link here: https://downloads.raspberrypi.org/raspios_arm64/images/
    • I am using that version: 2021-10-30-raspios-bullseye-arm64-lite.img
    • The kernel version of that one is 5.10
    • On the second one
    • I’ve installed the official 64 bits version after it got released few weeks/months ago, and installed it with the RaspberryPi Imager
    • The kernel version is 5.15

    And guess what ?

    • Plugging the Alxum USB to RJ45 adapter on the fist RPi will get the R8152 driver used straight (I checked with lshw)
    • On the second RPi, it’s not the case: the driver in use is the CDC NCM !!

    Very difficult to know what should (or shouldn’t) be used, or done, in order to enjoy the best performances with these adapters.

    If you’re in a similar situation, please raise your hand.

    Reply

    1. The r8152 driver is the preferred one and if you want to debug why some install chooses this driver and the other another one, probably udevadm is of help: https://unix.stackexchange.com/a/607935

      Module blacklisting might be the other source of different driver ‘choices’ so if you’re not administrating the RPi yourself check /etc/modprobe.d/ and ‘grep blacklist /proc/cmdline’

      Reply

  10. For your information,

    I also ordered the ASUS USB-C2500 2.5G Ethernet USB Adapter, and plugged it on my RPi 4B with the latest official 64 bit RaspiOS, and Kernel 5.15.

    The bcdDevice version is even higher: 31.05.

    Reply

  11. This post was extremely helpful. I finally managed to track down a USB Ethernet adapter with the RTL8156B(S)G, the StarTech US2GC30, and it seems to have fixed all my dumb networking issues.

    Thank you so much!

    Reply

    1. Hi,
      I can confirm, I have bought a StarTech US2GC30 thanks to your advise and I have ran iperf3 (server and client) on my Dell 7510 connected to a NXP RDB3 board and perf3 results are as expected:

      Notice I used 2.5Gbps cable first for my tests, and then I have used a 1 meter CAT6 Ethernet Cable (as 2.5Gbps was a loan…) with same results (results above were with CAT6 Ethenet cable).

      Thank you all for your testing

      Reply

  12. @jean-luc At the end of this article, you posted;

    Realtek RTL8156BG USB 3.0 to 2.5GbE dongle to the rescue.

    [Update: Realtek sent me one of their USB 3.0 to 2.5GbE adapters and it does not have the same performance issue]

    I own several adapters based on this Realtek chip design. Can you specify what one they sent you? Is their a specific model #? There are so many different vendors using this chipset family, it would be nice to have one directly from Realtek that doesn’t have issues.
    I have 3 dongles, all with a version of the 8156 family chip, one is the regular rtl8156, the other is the rtl8156b, and one is the dragon gaming version. They all behave differently, would be nice to have a uniformed performance for my network. Anyways, was the one they sent you made by Realtek? If so, how can I get my hands on it.

    Thank you!

    Reply

      1. Tested on Fedora 36, USB 2.5G after using 50-usb-realtek-net.rules. WHY ARE TX VALUES N/A?

        ethtool -g enp0s20u1
        Ring parameters for enp0s20u1:
        Pre-set maximums:
        RX:       4096
        RX Mini:    n/a
        RX Jumbo:    n/a
        TX:       n/a
        Current hardware settings:
        RX:       4096
        RX Mini:    n/a
        RX Jumbo:    n/a
        TX:       n/a
        RX Buf Len:       n/a
        CQE Size:        n/a
        TX Push:    n/a

        Reply

  14. Just used this article to set up my USB3 NIC. It looks much shorter and works fine:

    Reply

  15. I think you need to revisit this topic.

    I’ve gone through three different USB-C dongles that use the RTL8156 chipset.

    The latest one, which uses RTL8156BG (version 31.04), can sustain 2.48 Gbps…

    …but every so often it will drop/reconnect, and I will see this in my system log:

    The dongle does not even get warm. (I keep it cool with a DC-fan, that’s not even connected to the laptop, using a different power source.)

    It it “usable”? I guess? But in my opinion, it’s not acceptable if you take data integrity seriously, such as saving and editing files on a local NAS server.

    What happens if you let it run an indefinite iperf3 test?

    Do you notice it will occassionally “drop” (as seen with “0.00 bits/sec” and an entry of “carrier off” in your dmesg log?

    Reply

    1. I have such usb nic with version 31.04 and with Ubuntu 22.04 with newest HWA kernel 6.2.0 I have no problems at all.

      My tests are showing:

      [ 5][RX-S] 171.00-172.00 sec  280 MBytes 2.35 Gbits/sec                  
      [ 8][TX-S] 171.00-172.00 sec  280 MBytes 2.35 Gbits/sec   0  3.55 MBytes 
      I don’t see any drops or other performance issues even if I run iperf3 for hours.
      I’m using Cable Matters NIC from auction: https://www.amazon.co.uk/Cable-Matters-Ethernet-Adapter-Charging/dp/B0BKMPT6N3/ref=sr_1_3?crid=2KZT0EJVT86EP&keywords=cable+matters+usb+c+2.5&qid=1691526483&sprefix=cable+matters+usb+c+2.5%2Caps%2C87&sr=8-3

      This NIC looks very simple. I don’t see big radiators but it doesn’t seem to heat.
      I ordered one more NIC from same manufacturer to check it, but as usual, amazon sent me two cards from same manufacturer in two separate packages and I need to wait: https://www.amazon.co.uk/Cable-Matters-201095-Network-Adapters/dp/B08574CM8V/ref=sr_1_5?crid=2KZT0EJVT86EP&keywords=cable+matters+usb+c+2.5&qid=1691526634&sprefix=cable+matters+usb+c+2.5%2Caps%2C87&sr=8-5

      You can also try newest driver installable via dkms:
      https://github.com/awesometic/realtek-r8152-dkms. In my case, everything worked perfectly just with 6.2.0 kernel driver.

      Reply

    2. My card is connected directly to usb-c port of Dell laptop, without any hubs or docking stations.

      Reply

  16. Looks like the generic adapter is now being sold with RTL8156BG inside and for me it works perfectly on both Windows and Ubuntu (iperf3 shows 2.37 Gbps with zero fluctuations). My only complain is the flat cable but on the other hand it cost me just 7 bucks.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC