Hi Jose,
On 13/05/2019 11:07, Jose Abreu wrote:
> From: Simon Huelck
> Date: Sat, May 11, 2019 at 15:53:34
>
>> ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt
>> recognize before.
>
> Flow Control can prevent this to happen. Please check if your DT FIFO
> bindings are >
Hi,
what exactly do you mean with this DT binding ? i cant find this for
meson gxbb somewhere in the DTS ?
regards,
Simon
Am 13.05.2019 um 11:07 schrieb Jose Abreu:
> From: Simon Huelck
> Date: Sat, May 11, 2019 at 15:53:34
>
>> ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i
From: Simon Huelck
Date: Sat, May 11, 2019 at 15:53:34
> ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt
> recognize before.
Flow Control can prevent this to happen. Please check if your DT FIFO
bindings are >= 4096.
> Do we have new ideas / new direction to dig for ?
G
Hi guys,
on 5.1+ the story keeps being the same.
950 Mbits in each direction, but when in duplex RX is starving to ~70
MBits..
ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt
recognize before.
Do we have new ideas / new direction to dig for ?
regards,
Simon
Am 01.03.2
Hi,
RX is starving TX i guess ... so the other way around. a transfer was
ongoing from 10.10.11.100 to 10.10.11.1 when i triggered this command on
10.10.11.1
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 51652 connected to 10.10
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 s
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 90
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
Hi,
i got another question about NAPI and irq assignment.
my ethernet IRQ is assigned to CPU3:
CPU0 CPU1 CPU2 CPU3
1: 0 0 0 0 GICv2 25 Level
vgic
3: 7265279 3145278 4626601 2454147 GICv2 30 Level
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
Hi Simon,
On 2/24/2019 8:34 PM, Simon Huelck wrote:
> the topic is about ODROID C2 / Amlogic S905X since the start. we have a
> performance regression since 4.14.
As we are not advancing in this topic I suggest you try bisecting
the offending commit.
Thanks,
Jose Miguel Abreu
Am 24.02.2019 um 20:42 schrieb Sebastian Gottschall:
> vice are you talking about? its not your windows pc. if its a ipq8064
> based device or something like that you should look
> on a very different location. this platform like the r7800 has stmac
> performance problems since the kernel clk code
**
**its clearly visible when i activated the other stream for getting
duplex load ... The highest rate also stays alot under the possible
930MBits that i have seen earlier with 4.14.
**
**
**
**the parallel stream reached around 450Mbits , which almost sums up to
660Mbits. This is what i me
Am 24.02.2019 um 16:00 schrieb Simon Huelck:
> Am 21.02.2019 um 18:46 schrieb Jerome Brunet:
>> On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote:
>>> Hi,
>>>
>>>
>>>
>>> this was changed recently, with a patch for the EEE stuff , see here:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/gi
Am 21.02.2019 um 18:46 schrieb Jerome Brunet:
> On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote:
>> Hi,
>>
>>
>>
>> this was changed recently, with a patch for the EEE stuff , see here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e95
Hi All,
On Fri, 22 Feb 2019 at 01:05, Simon Huelck wrote:
>
> Am 21.02.2019 um 18:46 schrieb Jerome Brunet:
> > On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote:
> >> Hi,
> >>
> >>
> >>
> >> this was changed recently, with a patch for the EEE stuff , see here:
> >>
> >> https://git.kernel.or
Am 21.02.2019 um 18:46 schrieb Jerome Brunet:
> On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote:
>> Hi,
>>
>>
>>
>> this was changed recently, with a patch for the EEE stuff , see here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e95
On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote:
> Hi,
>
>
>
> this was changed recently, with a patch for the EEE stuff , see here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858
Hu, I was not aware t
Am 21.02.2019 um 15:21 schrieb Jerome Brunet:
> On Tue, 2019-02-19 at 20:41 +0100, Simon Huelck wrote:
>> Am 19.02.2019 um 09:47 schrieb Jose Abreu:
>>> Hi Simon,
>>>
>>> On 2/18/2019 6:05 PM, Simon Huelck wrote:
disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ),
the r
On Tue, 2019-02-19 at 20:41 +0100, Simon Huelck wrote:
> Am 19.02.2019 um 09:47 schrieb Jose Abreu:
> > Hi Simon,
> >
> > On 2/18/2019 6:05 PM, Simon Huelck wrote:
> > > disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ),
> > > the results are the same. I can confirm the LPI cou
Am 19.02.2019 um 09:47 schrieb Jose Abreu:
> Hi Simon,
>
> On 2/18/2019 6:05 PM, Simon Huelck wrote:
>> disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ),
>> the results are the same. I can confirm the LPI counters are zero or one
>> only after the test.
> It's interesting t
Hi Simon,
On 2/18/2019 6:05 PM, Simon Huelck wrote:
> disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ),
> the results are the same. I can confirm the LPI counters are zero or one
> only after the test.
It's interesting to see that you have a lot of RX packets but few
RX i
Am 18.02.2019 um 18:05 schrieb Jose Abreu:
> On 2/18/2019 4:51 PM, Simon Huelck wrote:
>> Hi,
>>
>> no im testing vanilla mainline kernel and against 4.14. where
>> performance was ok. but turning off EEE via ethtool should have same
>> results than removal of that patch.
>>
>> But, since it was ma
On 2/18/2019 4:51 PM, Simon Huelck wrote:
> Hi,
>
> no im testing vanilla mainline kernel and against 4.14. where
> performance was ok. but turning off EEE via ethtool should have same
> results than removal of that patch.
>
> But, since it was mainlined recently , not long ago, i think this was
Hi,
here directly after reboot and a first iperf test
C:\Users\Simon\Downloads\iperf-2.0.9-win64>iperf.exe -c 10.10.11.1 -i1 -d
Server listening on TCP port 5001
TCP window size: 208 KByte (default)
Hi,
no im testing vanilla mainline kernel and against 4.14. where
performance was ok. but turning off EEE via ethtool should have same
results than removal of that patch.
But, since it was mainlined recently , not long ago, i think this was
tested ??
https://git.kernel.org/pub/scm/linux/kernel/gi
On 2/18/2019 4:40 PM, Simon Huelck wrote:
> Hi,
>
> EEE is enabled for odroid - c2 and should be working in 5.0-rc7 afaik ?
Oops, I was seeing in the wrong version, sorry.
And did you test without that patch ?
Thanks,
Jose Miguel Abreu
Hi,
EEE is enabled for odroid - c2 and should be working in 5.0-rc7 afaik ?
there was a recent patch for this which was added to mainline
regards,
Simon
Am 18.02.2019 um 17:26 schrieb Jose Abreu:
> On 2/18/2019 3:53 PM, Simon Huelck wrote:
>> How can i do this (reset stats) ?
> A simple ifdown
On 2/18/2019 3:53 PM, Simon Huelck wrote:
> How can i do this (reset stats) ?
A simple ifdown / ifup should work.
> The .dtb .dts is meson-gxbb-odroid-c2 from mainline kernel 5.0.rc7
So, according to your DT bindings you have broken EEE yet it's
still enabled in stmmac as we see the LPI counters
How can i do this (reset stats) ?
The .dtb .dts is meson-gxbb-odroid-c2 from mainline kernel 5.0.rc7
Am 18.02.2019 um 16:31 schrieb Jose Abreu:
> On 2/18/2019 3:29 PM, Simon Huelck wrote:
>> Can i reset the ethtool statistics for better overview ?
> Yes please. And do send the remaining log
On 2/18/2019 3:29 PM, Simon Huelck wrote:
> Can i reset the ethtool statistics for better overview ?
Yes please. And do send the remaining logs + DT bindings.
Thanks,
Jose Miguel Abreu
Hi,
i tried your command and tested afterwards, no change in behaviour .
Can i reset the ethtool statistics for better overview ?
regards,
Simon
Am 18.02.2019 um 14:02 schrieb Jose Abreu:
> On 2/18/2019 12:41 PM, Jose Abreu wrote:
>> On 2/18/2019 12:33 PM, Simon Huelck wrote:
>>> Hi,
>>>
>>>
On 2/18/2019 12:41 PM, Jose Abreu wrote:
> On 2/18/2019 12:33 PM, Simon Huelck wrote:
>> Hi,
>>
>>
>> i recognize the followin on my ethernet stats:
>>
>> threshold: 1
>> tx_pkt_n: 1457325
>> rx_pkt_n: 5022405
>> normal_irq_n: 671738
>> rx_normal_irq_n: 606573
>> napi_
On 2/18/2019 12:33 PM, Simon Huelck wrote:
> Hi,
>
>
> i recognize the followin on my ethernet stats:
>
> threshold: 1
> tx_pkt_n: 1457325
> rx_pkt_n: 5022405
> normal_irq_n: 671738
> rx_normal_irq_n: 606573
> napi_poll: 784439
> tx_normal_irq_n: 61061
> t
Hi,
i recognize the followin on my ethernet stats:
threshold: 1
tx_pkt_n: 1457325
rx_pkt_n: 5022405
normal_irq_n: 671738
rx_normal_irq_n: 606573
napi_poll: 784439
tx_normal_irq_n: 61061
tx_clean: 784439
tx_set_ic_bit: 58293
irq_receive_pmt_irq_n:
On 2/18/2019 8:42 AM, Jose Abreu wrote:
> On 2/17/2019 2:48 PM, Martin Blumenstingl wrote:
>> Jose, is my command for disabling offloading correct?
>
> Yes, I think so. What about NIC statistics and logs ? ("ethtool
> -S eth0", "dmesg | grep -i stmmac")
And, "ifconfig eth0" after running the test
On 2/17/2019 2:48 PM, Martin Blumenstingl wrote:
> Jose, is my command for disabling offloading correct?
Yes, I think so. What about NIC statistics and logs ? ("ethtool
-S eth0", "dmesg | grep -i stmmac")
Thanks,
Jose Miguel Abreu
Hi Martin,
i repeated your commands , nothing changed the problematic result
regards,
Simon
Am 17.02.2019 um 15:48 schrieb Martin Blumenstingl:
> Hello Jose,
>
> On Mon, Feb 11, 2019 at 2:45 PM Jose Abreu wrote:
>> Hello,
>>
>> On 2/9/2019 1:09 AM, Martin Blumenstingl wrote:
>>> (it's in
Hello Jose,
On Mon, Feb 11, 2019 at 2:45 PM Jose Abreu wrote:
>
> Hello,
>
> On 2/9/2019 1:09 AM, Martin Blumenstingl wrote:
> > (it's interesting that the sending direction has 445 retries)
>
> I saw this before and I think it was related with COE. Can you
> please disable all offloading and try
I think it was related with COE. Can you
> please disable all offloading and try again?
>
> Anyway, maybe Simon should bissect ? I think since 4.14 there are
> not that many commits in stmmac / meson8b-dwmac that can cause
> this behavior.
>
> Thanks,
> Jose Miguel Abreu
here are
not that many commits in stmmac / meson8b-dwmac that can cause
this behavior.
Thanks,
Jose Miguel Abreu
Hi Simon,
On Thu, Feb 7, 2019 at 8:30 PM Simon Huelck wrote:
>
> Hi Guys,
>
>
> i can confirm better performance with 4.14.29
>
> - ~900 MBits with iperf2 in one way
> -~ 500 - 600MBits with iperf2 in duplex in both directions
>
>
> This wasnt the case with 4.17.9, not with 4.18, 4.19 or the 5.0
Hi Guys,
i can confirm better performance with 4.14.29
- ~900 MBits with iperf2 in one way
-~ 500 - 600MBits with iperf2 in duplex in both directions
This wasnt the case with 4.17.9, not with 4.18, 4.19 or the 5.0 series.
How can i help further ?
regards,
Simon
Am 06.02.2019 um 11:36
Hi,
4.17.9 failed going back further
regards,
Simon
Am 06.02.2019 um 11:36 schrieb Emiliano Ingrassia:
> Hi Martin, Hi Simon,
>
> On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote:
>> On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck wrote:
>> [...]
> I got problems with my OD
Hi,
yes i did reach 900MBits . maybe it was kernel 4.14 or 4.17. The 3.x
series was also ok.
I will pull latest 4.17 and test. If this doesnt work i go for 4.14
regards,
Simon
Am 06.02.2019 um 11:36 schrieb Emiliano Ingrassia:
> Hi Martin, Hi Simon,
>
> On Mon, Feb 04, 2019 at 03:34:41PM +0100
Hi Martin, Hi Simon,
On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote:
> On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck wrote:
> [...]
> > >> I got problems with my ODROID c2 running on 4.19.16 ( and some releases
> > >> earlier ). the stmmac / dwmac driver doesnt provide the 80
On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck wrote:
[...]
> >> I got problems with my ODROID c2 running on 4.19.16 ( and some releases
> >> earlier ). the stmmac / dwmac driver doesnt provide the 800M/900M
> >> performance that i was used to earlier.
> >>
> >>
> >> Now im stuck near 550M/600M in
Am 17.01.2019 um 21:57 schrieb Martin Blumenstingl:
> Hi Simon,
>
> On Thu, Jan 17, 2019 at 7:53 PM Simon Huelck wrote:
>> Hi Martin,
>>
>>
>> deutsch ?
> theoretisch: ja, das endet bei mir aber in einem komischen Mix aus
> deutsch und englisch, von daher...
>
>> I got problems with my ODROID c2 r
48 matches
Mail list logo
