I’m talking about a situation where there are just two devices connected to a switch and no other network traffic at all. Any other pair of devices I’ve tested under those conditions gives me zero retries; the Vero 4K+ talking to nearly everything gives me some. Sometimes it’s only a handful, but sometimes you get 50 or 100 in a single second.
Other than a few more retries than I might have expected, it seems to have more or less settled down, now. I’ll bug you if it goes weird again. 
If there’s congestion, there will be a retry and then the window size will wind down to accommodate the receiving device.
It’s possible there’s still some work that needs to be done with the driver.
Sam
@sam_nazarko, if you have some spare time (hah!) you might perhaps try installing the latest Leia test build on a 4K+, then reinstalling the basic August Krypton build from SD card, and manually installing updates in My OSMC - see if that causes any slow-down. It has done that more than once on my box.
You’re not meant to downgrade from Leia to Krypton. This is an unsupported upgrade path. You would need to reinstall OSMC completely from Download - OSMC.
Slow performance in the August image is probably caused by a Bluetooth bug. You can turn off Bluetooth and it will work properly again. Will be fixed in Sunday’s update.
I meant doing precisely that. That’s what caused my slow-down. Doing that after having installed Leia.
Probably Bluetooth as explained above.
How does one enable jumbo frames on the 4K+? Or are they enabled automatically?
Current max frame size is about 3500 bytes. With default MTU I have no issue — why do you need jumbo frames?
Do you need to know why in order to answer my question?
From what you say, it sounds like the answer is either “you can’t” or “they’re already as enabled as they’re ever going to get, by default” in which case, fine, that’s all I need to know.
EDIT: If you must have a reason, I normally have jumbo frames turned on for some other devices on my network, because it slightly speeds up large file transfers (at the cost of sightly increased latency). I’ve found in the past that things sometimes go more smoothly if all devices on the LAN have the same frame size, so I’d like to ensure consistency. If that means turning off jumbo frames on everything else, fine, but it’s good to know what the options are.
I tried enabling jumboframes to my NAS, and it did not provide any real enhancement. The only thing I realized is that when copying a large from/to my NAS from my desktop, the NAS load went up straight to 10 or so (NFSv4 / parallel streams + Jumbo frames). During that time, barely any other device could access the NAS.
Transwer was very fast indeed, but I couldn’t explain the behavior of my NAS.
Also - because the Vero could not use 9K Jumbo-Frames, I stopped the experiment there and went back to 1500Bytes. Works smooth.
Note that I get 940Mbps in both directions. And - I do know that my network is Ok as I put Cat6 Cables into all Walls in this house, and using a decent Zyxel Switch which does a very good job (Even though only 1Gbps).
Im my carrer on Monitoring systems, we noticed (at work) that bad equipment is usually the cause for weird traffic behavior. This applies to routers, switches, network Taps and traffic aggregators. No device is 100% perfect. And the worst part is non fatal errors as spotting these is the hardest.
We had once a network cable which was causing immense issues. We noticed it only after we put our Monitoring system in place and noticed that the problems happened only at a certain time. When we were looking at the generated graphs, the secretary of the group just said: oh - that looks like the TGV schedule (It is the high speed train in france). Funny thing was, the tracks were just next to the building, and the building vibrated because of that. And - indeed, we replaced all equipment on both ends thinking one of the electronic devices was the cause, until there was only the network cable left. When we replaced that one, all weird issues with the networking were gone.
We would never have imagined in our wildest dreams that vibrations could cause that on a network cat6 cable!
That was an extreme case, but nevertheless very valid. The looks on everybody’s faces (including mine) was really fun. Customer had that issue for 3 years, and it took us 3 days to identify and fix it. But hey, without the secretary we would never have had the link to the TGV 
and the vibrations.