TL;DR: Will my Thinkpad X1 Carbon 7th gen use all 4xPCIe lanes for eGPU if I connect an USB-C device to another Thunderbolt port?
Full story:
I have a Lenovo Thinkpad Carbon X1 7th gen laptop (20QD model series). The laptop has two Thunderbolt/USB-C ports, and, reportedly, is able to provide 4xPCIe connectivity to one of them, or, if two Thunderbolt devices are connected, each one gets 2xPCIe (I read that info somewhere but can’t find it now).
The time has come and I want to connect an eGPU case to it, one that can use all 4xPCIe lanes (Razer Core X if that matters).
However, I like to have a lot of peripherals and I wish to connect a capable USB hub as well (like Baseus CAHUB-BG0G).
So, the big question: if I connect such a hub to the second TB/USB-C port alongside the eGPU, will the eGPU still be able to use all the 4xPCIe lanes, or will it be then limited to 2xPCIe lanes despite the fact that the other device does not consume them?
Does it matter if the second USB-C device is just a plain USB-hub one, or a device that uses the DisplayPort-in-USB-C tunneling and has display port/HDMI connections?
I do not see any reason why a Thunderbolt-Controller would statically partition its Host-Bandwidth, because by definition, it can dynamically partition the bandwidth of the Thunderbolt-Devices that are daisy-chained to it.
You should only lose that bandwidth the second USB or TB device is actively using.
But latency is a thing, so there might adverse effects, not due to limited bandwidth, but because the second device might keep the controller busy and thus sporadically delay some transaction of the GPU causing more jitter. I have no idea how much Quality-of-Service Thunderbolt-Controllers do and how latency optimized their implementations are.
Sadly, I do not have an eGPU-Enclosure to do my own tests…
But all of this should only affect USB or Thunderbolt-Devices. Displayport should be just passed-through the controller and thus not be noticeable on the other port (except that it has 1 less Displayport-Connection available for Docks etc.). On the other hand, outputting Display-Contents from the Notebook that are calculated by the eGPU (directly or with sth. like the Baseus Dock) will cost you lots of PCIe bandwidth, because the contents need to make it back through PCIe, where the IGPU will then convert it back to Displayport. All external displays should be exclusively attached to the eGPU to avoid this.
I see, thanks. No, I don’t intend to output DP data through that second port, I will just probably end up with a video-capable USB hub since those happen to be the ones with a decent port pool anyway (like the mentioned Baseus one). So the question is about the allocation, not usage.
Would the possible latency problem be different if I plugged the hub into an USB-A port that the laptop has instead? (I wonder if a video-capable hub expecting USB-C would go silly then…)
Those latency problems, if they exist at all, could only occur when the Thunderbolt-Controller is the USB-Controller (and it typically is only for the Thunderbolt-Ports). Depending on the generation or Notebook the Thunderbolt-Controller might only handle USB 3.x and pass 2.0 through to the chipsets native controller, or do both. (easily found out with USBTreeView when having USB-Devices attached).
While in my experience many USB-C devices do non-compliant things, they have worked for me on non-display capable ports. Most problems come up when connecting USB-C devices to USB-A. Because technically the devices should be able to handle the C-Connector orientation, but when both host and device are USB-C, the host does it, so some devices have no support for it.
(I have 1 HDD-Enclosure depending on host-port and the orientation of the USB-C connector you either get just USB 2.0 or nothing. But the other way around works perfectly).
Oh, that USB-C plug orientation thing is funny! However, that’d be of a minor problem for a hub that stays on the desk, as the plugging/unplugging would happen on the USB-A side anyway, so once I figure out the orientation, it will stay.
But I also have only used a TB-Dock and TB-Networking (and only once done a full bandwidth test with that, because my long cable is only 20GBit/s and my Desktop is limited to x2, because I want all of my SATA-Ports…)
I got the eGPU, it works well (system is a bit unstable, but acceptable).
The eGPU receives 4 PCIe lanes regardless whether the second TB3/USB-C port is used for a USB-C connection or not (GPU-Z, nVidia control panel and HWInfo64 all agree on that).
I ended up using the USB-A port for other peripherals after all, as it had slightly less latency using a somewhat silly ping over the Ethernet card method, and also because it shows up higher in the USB device tree and is not employing the TB controller at all.
So, the setup is really nice and for some reason, I’m actually getting a 3DMark score higher than most other owners of the seemingly the same GTX 1080.
Fascinating, that it shows a difference in ping, I would not have expected that.
That, I expected. Though it does not guarantee all the bandwidth exclusively for the GPU If multiple devices on bus are competing for it.
If you’d like to do more testing, I’d be very curious to hear what happens if you use the USB host ports of the dock for some network or file transfers (iperf, ping) while running a GPU-PCIe bandwidth test like 3DMark’s. If there is some kind of QoS I would expect the network / file transfers to suffer and have more jitter, if there is not, i would expect all of it to suffer equally, which would probably be very bad for frametimes.
