Hi,
i sorted out some more things:
- i did not activate tcp window scaling , with this , iperf3 is reaching
930MBits now, this was related to my firewall and therefore my uplink.
so the remaining topic is ( and im currently testing with next-20190306 )
TX is starving RX and the total bandwith seem to be limited to 930MBits
instead of something like 930MBits * 2 for duplex.
@Jose, do you have some hints on that ? i saw that you introduced
patches for that , but somehow RX/TX are not equally sharing the NAPI
budget. But i wonder why the TX queue and RX queue collide at all,
shouldnt they be indipendent ?
regards,
Simon
> Hi guys,
>
>
> 1. i discovered something strange. when i never configure my external
> VLAN interface UP ( firewall doesnt start, traffic shaper CAKE doesnt
> start), my non duplex iperf bandwidth increases from 600MBits to 930.
>
> 2. duplex isnt working, TX is totally starving RX, the total bandwidth
> is 900MBits, whats going on there ?
>
> 3. i had a MTU issue ( was set to 1500, but due to VLANs etc 1450 would
> be better ) but this didnt change performance
> 4. even when i up eth0.4, then i down eth0.4, then flush iptables and
> shaper were never added, i drop to 600MBits ....
>
> questions:
> - why is duplex still not working even so the kernel says so ?
> - why is TX totally starving RX, even so duplex is "on"
> - when i flush all my iptable rules, and the traffic shaper, still im
> bond to 600MBits ... very strange, someone got an idea ? upping eth0.4
> is cutting the performance, even when other VLAN IFs like eth0.3,
> eth0.2, eth0.5 are up and bridged ( eth0.4 isnt bridged somewhere )
>
>
>
> my setup:
>
> br-dmz 8000.7ef0fd9b157f no eth0.2
> br-guest 8000.001f1fbbbd60 no wlan0
> br-iot 8000.7ef0fd9b157f no eth0.5
> br-lan 8000.001f1fbbbd61 no eth0.3
> wlan0_1
> wlan2
>
> eth0.4 is my uplink
>
> all the bridges are internally , eth0.4 is externally
>
>
> C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c
> 10.10.11.1 -i1
> warning: Ignoring nonsense TCP MSS 0
> Connecting to host 10.10.11.1, port 5201
> [ 5] local 10.10.11.100 port 52173 connected to 10.10.11.1 port 5201
> [ ID] Interval Transfer Bitrate
> [ 5] 0.00-1.00 sec 384 KBytes 3.14 Mbits/sec
> [ 5] 1.00-2.00 sec 384 KBytes 3.15 Mbits/sec
> [ 5] 2.00-3.00 sec 1.12 MBytes 9.44 Mbits/sec
> [ 5] 3.00-4.00 sec 2.00 MBytes 16.8 Mbits/sec
> [ 5] 4.00-5.00 sec 2.38 MBytes 19.9 Mbits/sec
> [ 5] 5.00-6.00 sec 3.12 MBytes 26.2 Mbits/sec
> [ 5] 6.00-7.00 sec 4.75 MBytes 39.8 Mbits/sec
> [ 5] 7.00-8.00 sec 68.4 MBytes 574 Mbits/sec
> [ 5] 8.00-9.00 sec 104 MBytes 875 Mbits/sec
> [ 5] 9.00-10.00 sec 105 MBytes 881 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate
> [ 5] 0.00-10.00 sec 292 MBytes 245 Mbits/sec sender
> [ 5] 0.00-10.04 sec 292 MBytes 244 Mbits/sec
> receiver
>
> iperf Done.
>
>
> root@odroidc2:~# iperf3 -c 10.10.11.100 -i1
> Connecting to host 10.10.11.100, port 5201
> [ 5] local 10.10.11.1 port 60022 connected to 10.10.11.100 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 417 KBytes
> [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 487 KBytes
> [ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 0 487 KBytes
> [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 512 KBytes
> [ 5] 4.00-5.01 sec 109 MBytes 907 Mbits/sec 0 543 KBytes
> [ 5] 5.01-6.01 sec 109 MBytes 911 Mbits/sec 0 543 KBytes
> [ 5] 6.01-7.01 sec 108 MBytes 902 Mbits/sec 0 543 KBytes
> [ 5] 7.01-8.01 sec 108 MBytes 905 Mbits/sec 0 543 KBytes
> [ 5] 8.01-9.00 sec 106 MBytes 895 Mbits/sec 0 543 KBytes
> [ 5] 9.00-10.00 sec 106 MBytes 891 Mbits/sec 0 543 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec 0 sender
> [ 5] 0.00-10.04 sec 1.07 GBytes 915 Mbits/sec
> receiver
>
> --
>
>
> Mar 5 09:46:03 localhost kernel: [ 105.534204] meson8b-dwmac
> c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>
> iperf Done.
> root@odroidc2:~#
>
>
>
>
> regards,
> Simon
>
> Am 01.03.2019 um 10:23 schrieb Jose Abreu:
>> Hi Simon,
>>
>> On 2/27/2019 7:02 PM, Simon Huelck wrote:
>>> Hi,
>>>
>>>
>>> the thing is , that im not a stmmac developer. Yes , maybe i can bissect
>>> it and yes you are lucky since im a C-developer since a long time for
>>> embedded systems.
>>>
>>> The problem is that i dont understand the structure of stmmac and im not
>>> aware of any documentation about the driver structure nor the underlying
>>> ethernet hardware ( even though im used to ethernet hardware in embedded
>>> environment ). So how shall i recognize the relevant change between
>>> 4.14.29 and 5.0rc8 ?
>>>
>>>
>>> Is it in the DTS/DTB, wrong hardware description ? Is it in the code ?
>>> how is the duplex hardware working on this piece ?
>>>
>>> I can try to support you the best i can, but i have little chances to
>>> analyze it myself. At which measurements / counters is it possible to
>>> see that duplex is fully working ? Why did even the non-duplex
>>> bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing
>>> up to TX and RX in summary when doing duplex ? Why is TX not starving in
>>> duplex but RX ?
>>>
>>> From my point of view should be the following things given:
>>> - the non duplex bandwidth should be somewhere around 900MBits , the HW
>>> is capable of that
>>> - TX should not influence RX or vice versa in duplex
>>> - the duplex bandwidth should be 900MBits in both directions ( maybe a
>>> bit asymetric when buffers in both dirs are not same )
>>>
>>> I guess we need some profiling on stmmac and ( at least i need ) more
>>> knowledge of the hardware and stmmac itself. Can someone point me to the
>>> driver documentation, describing the functions in the code and the
>>> structure ? How can i profile stmmac ( usually im using hardware / JTAG
>>> debuggers at work, but here @home i got nothing like that )
>>>
>>> So how do we continue ?
>> When I said bissect I was meaning GIT Bissect [1]. You shouldn't
>> need any development background for this. You just have to start
>> bissect, compile, test and check if commit is good or not.
>>
>> I'm not very familiar with this feature but I think you can
>> bissect pretty fast if you say you just want stmmac commits,
>> check ("Cutting down bisection by giving more parameters to
>> bisect start") on previous link ... In your case it would be
>> stmmac changes, dts, and phy.
>>
>> [1] https://git-scm.com/docs/git-bisect
>>
>> Thanks,
>> Jose Miguel Abreu
>
