Demystifying USB-C Complexity Through a 10G Ethernet Lens

We have been told for a decade that USB-C is the universal port. In a physical sense, that is true. It is a neat, reversible connector that fits into our laptops, phones, and tablets. But beneath that uniform sheet-metal shell lies a chaotic matrix of protocols, alternate modes, power delivery profiles, and host controller quirks.

The release of the WisdPi 10G Ethernet Expansion Card for Framework laptops serves as a perfect case study of this hidden complexity. Priced at $99, this tiny module promises to cram 10 Gbps networking directly into a standard Framework expansion slot. However, the engineering compromises required to make this work reveal why targeting high-performance USB-C peripherals is a minefield for systems developers and hardware engineers alike.

The Protocol Overhead Bottleneck

To understand why this module is so complex, we have to look at the silicon inside. The WisdPi card uses the Realtek RTL8159 Ethernet controller. To deliver a full 10 Gbps of network throughput, the RTL8159 requires a USB 3.2 Gen 2x2 connection, which provides a theoretical signaling rate of 20 Gbps over two lanes.

This requirement highlights a fundamental truth about USB protocol overhead. You might assume that a 10 Gbps USB connection (USB 3.2 Gen 2x1) would be sufficient to feed a 10 Gbps Ethernet port. It is not. USB is a highly transactional, packetized protocol with significant encapsulation overhead. When you factor in physical layer encoding (such as the 128b/132b encoding used in Gen 2), packet headers, flow control, and host controller latency, the actual usable payload bandwidth of a 10 Gbps USB link drops significantly.

If you plug this 10G module into a port that only supports USB 3.2 Gen 2x1, or even certain USB4 implementations that do not backward-compatible tunnel Gen 2x2 correctly, the connection bottlenecks. The bandwidth caps out well under 8 Gbps.

xychart-beta
    title "Real-World Throughput (Gbps)"
    x-axis ["Gen 2x1 / USB4 Bottleneck", "Gen 2x2 (Default Driver)", "Gen 2x2 (Optimized Driver)"]
    y-axis "Throughput (Gbps)" 0 --> 10
    bar [7.5, 7.0, 9.4]

For developers building high-throughput peripherals, this means you cannot design for the nominal speed of the network interface. You must over-provision the host interface bandwidth by nearly 100% just to saturate the line.

The Software Stack and Kernel Drift

Hardware capability is only half the battle. The software stack must also align perfectly, and this is where Linux developers frequently run into roadblocks.

During testing of the WisdPi module on a Framework laptop running Ubuntu 26.04 with a modern Linux 7.x kernel, the operating system successfully negotiated a 20 Gbps connection. Running lsusb confirmed the port was operating at 20000 Mbps. Yet, running iperf3 yielded only 7 Gbps of throughput.

# Checking negotiated speed on Linux
$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 20000M

The issue lies in driver optimization. The default, in-box Linux driver for the Realtek chip does not fully optimize the controller's register settings for maximum throughput. Attempting to compile the official, proprietary Realtek driver to fix this resulted in compilation errors because the driver source code had not yet been updated to support the API changes in the newer Linux 7.x kernel.

On Windows 11, a similar pattern emerged. The default Microsoft-provided driver capped performance at the same 7 Gbps mark. Only after installing the dedicated Realtek vendor driver did the throughput jump to its real-world maximum of 9.4+ Gbps.

This is a critical lesson for systems developers: never assume that OS-native drivers will extract maximum performance from high-speed silicon. When writing software that relies on external high-speed interfaces, you must account for driver-level optimizations that may not be present in upstream kernels.

The Thermal Realities of High-Speed I/O

Another major constraint when dealing with high-performance USB-C peripherals is heat. Converting 10G Base-T Ethernet signals to USB packets requires a significant amount of processing power, which translates directly into thermal dissipation.

The WisdPi module gets hot. Under sustained load, the bottom plastic surface of the module can reach temperatures close to 70°C. While WisdPi notes that this complies with the IEC 62368-1 temperature safety limits (which allow higher temperatures for surfaces touched for less than 10 seconds), it is far from ideal for a device meant to sit on a user's lap.

When designing compact peripherals or writing software that drives them, thermal throttling is a real-world constraint. If a device gets too hot, the hardware controller will scale back its clock speeds to prevent damage, causing sudden, unpredictable drops in software performance. Developers must design their applications to handle these hardware-induced performance drops gracefully.

The Developer Takeaway

The WisdPi 10G Ethernet module is an impressive feat of miniaturization, but it serves as a warning for developers. USB-C is not a guarantee of performance; it is merely a physical gateway.

When building applications that depend on external high-speed peripherals, you must design for the worst-case protocol negotiation, actively manage driver compatibility across kernel versions, and expect thermal constraints to impact your real-world throughput. For most users, a standard 2.5 Gbps adapter remains the more practical choice, but for those who truly need 10 Gbps, the WisdPi card shows exactly what it takes to push the physical limits of the USB-C interface.