Not all OCuLink eGPU docks are created equal
jeffgeerling.com116 points by speckx 3 days ago
116 points by speckx 3 days ago
I understand the focus on the cables, and as an owner of several Minisforum devices, IME they don't really do compatibility very well (e.g. linux on V3). Their specialty seems to be taking reference PCB's, down costing them by changing/removing components, and then putting them in very unique enclosures. They're one vendor I would avoid considering - unless it's x86.
I can't speak for the V3, but Minisforum's AMD mini PCs (at least from the Zen 4 onwards) all have excellent Linux compatibility. I have the UM780 XTX and it's been a blast using it on Linux (Arch btw). A mate has a UM790, another bought a recent Ryzen AI Max one and they've all reported excellent Linux compatibility (running Fedora-based and Arch-based distros).
The only issue is the lack of regular BIOS/firmware updates. My UM780 got around 5 updates post-release, but they haven't released any new updates since last year March last year... which isn't great if you care about firmware security. In my case however it's not a big issue as it's an isolated vlan and I use mine on my for dev/test/homelab stuff.
The one AMD x86 box I got from them occasionally randomly segfaulted and would blackscreen and hang if left on on after anywhere from 45 minutes to a few hours. I read that it might be a driver issue in proxmox debian and tried running windows on it and had the same issue. Oddly memtest passed on it while running repeatedly for 3 days strait before shutting down unexpectedly.
Its kinda made me hesitant to trust any of these cheap minipcs ever again.
I bought three of them for a Kubernetes cluster and it seems to work great for a few days and then constant black screens every few hours to few days. The most frustrating part is thinking I fixed it with a bios change or different software, but it keeps coming back. Never again.
Try disabling C states in the bios. My 5950x developed that issue, as did a friends 5600x.
Ive had very similar issues with my UM790 pro. I even RMA’ed it and the replacement ran into the same issue. It gets corrupted somehow if I leave it running overnight.
I love the hardware Minisforum makes, but man, this company ongoingly sets consumer expectations lower and lower.
I haven't checked in the past year, but historically Minisforum has been awful about having bios updates, doing so seemingly only when truly needed.
I just ordered the BD790i X3D mainboard. A while ago Minisforum has been known for their slow BIOS updates, but hope that they have improved their processes since. I'll see…
In my experience, incompatibilities like that have for the most part been due business partnership decisions. Let me give you an example. A company that designs motherboards may state that one board should be compatible with a full range of other hardware in the market, e.g. RAM, PCIe, M.2, etc. The reality is that they usually partner and/or are locked into certain vendors, contractually, that supply them with their products for the board. You can see this in their products spec pages, in a section titled, "Support List," with a warning that should you deviate from this list, they will not guarantee 100% functionality. Basically, the company tests each product that they list, and if does not work properly, they either tweak the board, its firmware, or communicate this to the third-party vendor to see if they can provide a solution. Most companies that sell these boards or devices more often than not, are small, do not have enough R&D funds, or manpower to do the proper research, testing and adjustments to their products, since devices are already 6 months behind current technology when they are released into the wild. Usually, customers can call into the company's support line and report the problem. The company may or may not address the incompatibility of their board with the third-party product if they see that there is potential for increased sales should the third-party device prove to be a trending product, or the customer is a high-volume order customer. More often than not, the incompatibility is not properly addressed.
Just my thoughts :|
Are they actually extra? Or does the other cable simply route them over coax? Answer here is to grab a couple SFF-???? Breakout boards, a scope, and a signal generator.
Another thing to consider is isolating all but the first PCIe lane.
> Answer here is to grab a couple SFF-???? Breakout boards, a scope, and a signal generator.
Yeah, I've considered buying an extra adapter and just probing pins — I don't have a spare M.2 to OCuLink adapter but will probably order a few different models to see if there are any differences there too.
> Another thing to consider is isolating all but the first PCIe lane.
The Pi nicely does that for me ;)
Haha, touché- forgot the Pi5 only has a single lane.
The comment came out of knowing if the cable's a little dodgy the timing could be off- scrambling the PCIe signals (easier to just tape it off than look up if its supposed to matter and then tape it off anyway), and the fact my first HBA had the "QC pass" sticker prevent some lanes from connecting and the whole card was unresponsive as a result.
I've actually been dealing with this myself recently, but only the gpu portion. I've been trying to get a gpu working on the orangepi RV2 just to see if I can. The tools for building the kernel for orangepi are kind of bad though.
But no, the 2 old amd gpus I have just don't show up at all in lspci, testing the RTX 2080 and RX 7800 both did show up though.
I can’t seem to find the answer about this, is there anyway to get an oculink through the x4 slot on framework desktop?
If you mean "can it be done with the connections" the answer is yes, as there are many PCIe x4 add-inboards for an external oculink port on the market.
As for framework's desktop specifically, their site says this about the PCIe x4 slot:
>1 x PCIe x4 slot (not exposed on default case)
No opening in the back of the case for an expansion card that exposes ports. My guess is you would be best off putting the mainboard in a different case, but alternatively you could either:
(A) Cut a big hole in the back that can expose an AIB with an external oculink.
(B) Use an internal oculink, and cut a smaller hole (anywhere you want) to run the oculink cable through.
You mean like fish a cable through the case? It looks like it might be doable based on the pictures. If its in the right spot, you might even be able to 3D print a cable gland or something at the case. Hard to tell based on the pictures.
i had a nuc with an eGPU, connected via a simple usb/thunderbolt connection, and I recall it was a nightmare to setup
I have read that thunderbolt and oculink are very different in this regard. Whereas thunderbolt devices can be plugged in at anytime, the oculink needs to be plugged at boot time. This seemingly innocuous detail is the catalyst as to the reason why oculink is better performing. It comes down to PCIe vs Thunderbolt in general.
While PCIe as a standard allows for hot swapping I would be quite surprised to learn that any motherboard or GPU supported it. At least in the consumer space
Lenovo's TGX 'extension' (I guess? It was for their eGPU solution) allowed hot swap, but support for it is definitely not very broad.
AFAIK oculink is pretty much pure pci-e wiring while thunderbolt has a whole protocol much like USB that adds some overhead.
I used an eGPU with a 2013 MBP for gaming, it was great when my other machine shat itself.
The other machine was also a NUC the "Skull Canyon" and it was much more finicky about using the eGPU.
Same for my wife's old Mac Mini. Finally gave up on it and bought her a new M4 Pro
I just bought an external thunderbolt eGPU box (even thought it'll never support a GPU with its mini form factor) to host a blackmagic 4k display card. Luckily, I'm still on the last gen i9 CPU so it worked right out of the box once I found the slightly older software. I've read people have issues getting it to work on the M* series chips though.
I use a eGPU via USB4/Thunderbolt (I think it's the same? Not entirely clear). Works out of the box on Linux. No real setup needed. Main downside is that removing it tends to make the system somewhat unstable and lock up (sometimes hours later) after a kernel "oops". I need to look into that because it's probably a relatively minor Linux kernel issue. But minus that: it works great.
Why use an egpu with a raspberry pi? all the games are x86 based. LLMs?
GPU compute? That said you can play x86 games using something like box64/box86
Vulkan works, so you can get llama.cpp fully accelerated, and many x86 games do run fine through FEX-Emu and/or box86/64.
I like how the comments section on Jeff Geerling's website now looks exactly like an HN thread. I did a double take, haha!
It's spartan, text-focused, and threaded; I've enjoyed having nice tidy threads, and the comments often contain a lot of great nuggets of wisdom over the years (which is also why I leave them open as long as possible).