Hallelujah.

Preach it!

Yes but also no. Originally MIMO, or multi-in, multi-out, was what is now called SU-MIMO, or single user MIMO. In wireless AC, they did multi-user MIMO on the access point transmission side, then AC wave2 brought it to the client as well. Wi-Fi 6 should have MU-MIMO supported on all points, but I forget if it's a requirement of the spec or just a feature. In the later case, manufacturers would not have a requirement to include it.

The difference is in how many nodes are "talking" at once. They use beam forming to enhance signal strength where the recipient node is, which sacrifices signal strength everywhere else. That's SU-MIMO. This came with the promise of MU-MIMO, which is using beam forming to transmit different messages to multiple nodes at the same time. Which effectively doubles throughput for that duration, but also requires very specific conditions in an environment that's constantly changing, especially for mobile phones. Tapping the screen or rotating the device slightly could put your device into a situation where MU-MIMO may start or stop working. Millimeters of travel can be the difference here. Even a laptop slightly shaking from someone bumping the surface it's on, or someone typing on the keyboard could affect it. It also may not.

The point is, MU-MIMO is great when it works, but you have no reasonable promise that you'll get any benefit from having it. It's especially useless in areas with a lot of reflections. But I digress.

The game changer tech is coming with WiFi 7 and multi link operation, we can basically go to a pseudo full duplex operation on Wi-Fi using it, which would be a huge boost for overall speed.

I'm side tracked. The issue you have on your friends network has nothing to do with the wifi. It is a matter of contention. Your upload usage is basically causing drops, or at least significant delays, for other traffic going up to the Internet. So when the client device requests to download a file, or a webpage, or a document, or start a media stream or whatever, the request can't go out, and every so often the downloading client needs to tell the server "I have this data, send me more" and those messages (called acknowledgments) are not going through.

Two options to fix this. The easiest is to turn off your torrent software. If you must have it on, when the network is dormant, do a speed test, and set an upload limit in your software for less than the upload of the connection. 75% is probably a good place to be, so if they have 10mbps upload, set your software to 7.5mbps. (be weary of Mbps vs MBps) The other option is going to be a bit more involved and depending on what hardware your friend has, may not be possible at all. This will, however, permanently fix the problem moving forward, both with your computer on his network, but also with everyone else's. Implement QoS. Some routers can fall over in terms of performance with QoS on, so your mileage may vary, and there's no guarantee that QoS is even available on their router. If it is, you need some basic settings in place for it to work correctly, most importantly, it needs to know how fast the upload and download are for the WAN. I would also build in a margin here, and only enter about 90% of the actual speed of the connection, the overhead will be used for high priority traffic when the link is otherwise fully occupied. My recommendation, if you have the option, is to set QoS to drop instead of buffer. This reduces buffer bloat, and the information that's getting dropped can and will be retransmitted (calling back to those acknowledgments I mentioned earlier).

QoS if implemented correctly will prevent the connection from being over saturated by any one thing, and traffic will continue in a high bandwidth use situation. It will still be impacted by how much is going on, but it should at least function. Acknowledgments usually have a slightly higher priority than other traffic, so those should be sent before other traffic.

Good luck.