Sorry if this questions been asked before. However, I wasn’t really able to find something in particular that was similar.
I’m a little bit of a noob, but if someone might be able to assist me with interpreting some of my IPerf network results, it would be greatly appreciated.
The first screen shot is of an IPerf test run on a client PC within normal operation of the network.
The second screen shot is of IPerf run on OSMC using putty.
And the third screen shot is of IPerf run using the same wall outlet and cable that the Vero is connected to.
(I’m not even too sure if there is an issue or not, but from the results it looks like there could be?)
I quickly made a simple network diagram with Cat6 cabling used throughout.
I think I’ve added some most of the info but If I’m missing anything, let me know.
Many thanks in advance for any assistance & Merry Christmas!!
Will the iperf3 test can be influenced by several factors it shouldn’t be fluctuating as much as you are showing.
Did you always had the same target server which was not doing other CPU heavy or network stuff?
Does ifconfig show any errors, drops or overuns?
As I wrote in my HowTo when both sides are wired with 1000Mbit you should expect a clean 940 Mbit.
So looking at your numbers there is definitely something wrong/strange.
Sorry my that was my typo mistake, 1.5Gbit switch used in production.
Ahh ahah I’m learning things every day.
Checking and testing all cabling and wall outlets, including different ports on the switch as well as removing the switch and using only the router, the results from ifconfig are:
That’s surely not healthy but wouldn’t explain so low numbers.
That might be part of the issue as their might be negotiation issues.
Try ethtool sudo apt-get install ethtool and run ethtool eth0 check the output of that.
Most of the other network clients and the switches jumbo frame is set to 9216 bytes, if this might be causing the issue. You don’t happen to know if the Vero’s MTU value was set at 1500, by any chance?
results from ethtool eth0
osmc@osmc:~$ sudo apt-get install ethtool
Reading package lists... Done
Building dependency tree
Reading state information... Done
ethtool is already the newest version (1:4.19-1).
0 upgraded, 0 newly installed, 0 to remove and 88 not upgraded.
osmc@osmc:~$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x0000003d (61)
drv link timer ifdown ifup
Link detected: yes
Mmm from memory, I think it was because there is two clients always using a fair amount of resources as well as my dad’s PC using the NAS for his photographic needs
Oh yes, I missed that one ahah…
If you want to change it for testing issue ip link set eth0 mtu 9000 but I really think you will create a useful setup with that.
Hmm it’ll be something I’ll have to think about… if that is the issue ahha
