Realtek RTS5490: USB4 ports, bandwidth and Linux diagnostics

A 40 Gbps dock can contain ports with different data capabilities. That matters when an external SSD holds your build directory, a display uses the same dock, and a slow transfer sends you looking for a driver problem.

Realtek's RTS5490 is a USB4 hub controller with a mixed downstream port design. Understanding this port layout helps you choose a port and trace connection problems. The specifications below come from the manufacturer; the diagnostic procedure is proposed, not a report of testing RTS5490 hardware.

The RTS5490 port map

Realtek's February 2025 announcement describes this configuration:

Function	Published configuration
USB4	40 Gbps; one upstream port and two downstream ports
Additional USB ports	Two USB 3.2 Gen 2x2 downstream ports
DisplayPort	Version 2.1, one input and one output
Integrated controllers	USB PD 3.2, a PCIe switch and a USB 3.2 host controller

These are chip capabilities, as stated in Realtek's RTS5490 announcement. A finished dock still needs its own port map, display specifications and power ratings.

In particular, the four downstream USB ports are not interchangeable. Check the dock's manual before attaching a peripheral that requires a USB4 path. A USB-C socket describes the connector; it doesn't by itself establish the data protocol or power capability. USB-IF's USB Type-C terminology guide separates those properties explicitly.

During debugging, compare the dock's documented port map with the path reported by the operating system. For an implementation example, PURPLELEC's RTS5490 dock overview describes the TU001M1's USB4 and USB 3.2 downstream connections.

Follow the connection back to the host

USB4 can carry USB 3.x, PCI Express (PCIe) and DisplayPort traffic through protocol tunnels. A tunnel carries one protocol's traffic over the USB4 connection, so the operating system can work with the corresponding device stack. Microsoft's USB4 design requirements describe that relationship.

For troubleshooting, start with this simplified data path:

Host USB4 router
        |
One negotiated upstream USB4 link
        |
Dock controller
        |
Selected downstream path
        |
Peripheral

This is a connection model, not a chip block diagram. Check each connection in order. Establish the host port's documented capability, identify the upstream cable, then check the chosen downstream port and peripheral.

Record the active protocol when reporting the issue. A device working in a fallback USB mode proves that a connection exists; it doesn't establish that the intended USB4 path is active. USB-IF describes compatibility as a connection that adjusts to the participating devices' common capability in its USB4 language guide.

Budget bandwidth in the direction of the transfer

The same USB-IF guide describes multiple data and display protocols sharing the available bus bandwidth. Adding downstream ports does not add independent upstream links to the host.

A simple calculation helps keep the units straight:

40 gigabits per second / 8 = 5 gigabytes per second

That is a unit conversion, not an SSD benchmark. Protocol overhead, the storage path and the workload affect application throughput. It would be incorrect to turn the calculation into a promise of 5 GB/s file copies.

Consider a deliberately simplified example: two peripherals each request 24 Gbps toward the host through one nominal 40 Gbps upstream connection. Their combined demand is 48 Gbps. That exceeds the link's nominal capacity even before overhead. The numbers illustrate contention; they are not RTS5490 measurements.

Direction matters. Keep host-to-device traffic separate from device-to-host traffic when reasoning about a link. Reading an SSD and sending pixels to a display do not automatically consume the same directional budget. Windows also manages bandwidth reservations for tunnels, so a useful test records the display mode and transfer direction rather than assuming that every attached monitor removes a fixed amount of SSD throughput. Microsoft documents its bandwidth allocation policy.

Read display and charging claims separately

DisplayPort version, DisplayPort link rate and USB4 link rate are different entries in a specification sheet. For example, VESA defines UHBR20 as 20 Gbps per lane, giving 80 Gbps across four DisplayPort lanes. That number describes the DisplayPort link. It does not establish an 80 Gbps USB4 connection or prove that a particular chip implements UHBR20. VESA's UHBR explanation provides the rate definitions.

USB4 itself also has faster implementations: USB4 Version 2.0 introduced support for 80 Gbps. Check the product's stated link speed as well as the protocol name.

For a display, request the supported resolution, refresh rate, color depth and simultaneous monitor configuration. Ask whether that configuration requires Display Stream Compression (DSC). A version number alone leaves those questions open.

Power needs a separate check. USB Power Delivery (USB PD) negotiates power between devices. USB-IF states that revision 3.1 expanded the specification's ceiling to 240 W, with corresponding cable requirements. That ceiling is not the power every dock guarantees to a laptop, even if the dock supports a later PD revision. USB-IF's Power Delivery overview explains the distinction between power levels and device requirements.

For a finished product, ask how much power the dock can deliver to the laptop while its other ports are in use. A controller supporting the negotiation protocol still relies on the dock's power supply, power circuitry, cable and receiving device. An adapter rating alone leaves the dock's own consumption and peripheral power budget unaccounted for.

Inspect what Linux actually exposes

Run these commands on the Linux host connected to the dock. The first requires usbutils:

lsusb -t

The usbutils manual defines this as a USB device tree view. It helps identify USB devices and their parent connections. It is not a complete view of USB4 routers and PCIe tunnels, so its speed labels should not be used alone to verify the dock's upstream link.

Linux exposes USB4/Thunderbolt information through sysfs. The following loop only reads attributes that exist and are readable:

for dev in /sys/bus/thunderbolt/devices/*; do
    [ -d "$dev" ] || continue
    printf '\n%s\n' "$dev"
    for attr in device_name generation rx_speed rx_lanes tx_speed tx_lanes; do
        if [ -r "$dev/$attr" ]; then
            printf '%s: ' "$attr"
            cat "$dev/$attr"
        fi
    done
done

The Linux sysfs ABI defines generation=4 as USB4. It also defines rx_speed and tx_speed as speeds per lane. Read them together with rx_lanes and tx_lanes.

For example, a reported 20 Gbps per lane with two active lanes represents a nominal 40 Gbps in that direction. This is an interpretation example, not captured output. Match the sysfs entry to the intended dock before using its values; other entries can describe another device or domain. Missing entries or attributes mean that this view does not provide the answer on that system.

Device discovery and PCIe authorization are separate checks. Linux documents security modes that restrict PCIe tunneling. Review the system's existing policy if a PCIe peripheral is absent; don't change authorization or disable security merely to make a benchmark run. The Linux USB4 and Thunderbolt guide explains those controls and their risks.

On Windows 11, the corresponding starting point is Settings → Bluetooth & devices → USB → USB4 Hubs and Devices on supported systems. Microsoft introduced this view in build 22621.1778. Its visibility depends on host-router detection and platform configuration, so an absent page is not sufficient evidence of a bad dock. Microsoft's USB4 settings documentation covers those conditions.

Test the configuration you intend to use

Keep the SSD, test data and software settings consistent. Change one part of the connection at a time:

Comparison	What it helps investigate
Peripheral connected directly, then through the intended dock port	Whether adding the dock path changes the result
Same setup with another cable rated for the intended link	Whether behavior follows the upstream cable
One transfer, then two transfers in the same direction	Whether concurrent demand affects throughput
Display disconnected, then connected at the target mode	Whether that display configuration changes available functions or performance
Initial connection, then normal suspend and resume	Whether discovery or reconnection changes across a power transition

These comparisons narrow the investigation. A slowdown during simultaneous transfers does not, by itself, identify a defective controller. Equally, a single successful file copy says little about reconnection or the intended monitor configuration.

A useful issue report includes the dock model and firmware, host model and operating system, exact ports and cables, active display mode, link information, transfer direction and steps that reproduce the symptom. Capture that information before changing drivers or firmware. It gives the next person a configuration to examine instead of a claim that “the RTS5490 is slow.”

Prepared with AI assistance using the linked technical sources. No RTS5490 hardware benchmarks or test results are reported here.