Thanks – that’s helpful.
Sam
Try:
wget https://collab.osmc.tv/s/0DXtBTKuDquL3mz/download -O dtb.img
sudo dd if=dtb.img of=/dev/dtb bs=256k conv=sync
Then halt and do a cold boot.
Does it make the performance more consistent?
done.
but my SSH doesn’t connect anymore…
Kodi opens, but scrolling through Network is now too slow.
So seems worse
(losing more pings too)
What’s the factory reset without SSH?
tx
cr
sudo apt-get install --reinstall vero364-image-3.14.29-117-osmc
and without working SSH ? …
got the ssh promptonce, but just toooooo slow to do anything.
I could download to µ-SD card add USB keyboard, … but how do I enter a Terminal from Kodi?
tx
cr
Connect a USB keyboard, exit Kodi and press ESC on the keyboard should get you a command prompt.
1 Like
Tx bmilham, indeed 
Three different options:
-
Connect to Wifi with My OSMC and use SSH to connect to the device while on Wifi then turn off Wifi after the kernel is downgraded. (You might need to unplug Ethernet during this time)
-
Plug in a keyboard and hold down CTRL as soon as you see the blue screen with the OSMC logo until you see a login prompt - log in with the keyboard.
-
Choose exit from Kodi, when you see the blue screen and OSMC logo press ESC then log in with a keyboard. (Quickly - you have to do it within 30 seconds or you will go back to Kodi)
2 Likes
FYI accessing the box via USB keyboard, Iperf gives 100KB… first packet
then all 0 Kbs…
so broken Network
Wild speculation follows. 
@sam_nazarko, I asked about optimising for receiving data over transmission because I’m wondering if the 4K+ ends up being so busy processing incoming packets that it has no time to send an acknowledgement back to the source saying “TCP packet received”.
My limited understanding is that if the source doesn’t receive any acknowledgement that a TCP packet reached its destination, it will send out the same packet again, and then keep retrying until it gets a response. So it’s not just that not acknowledging quickly slows things down in itself, it’s that not acknowledging quickly generates more packets to process.
If the 4K+ is too busy to acknowledge, the the source will generate more and more duplicate packets for the same data, and maybe the 4K+ will be too busy processing those duplicate packets to ever acknowledge anything; and that keeps going until the source slows down the flow rate enough for the 4K+ to be able to respond. (And at that moment the throughput chokes).
Precisely because there is so much more data to receive then transmit, it seems to me that allowing transmitting to have a higher priority than receiving won’t actually slow receiving down very much - you’ll get a packet dropped and retried sometimes, but probably not more than once per packet, because after each packet is acknowledged, the 4K+ has nothing else to send until the next packet arrives.
It’s very possible this all makes no sense. But I’m curious as to what it would do to the throughout if you actually reversed that, and gave Tx priority over Rx.
Done, back like before
tx
cr
No – that won’t be the issue.
The RX → TX changes are only in staging currently.
I would not go into details here. But the ACK not reaching the remote party will cause a downsizing on the Sliding Window (Sliding window protocol - Wikipedia).
For dummies - if the transfer speed is fast, the sender will send say 90 packets before expecting a ACK from the remote side. If the ACK won’t come, it will slow down and reduce the window size to expect an ACK after 45 packets etc. In the end, it will be one packet sent, one ACK expected. Which is also very slow - as both sides will have more chit-chat to perform.
There one other thought I had…
Any of you have explicitly disable IPv6? I have a vero with no problems, but in my LAN IPv6 is completely disabled. I just remembered that I disabled it because I had performance issues with it enabled some time ago (well, when IPv6 was still young).
will there be any ethernet-fixes in the september update? testing almost a lot… and its not getting better. if a cheap usb adapter works well, i think the problem is somewhere in the 4k+… my old vero 4k has a better ethernet performance in the same network as the new one.
We will keep improving the driver, but you may have a hardware problem. The majority of users are not affected.
Does dropping to 100Mbps improve the performance?
Sam
dropping to 100mbps with:
sudo ethtool -s eth0 speed 100 duplex full autoneg on ?
Yes. It does look like you get over 100Mbps constantly however. Does it ever drop below this?
osmc@osmc:~$ sudo ethtool -s eth0 speed 100 duplex full autoneg on
osmc@osmc:~$ iperf3 -c 192.168.178.85
Connecting to host 192.168.178.85, port 5201
[ 4] local 192.168.178.81 port 52435 connected to 192.168.178.85 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 12.4 MBytes 104 Mbits/sec 0 215 KBytes
[ 4] 1.00-2.00 sec 11.8 MBytes 99.3 Mbits/sec 0 322 KBytes
[ 4] 2.00-3.00 sec 11.7 MBytes 98.2 Mbits/sec 0 399 KBytes
[ 4] 3.00-4.00 sec 11.6 MBytes 97.3 Mbits/sec 0 485 KBytes
[ 4] 4.00-5.00 sec 11.7 MBytes 98.4 Mbits/sec 0 567 KBytes
[ 4] 5.00-6.00 sec 11.7 MBytes 98.1 Mbits/sec 0 635 KBytes
[ 4] 6.00-7.00 sec 11.5 MBytes 96.3 Mbits/sec 0 699 KBytes
[ 4] 7.00-8.00 sec 11.1 MBytes 93.5 Mbits/sec 0 765 KBytes
[ 4] 8.00-9.00 sec 11.2 MBytes 94.3 Mbits/sec 0 817 KBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 94.4 Mbits/sec 0 864 KBytes
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 116 MBytes 97.4 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec receiver
iperf Done.
osmc@osmc:~$ sudo ethtool -s eth0 speed 1000 duplex full autoneg on
osmc@osmc:~$ iperf3 -c 192.168.178.85
Connecting to host 192.168.178.85, port 5201
[ 4] local 192.168.178.81 port 52438 connected to 192.168.178.85 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.20 MBytes 35.2 Mbits/sec 67 2.83 KBytes
[ 4] 1.00-2.00 sec 7.65 MBytes 64.2 Mbits/sec 39 9.90 KBytes
[ 4] 2.00-3.00 sec 5.27 MBytes 44.2 Mbits/sec 75 4.24 KBytes
[ 4] 3.00-4.00 sec 2.52 MBytes 21.1 Mbits/sec 40 4.24 KBytes
[ 4] 4.00-5.00 sec 2.67 MBytes 22.4 Mbits/sec 37 5.66 KBytes
[ 4] 5.00-6.00 sec 5.25 MBytes 44.1 Mbits/sec 74 4.24 KBytes
[ 4] 6.00-7.00 sec 7.34 MBytes 61.5 Mbits/sec 71 7.07 KBytes
[ 4] 7.00-8.00 sec 3.12 MBytes 26.2 Mbits/sec 51 2.83 KBytes
[ 4] 8.00-9.00 sec 3.90 MBytes 32.7 Mbits/sec 48 2.83 KBytes
[ 4] 9.00-10.00 sec 4.54 MBytes 38.1 Mbits/sec 63 4.24 KBytes
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 46.5 MBytes 39.0 Mbits/sec 565 sender
[ 4] 0.00-10.00 sec 46.1 MBytes 38.7 Mbits/sec receiver
iperf Done.
worst result ever 
So if you switch from 1G (automatic) to 100MBPS back to 1G the connection degrades?
Basti,1988, do you see the same ‘temperature’ related changes, as your iperf looks like mine…
(how I tested: Halt the device 10 mins, and right after boot run iperf, I got 200-300Mbps, while after running a movie for coupe of mins, it drops to <50Mbps)
cr