full duplex only like half duplex

[EtienneB]

Hi,
I have seen many forum posts and other websites about slow networking speeds. Most of them referring to Realtek network cards.
I am running my FreeNAS 11.2U7 on a SuperMicro X10SL7-F with 16GB ram, and G3220 CPU

My main pool consists of 3 VDEVs in RAIDZ2 config, each existing of 6 drives (6x2, 6x3 and 6x4 WD Reds).

When I copy a file to my FreeNAS server from my Macbook 2018 running MacOS Mojave I achieve around 100+mbytes/sec, no worries there.

However when I copy a file from the FreeNAS server to the FreeNAS server using my Macbook, it halves the speed to about 55-60 Mbytes/s per one way (to a second pool or the main pool doesn't matter). This looks like half duplex to me.
My share is SMB.
When I tested it with an AFP share I get about 10mbytes/sec more speed, so around 65 Mbytes/sec one way doing this (around 135Mbytes/s combined up and down compared to around 120Mbytes/s combined up and down with SMB)

Ifconfig of the FreeNAS and the Macbook both state that they are full duplex if I am not mistaken?

ifconfig Macbook:
en9: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=4<VLAN_MTU>
ether 00:1c:c2:46:2d:eb
inet6 fe80::9b:e82:9c2c:d07b%en9 prefixlen 64 secured scopeid 0x8
inet6 2001:981:7391:1:cea:a8c:3679:8272 prefixlen 64 autoconf secured
inet6 2001:981:7391:1:35d1:a30b:f39b:e241 prefixlen 64 deprecated autoconf temporary
inet6 fd00::cf:f226:609:ba28 prefixlen 64 autoconf secured
inet6 fd00::39d5:14d1:11e7:f8f0 prefixlen 64 deprecated autoconf temporary
inet 192.168.178.26 netmask 0xffffff00 broadcast 192.168.178.255
inet6 2001:981:7391:1:dc06:94b2:58d7:3269 prefixlen 64 deprecated autoconf temporary
inet6 fd00::dc06:94b2:58d7:3269 prefixlen 64 deprecated autoconf temporary
inet6 2001:981:7391:1:2990:8fd6:f4a:6542 prefixlen 64 deprecated autoconf temporary
inet6 fd00::2990:8fd6:f4a:6542 prefixlen 64 deprecated autoconf temporary
inet6 2001:981:7391:1:d851:4dc:f9c2:8c70 prefixlen 64 deprecated autoconf temporary
inet6 fd00::d851:4dc:f9c2:8c70 prefixlen 64 deprecated autoconf temporary
inet6 2001:981:7391:1:b4b4:c103:e87:a865 prefixlen 64 autoconf temporary
inet6 fd00::b4b4:c103:e87:a865 prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active


ifconfig FreeNAS:
igb0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=2400b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,RXCSUM_IPV6>
ether 00:25:90:f3:5a:9e
hwaddr 00:25:90:f3:5a:9e
inet6 fe80::225:90ff:fef3:5a9e%igb0 prefixlen 64 scopeid 0x1
inet6 2001:981:7391:1:225:90ff:fef3:5a9e prefixlen 64 autoconf
inet6 fd00::225:90ff:fef3:5a9e prefixlen 64 autoconf
inet 192.168.178.29 netmask 0xffffff00 broadcast 192.168.178.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

The Macbook is wired to my Switch which connects directly to my FreeNAS.
It is an 8 port Sitecom Gigabit switch. I also tested this with the switch inside my Apple Time Capsule; same result.
Furthermore, I tested different cables and also the other Ethernet port on my Supermicro board. (I mainly use SFTP 6 cables and some CAT5e cables.)
Nothing changes in terms of speed.

I am not fully sure if it is a FreeNAS thing or a MacOS Mojave thing, but that is harder to test.

Perhaps I am missing a switch or parameter somewhere?

Any ideas are more than welcome!

 

[Fredda]

If you really suspect it is the ethernet connection, you should test this with iperf. This will show the raw network speed without any
SMB or AFP layers interfering.
Run iperf -s on the Server and iperf -c <server_ip> on your Macbook.

 

[Elliot Dierksen]

However when I copy a file from the FreeNAS server to the FreeNAS server using my Macbook, it halves the speed to about 55-60 Mbytes/s per one way

That is actually an easy answer. You are reading it from one place, and then pushing it back out. It is doing this as a serial task, so that is why you have the net result of lower throughput.

 

[EtienneB]

Thanks, I forgot to mention that I tried that too :)
With iperf3 I get I think normal results:

FreeNAS as iperf3 -s:
Connecting to host 192.168.178.29, port 5201
[ 4] local 192.168.178.26 port 61505 connected to 192.168.178.29 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 91.9 MBytes 771 Mbits/sec
[ 4] 1.00-2.00 sec 93.7 MBytes 786 Mbits/sec
[ 4] 2.00-3.00 sec 91.6 MBytes 768 Mbits/sec
[ 4] 3.00-4.00 sec 92.4 MBytes 775 Mbits/sec
[ 4] 4.00-5.00 sec 91.1 MBytes 764 Mbits/sec
[ 4] 5.00-6.00 sec 89.3 MBytes 749 Mbits/sec
[ 4] 6.00-7.00 sec 89.4 MBytes 750 Mbits/sec
[ 4] 7.00-8.00 sec 93.2 MBytes 782 Mbits/sec
[ 4] 8.00-9.00 sec 96.4 MBytes 809 Mbits/sec
[ 4] 9.00-10.00 sec 88.2 MBytes 740 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 917 MBytes 769 Mbits/sec sender
[ 4] 0.00-10.00 sec 917 MBytes 769 Mbits/sec receiver


Macbook as iperf3 -s:
Connecting to host 192.168.178.26, port 5201
[ 5] local 192.168.178.29 port 29373 connected to 192.168.178.26 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 103 MBytes 866 Mbits/sec 0 2.00 MBytes
[ 5] 1.00-2.00 sec 105 MBytes 882 Mbits/sec 0 2.00 MBytes
[ 5] 2.00-3.00 sec 105 MBytes 879 Mbits/sec 0 2.00 MBytes
[ 5] 3.00-4.00 sec 106 MBytes 886 Mbits/sec 0 2.00 MBytes
[ 5] 4.00-5.00 sec 106 MBytes 891 Mbits/sec 0 2.00 MBytes
[ 5] 5.00-6.00 sec 104 MBytes 875 Mbits/sec 0 2.00 MBytes
[ 5] 6.00-7.00 sec 106 MBytes 887 Mbits/sec 0 2.00 MBytes
[ 5] 7.00-8.00 sec 110 MBytes 926 Mbits/sec 0 2.00 MBytes
[ 5] 8.00-9.00 sec 110 MBytes 923 Mbits/sec 0 2.00 MBytes
[ 5] 9.00-10.00 sec 109 MBytes 916 Mbits/sec 0 2.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.04 GBytes 893 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.04 GBytes 892 Mbits/sec receiver


Looks normal to me, or am I wrong here?

 

[EtienneB]

That is actually an easy answer. You are reading it from one place, and then pushing it back out. It is doing this as a serial task, so that is why you have the net result of lower throughput.

I always believed that Full Duplex means that I should be able to get around 100mbytes up and down at the same time?

I tried to copy a file from my server to my macbook which fires up to 100MBytes/s easily, but as soon as a I push another file to my server, the combined speed drops to 100mbytes/s (and thus the first file to around 55mbytes/s)

 

[Elliot Dierksen]

I always believed that Full Duplex means that I should be able to get around 100mbytes up and down at the same time?

Yes BUT..... Just because the network has that capability doesn't mean that the hosts involved and all the interacting pieces of hardware and software will be able to wring every last bit of efficiency out of it.

I tried to copy a file from my server to my macbook which fires up to 100MBytes/s easily, but as soon as a I push another file to my server, the combined speed drops to 100mbytes/s (and thus the file to around 55mbytes/s)

That is more likely something where both tasks aren't able to execute or have access to the resources at the same time. iperf is the best indicator of what a host can do on a network without having to deal with any storage i/o. If you get reasonable results with that but your real workload doesn't, the problem is somewhere other than the network. That is harder to isolate, unfortunately.

 

[EtienneB]

Yes BUT..... Just because the network has that capability doesn't mean that the hosts involved and all the interacting pieces of hardware and software will be able to wring every last bit of efficiency out of it.

That is more likely something where both tasks aren't able to execute or have access to the resources at the same time. iperf is the best indicator of what a host can do on a network without having to deal with any storage i/o. If you get reasonable results with that but your real workload doesn't, the problem is somewhere other than the network. That is harder to isolate, unfortunately.

Thanks Elliot for clarification.

I am afraid that I indeed need to isolate further....