Full speed with adapter attached only if the file looks like this (first line must be removed = net.ipv4.tcp_sack=0):
(...)
# tcpsack fixes (temporary)
net.ipv4.tcp_mtu_probing=0
Full speed with adapter attached only if the file looks like this (first line must be removed = net.ipv4.tcp_sack=0):
(...)
# tcpsack fixes (temporary)
net.ipv4.tcp_mtu_probing=0
OK – thanks for letting me know
Sam
I can confirm that after June update the iperf3 shows no change in NAS -> Vero 4K+, but severe degradation to the Vero 4K+ -> NAS nitrate results.
No problem with stutter or buffering with 4K HDR or other content.
Should I proceed to the solution 2 posts above or no need for that?
If you aren’t seeing any playback issues, it’s probably wise to leave things as they are. When Sam pinpoints the issue then an update will likely be pushed to all.
Hi,
Are you running iperf3 -s on NAS and iperf3 -R -c (IP of your iperf3-server) command from Vero? It is the combination when I saw degradation.
Clarifications:
iperf3 -s on NAS (NAS ip 192.168.1.3)
iperf3 -R -c 192.168.1.3 on Vero 4K+
This combination shows no change: maximum attainable bitrate.
iperf3 -s on Vero 4K+ (Vero 4K+ ip 192.168.1.4)
iperf3 -R -c 192.168.1.4 on NAS
Degradation to attainable bitrate comparing to may update.
Ok,
I have opposite situation, but unlike you I am using Vero 4K and an ethernet to usb adapter.
Ok, my fault. I have read your posts and got the impression that the reverse connection (Vero to NAS) was problematic for you too. And I was wondering why this caused you problems with stuttering.
Nevertheless, I think that something has changed and created the reverse bitrate problem.
Let’s wait for Sam’s response.
I think that your 6th post is the one that confused me. I think that the descriptions should be reversed.
Sorry for that, I rarely use iperf3 and I have never experienced such weird behavior in networking.
Very good detective work!
I think your problem is in some way related to the large number of retransmissions you are seeing. For example:
osmc@osmc:~$ iperf3 -R -c 192.168.1.4
...
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 298 MBytes 250 Mbits/sec 6543 sender
[ 4] 0.00-10.00 sec 296 MBytes 248 Mbits/sec receiver
That averages 654 retransmissions per second, so it seems that something isn’t working corrrectly, possibly beacause of excessive buffering, flow control or even because you’re not picking up the correct driver. By disabling the selective ACK mechanism, it looks like it has made the situation even worse, since a lot more data now needs to be retransmitted.
The retransmissions only seem to be one way: data transmissions to the Vero4K. The other way, showed zero retransmissions:
sojer2005@Synology:~$ iperf3 -R -c 192.168.1.90
...
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 222 MBytes 187 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 220 MBytes 184 Mbits/sec receiver
Is this still the case?
Yes it is. But the transfer is fine and no buffering while playing files (after editing /etc/sysctl.d/100-osmc.conf file and removing net.ipv4.tcp_sack=0 line).
osmc@osmc:~$ iperf3 -R -c 192.168.1.4
Connecting to host 192.168.1.4, port 5201
Reverse mode, remote host 192.168.1.4 is sending
[ 4] local 192.168.1.90 port 49528 connected to 192.168.1.4 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 32.9 MBytes 276 Mbits/sec
[ 4] 1.00-2.00 sec 26.0 MBytes 218 Mbits/sec
[ 4] 2.00-3.00 sec 32.7 MBytes 274 Mbits/sec
[ 4] 3.00-4.00 sec 33.0 MBytes 277 Mbits/sec
[ 4] 4.00-5.00 sec 34.1 MBytes 286 Mbits/sec
[ 4] 5.00-6.00 sec 33.1 MBytes 277 Mbits/sec
[ 4] 6.00-7.00 sec 32.9 MBytes 276 Mbits/sec
[ 4] 7.00-8.00 sec 26.2 MBytes 220 Mbits/sec
[ 4] 8.00-9.00 sec 24.8 MBytes 208 Mbits/sec
[ 4] 9.00-10.00 sec 31.0 MBytes 260 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 307 MBytes 257 Mbits/sec 6542 sender
[ 4] 0.00-10.00 sec 307 MBytes 257 Mbits/sec receiver
iperf Done.
I was more interested in the figures the other way:
sojer2005@Synology:~$ iperf3 -R -c 192.168.1.90
Ok, the result just from now:
sojer2005@Synology:~$ iperf3 -R -c 192.168.1.90
Connecting to host 192.168.1.90, port 5201
Reverse mode, remote host 192.168.1.90 is sending
[ 5] local 192.168.1.4 port 44268 connected to 192.168.1.90 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 22.2 MBytes 186 Mbits/sec
[ 5] 1.00-2.00 sec 22.1 MBytes 185 Mbits/sec
[ 5] 2.00-3.00 sec 22.1 MBytes 185 Mbits/sec
[ 5] 3.00-4.00 sec 22.1 MBytes 185 Mbits/sec
[ 5] 4.00-5.00 sec 22.0 MBytes 184 Mbits/sec
[ 5] 5.00-6.00 sec 21.9 MBytes 184 Mbits/sec
[ 5] 6.00-7.00 sec 21.8 MBytes 183 Mbits/sec
[ 5] 7.00-8.00 sec 21.7 MBytes 182 Mbits/sec
[ 5] 8.00-9.00 sec 21.7 MBytes 182 Mbits/sec
[ 5] 9.00-10.00 sec 21.7 MBytes 182 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 222 MBytes 186 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 219 MBytes 184 Mbits/sec receiver
iperf Done.
Thanks. So no change and still lower bandwidth to the Synology. But it’s working for you, which is the main thing.
Ok, I have run iperf3 -c 192.168.1.90 (without -R) on Synology, the result is slightly different from above now.
sojer2005@Synology:~$ iperf3 -c 192.168.1.90
Connecting to host 192.168.1.90, port 5201
[ 5] local 192.168.1.4 port 44326 connected to 192.168.1.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 32.0 MBytes 268 Mbits/sec 753 31.1 KBytes
[ 5] 1.00-2.00 sec 31.3 MBytes 263 Mbits/sec 670 29.7 KBytes
[ 5] 2.00-3.00 sec 32.9 MBytes 276 Mbits/sec 730 59.4 KBytes
[ 5] 3.00-4.00 sec 31.7 MBytes 266 Mbits/sec 738 56.6 KBytes
[ 5] 4.00-5.00 sec 33.0 MBytes 277 Mbits/sec 694 29.7 KBytes
[ 5] 5.00-6.00 sec 33.0 MBytes 277 Mbits/sec 724 29.7 KBytes
[ 5] 6.00-7.00 sec 31.7 MBytes 266 Mbits/sec 729 39.6 KBytes
[ 5] 7.00-8.00 sec 34.1 MBytes 286 Mbits/sec 682 49.5 KBytes
[ 5] 8.00-9.00 sec 31.7 MBytes 266 Mbits/sec 718 41.0 KBytes
[ 5] 9.00-10.00 sec 25.9 MBytes 217 Mbits/sec 567 39.6 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 317 MBytes 266 Mbits/sec 7005 sender
[ 5] 0.00-10.00 sec 317 MBytes 266 Mbits/sec receiver
iperf Done.
It’s roughly in line with the osmc@osmc:~$ iperf3 -R -c 192.168.1.4
figures above.
And finally for anyone intrested , result from vero 4k internal ethernet:
I have finally undersad how iperf3 work
After we have installed it on both devices we can run the test:
1. Start iperf3 in server mode on your central device (NAS, Server, Router or PC) with `iperf3 -s`
2. Start iperf3 on the OSMC as client with `iperf3 -R -c <IP of your iperf3-server>` , this will run a test where the OSMC device will receive data from the Server
3. Now to test the direction from OSMC to the Server we need to remove `-R` switch on the OSMC device `iperf3 -c <IP of your iperf3-server>`
While the `-R` test is the more relevant one (you normally use the direction where the OSMC device receives the data) it still also important to run the test without the `-R` option to ensure both receiving and transmission direction works fine.
osmc@osmc:~$ iperf3 -c 192.168.1.4 -R
Connecting to host 192.168.1.4, port 5201
Reverse mode, remote host 192.168.1.4 is sending
[ 4] local 192.168.1.17 port 58861 connected to 192.168.1.4 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 4] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 4] 2.00-3.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 4] 3.00-4.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 4] 4.00-5.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 4] 5.00-6.00 sec 11.2 MBytes 94.0 Mbits/sec
[ 4] 6.00-7.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 4] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec
[ 4] 8.00-9.00 sec 11.2 MBytes 94.2 Mbits/sec
[ 4] 9.00-10.00 sec 11.2 MBytes 94.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 114 MBytes 95.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 112 MBytes 94.3 Mbits/sec receiver
iperf Done.
osmc@osmc:~$ iperf3 -c 192.168.1.4
Connecting to host 192.168.1.4, port 5201
[ 4] local 192.168.1.17 port 58863 connected to 192.168.1.4 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 12.8 MBytes 107 Mbits/sec 0 286 KBytes
[ 4] 1.00-2.00 sec 12.2 MBytes 102 Mbits/sec 0 440 KBytes
[ 4] 2.00-3.00 sec 11.9 MBytes 100 Mbits/sec 0 561 KBytes
[ 4] 3.00-4.00 sec 11.8 MBytes 99.2 Mbits/sec 0 662 KBytes
[ 4] 4.00-5.00 sec 11.2 MBytes 93.9 Mbits/sec 0 755 KBytes
[ 4] 5.00-6.00 sec 11.2 MBytes 94.5 Mbits/sec 0 837 KBytes
[ 4] 6.00-7.00 sec 11.2 MBytes 94.2 Mbits/sec 0 919 KBytes
[ 4] 7.00-8.00 sec 11.2 MBytes 94.4 Mbits/sec 0 991 KBytes
[ 4] 8.00-9.00 sec 11.2 MBytes 93.7 Mbits/sec 0 1.04 MBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 94.0 Mbits/sec 0 1.10 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 116 MBytes 97.3 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 113 MBytes 94.6 Mbits/sec receiver
iperf Done.
osmc@osmc:~$
Zero Retr.
So the ethernet to USB adapter is to blame for sure.
Not necessarily. It connects to the switch at 1000 Mb/s but, in reality, can’t offload the data at this speed because of the Vero4K’s USB2 interface. Add to this that it’s not picking up the correct driver, so it might be a combination of factors.
Ok. As I have said 0 retransmissions in connection from NAS to Vero4K+, maximum rate. But I have about 500-600 retransmissions in total to the connection direction from Vero4K+ to my NAS.
That does not created any stutter or buffering of course but I wonder what is the cause and how I can resolve it. Problem with the Vero4K+ drivers? Only in one way though?