I tried setting the router to 100 mbit, but it still has buffering issues (but not as many.
I have uploaded the logs. I tried playing a recording from recorded tv (Fredagsfilm_ Men så kom Polly - DR1 - 2015-03-27.ts).
Same problem here, that videos keep buffering across a samba share. I have a wired network throughout the house. I have a Raspberry Pi (version 1) running Raspbmc which, when connected to the same port as the Vero, has no problems playing anything back over the network, whereas the Vero does. I have tried, as suggested here, to put the port back to 100Mbit from 1000Mbit but this only increases the buffering problem.
I am observing the same issue with my new Vero and just like butlerat, I still have a Raspberry Pi on Raspbmc, streaming content without any buffering. Enforcing 100 Mbit on Vero did not improve the performance.
Any other suggestions?
Thanks!
Vero:
osmc@osmc:~$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Link detected: yes
osmc@osmc:~$ ./testnfs
Testing transfer speed of udp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 70.5451 s, 1.5 MB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 86.6659 s, 1.2 MB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 434.722 s, 241 kB/s
osmc@osmc:~$ ./testnfs tcp
Testing transfer speed of tcp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 20.2842 s, 5.2 MB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 19.53 s, 5.4 MB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 19.1781 s, 5.5 MB/s
osmc@osmc:~$
osmc@osmc:~$ sudo ethtool -s eth0 speed 100 autoneg off
osmc@osmc:~$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: off
Cannot get wake-on-lan settings: Operation not permitted
Link detected: yes
osmc@osmc:~$ ./testnfs
Testing transfer speed of udp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 397.197 s, 264 kB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 218.902 s, 479 kB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 149.209 s, 703 kB/s
osmc@osmc:~$ ./testnfs tcp
Testing transfer speed of tcp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 178.539 s, 587 kB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 177.785 s, 590 kB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 180.732 s, 580 kB/sRPi:
pi@raspbmc:~$ ./testnfs
Testing transfer speed of udp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 11.8624 s, 8.8 MB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 8.90123 s, 11.8 MB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 8.80016 s, 11.9 MB/s
pi@raspbmc:~$ ./testnfs tcp
Testing transfer speed of tcp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 16.1387 s, 6.5 MB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 13.3184 s, 7.9 MB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 12.2514 s, 8.6 MB/sSomething very wrong with your speeds there. I can achieve around 325Mbps (41MB/sec) tcp throughput in both directions using iperf on my vero, on a switch that has flow control enabled. (The remote end was a Windows 7 PC)
A couple of suggestions:
- When you are forcing 100Mbit with ethtool I see you are disabling auto-negotiation and forcing Full Duplex. This will cause a Duplex mismatch which will cause poor performance in one direction and extremely poor performance in the other direction.
Any time you manually disable auto-negotiation at one end of an Ethernet link you MUST choose half duplex if the other end of the link (eg your switch) is still set to auto-negotiate.
- Can you try iperf instead of nfs to make sure there isn’t an nfs issue ?
Well, there, that’s certainly better. Thanks for pointing out the duplex mismatch. My bad for not considering the automatic fallback to half-duplex mode which still uses CSMA/CD.
Setting the speed to 100 and enabling autonegotiation did the trick. Now it is only unfortunate that GbE will not work, but that is hardly a showstopper for me. 
Again, many thanks!
osmc@osmc:~$ sudo ethtool -s eth0 speed 100 duplex full autoneg on
osmc@osmc:~$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 100baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Link detected: yes
osmc@osmc:~$ ./testnfs
Testing transfer speed of udp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 9.57727 s, 10.9 MB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 8.84943 s, 11.8 MB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 8.86104 s, 11.8 MB/s
osmc@osmc:~$ ./testnfs tcp
Testing transfer speed of tcp on file 192.168.179.43:/raid/random100m.bin
/mnt/test mounted @ rsize (8K), requested rsize (8K)
104857600 bytes (105 MB) copied, 9.78113 s, 10.7 MB/s
/mnt/test mounted @ rsize (16K), requested rsize (16K)
104857600 bytes (105 MB) copied, 9.13921 s, 11.5 MB/s
/mnt/test mounted @ rsize (32K), requested rsize (32K)
104857600 bytes (105 MB) copied, 9.01669 s, 11.6 MB/sGlad to see it was indeed a Duplex mismatch causing 100Mbit to perform so slowly - setting full duplex with auto negotiation turned on and speed limited to 100Mbit is preferable to using half duplex with auto negotiation turned off and speed limited to 100Mbit, so you’ve done the right thing there.
The question is, why is Gigabit not working properly for you even though your switch advertises pause frame use ? I did my previous testing on a Gigabit switch at work so I’ve just retested the Vero at home using iperf to a Mac Mini. They are both plugged into a Virgin Media Superhub 2 (cable modem router/switch in the UK) and here is what ethtool reports for the switch, which looks exactly the same as what ethtool reported for you:
osmc@vero:~$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Link detected: yes
And here are the iperf results, the first one is Mac Mini -> Vero (receive) and the second is Vero->Mac Mini. (send) This is with no manual changes to the link with ethtool.
osmc@vero:~$ iperf -w 1M -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 320 KByte (WARNING: requested 1.00 MByte)
------------------------------------------------------------
[ 4] local 192.168.0.40 port 5001 connected with 192.168.0.10 port 52458
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 556 MBytes 466 Mbits/sec
osmc@vero:~$ iperf -w 1M -c 192.168.0.10
------------------------------------------------------------
Client connecting to 192.168.0.10, TCP port 5001
TCP window size: 320 KByte (WARNING: requested 1.00 MByte)
------------------------------------------------------------
[ 3] local 192.168.0.40 port 45041 connected with 192.168.0.10 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 417 MBytes 350 Mbits/sec
Bit of a difference from what you were seeing! What make and model of switch is the Vero connected to, what is your server that you’re testing to and is it too connected to the same switch ?
BTW 480Mbps is the theoretical maximum throughput on Gigabit for a Vero as the Ethernet controller is connected to the USB2 bus, and USB2 is limited to 480Mbps, so on receive I’m actually seeing very close to the theoretical maximum…
Indeed! Luckily, to date there is very little content available (none?) that requires ≥100Mbps of bandwidth to Vero. 
In this specific case, I am suspecting the culprit may be the powerline segment of my LAN. All other devices, and those happen to be upstream of the PLC adapters, achieve adequate throughput rates.
This is the setup, consisting of AVM Fritz!Box 6360 cable modem, D-Link DGS-105 switch and two devolo dLAN 1200+ / WiFi ac adapters with 1 resp. 2 GbE ports:
Router --- GbE Switch -+- Powerline Adapter --- Powerline Adapter -+- Vero
+- Ubuntu Server NAS +- RPi
+- ...
Either way, I am not actually expecting gigabit speeds over my power-line connection; Just some value beyond 100Mbps because the RPi achieved similar throughput rates. And we are trying to investigate the awful speeds occurring when configured for GbE. So if there is anything else I can provide that will help with this, please let me know. 
I don’t get this, According to Sam the Vero can go over 480Mbit. Vero network speed - choppy playback - #13 by sam_nazarko
I mean if the Ethernet controller is connected to the USB2 bus, then it shouldn’t be possible to go over 480Mbit.
Even on SolidRuns web site it says.
> (*) Note that due to internal i.MX6 buses the 1000Mbps interface speed is limited to 470Mbps.
Can anyone please explain what is the fact here.
This is not a USB bus limitation, but a system bus limitation (on the Atheros 8035). However speed actually depends greatly on the protocol used:
Russel King also bursted above this a while back.
S
Ok, so i tried
osmc@osmc:~$ sudo ethtool -s eth0 speed 100 duplex full autoneg on
and this worked. I’m not the best at linux commands but what do I need to do in order to persist the 100M speed? It resets back to 1000M each time it reboots. Do I need to put the command in a startup file?
At the moment you could try adding it to /etc/rc.local before the exit 0 line. You won’t need sudo if run from there.
Let us know if that works.
No, that hasn’t done it. Still goes back to 1000M on reboot.
Ok, that is probably running too soon then, before the ethernet driver even loads.
We are looking into ways of adding a user setting for 100Mbit but not sure how long that will be.
As a quick and ugly workaround - you could try adding a sleep 10 before the ethtool line in /etc/rc.local?
Excellent, thanks. That did the trick.