arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Very poor network performance is observed on the ODROID-M1 Board
(REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and
this problem can be resolved after changing the value of TXD
timing to 0x35 from 0x4f.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
Change-Id: Idecd246e3fe93447b6e3e9b165d077d2050bbd75
---
arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts b/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts
index 0f844806ec542..e1a550a04498e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts
@@ -210,7 +210,7 @@ &gmac0_rgmii_clk
&gmac0_rgmii_bus>;
status = "okay";
- tx_delay = <0x4f>;
+ tx_delay = <0x35>;
rx_delay = <0x2d>;
};
--
2.34.1
On Tue, Aug 19, 2025 at 01:50:17PM +0900, Dongjin Kim wrote: > Very poor network performance is observed on the ODROID-M1 Board > (REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and > this problem can be resolved after changing the value of TXD > timing to 0x35 from 0x4f. How did you decide on 0x35? ~/linux/arch/arm64$ grep -hr "tx_delay = " | sort | uniq -c 4 tx_delay = <0x10>; 1 tx_delay = <0x1a>; 1 tx_delay = <0x21>; 2 tx_delay = <0x22>; 4 tx_delay = <0x24>; 2 tx_delay = <0x26>; 14 tx_delay = <0x28>; 1 tx_delay = <0x2a>; 6 tx_delay = <0x30>; 1 tx_delay = <0x3a>; 3 tx_delay = <0x3c>; 2 tx_delay = <0x42>; 5 tx_delay = <0x43>; 2 tx_delay = <0x44>; 1 tx_delay = <0x46>; 6 tx_delay = <0x4f>; The numbers are all over the place, but it is clear that 0x28 is the most popular for some reason. But since this delay values are magic, i've no idea why. Andrew
On Tue, Aug 19, 2025 at 06:03:47PM +0200, Andrew Lunn wrote: > On Tue, Aug 19, 2025 at 01:50:17PM +0900, Dongjin Kim wrote: > > Very poor network performance is observed on the ODROID-M1 Board > > (REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and > > this problem can be resolved after changing the value of TXD > > timing to 0x35 from 0x4f. > > How did you decide on 0x35? > > ~/linux/arch/arm64$ grep -hr "tx_delay = " | sort | uniq -c > 4 tx_delay = <0x10>; > 1 tx_delay = <0x1a>; > 1 tx_delay = <0x21>; > 2 tx_delay = <0x22>; > 4 tx_delay = <0x24>; > 2 tx_delay = <0x26>; > 14 tx_delay = <0x28>; > 1 tx_delay = <0x2a>; > 6 tx_delay = <0x30>; > 1 tx_delay = <0x3a>; > 3 tx_delay = <0x3c>; > 2 tx_delay = <0x42>; > 5 tx_delay = <0x43>; > 2 tx_delay = <0x44>; > 1 tx_delay = <0x46>; > 6 tx_delay = <0x4f>; > > The numbers are all over the place, but it is clear that 0x28 is the > most popular for some reason. But since this delay values are magic, > i've no idea why. > > Andrew I do have more numbers in the Rockchip BSP kernel, and 0x35 is from one of them that shows less retry counts when testing 'iperf3' while testing with the batch of ODROID-M1. :) Thanks, Dongjin Kim.
Dongjin Kim wrote: > On Tue, Aug 19, 2025 at 06:03:47PM +0200, Andrew Lunn wrote: > > On Tue, Aug 19, 2025 at 01:50:17PM +0900, Dongjin Kim wrote: > > > Very poor network performance is observed on the ODROID-M1 Board > > > (REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and > > > this problem can be resolved after changing the value of TXD > > > timing to 0x35 from 0x4f. > > > > How did you decide on 0x35? > > > > ~/linux/arch/arm64$ grep -hr "tx_delay = " | sort | uniq -c > > 4 tx_delay = <0x10>; > > 1 tx_delay = <0x1a>; > > 1 tx_delay = <0x21>; > > 2 tx_delay = <0x22>; > > 4 tx_delay = <0x24>; > > 2 tx_delay = <0x26>; > > 14 tx_delay = <0x28>; > > 1 tx_delay = <0x2a>; > > 6 tx_delay = <0x30>; > > 1 tx_delay = <0x3a>; > > 3 tx_delay = <0x3c>; > > 2 tx_delay = <0x42>; > > 5 tx_delay = <0x43>; > > 2 tx_delay = <0x44>; > > 1 tx_delay = <0x46>; > > 6 tx_delay = <0x4f>; > > > > The numbers are all over the place, but it is clear that 0x28 is the > > most popular for some reason. But since this delay values are magic, > > i've no idea why. > > > > Andrew > I do have more numbers in the Rockchip BSP kernel, and 0x35 is from > one of them that shows less retry counts when testing 'iperf3' while > testing with the batch of ODROID-M1. :) FWIW, I had trouble with my Odroid-M1 whose outgoing ethernet bandwidth seemed to be limited to an average around 100kB/s, when I bumped into this thread. I applied the patch and I can now download from that Odroid at >80MB/s. So: Tested-by: Stefan Monnier <monnier@iro.umontreal.ca> Haven't tried the `rgmii-id` patch yet. Stefan
Am Dienstag, 19. August 2025, 18:03:47 Mitteleuropäische Sommerzeit schrieb Andrew Lunn: > On Tue, Aug 19, 2025 at 01:50:17PM +0900, Dongjin Kim wrote: > > Very poor network performance is observed on the ODROID-M1 Board > > (REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and > > this problem can be resolved after changing the value of TXD > > timing to 0x35 from 0x4f. > > How did you decide on 0x35? just because I accidentially stumbled over that recently, Rockchip has some scanning functionality in their vendor-kernel to get possible delay values for a board. Described in a document called "Rockchip GMAC RGMII Delayline Guide" [0] and one code location is for example the armbian tree [1] At least that is one possible source of per-board delay values :-) Heiko [0] https://lo01.g77k.com/aeb/docs/en/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf (random internet source Google found me) [1] https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c > > ~/linux/arch/arm64$ grep -hr "tx_delay = " | sort | uniq -c > 4 tx_delay = <0x10>; > 1 tx_delay = <0x1a>; > 1 tx_delay = <0x21>; > 2 tx_delay = <0x22>; > 4 tx_delay = <0x24>; > 2 tx_delay = <0x26>; > 14 tx_delay = <0x28>; > 1 tx_delay = <0x2a>; > 6 tx_delay = <0x30>; > 1 tx_delay = <0x3a>; > 3 tx_delay = <0x3c>; > 2 tx_delay = <0x42>; > 5 tx_delay = <0x43>; > 2 tx_delay = <0x44>; > 1 tx_delay = <0x46>; > 6 tx_delay = <0x4f>; > > The numbers are all over the place, but it is clear that 0x28 is the > most popular for some reason. But since this delay values are magic, > i've no idea why. > > Andrew >
On 19/08/2025 06:50, Dongjin Kim wrote: > Very poor network performance is observed on the ODROID-M1 Board > (REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and > this problem can be resolved after changing the value of TXD > timing to 0x35 from 0x4f. > > Signed-off-by: Dongjin Kim <tobetter@gmail.com> > Change-Id: Idecd246e3fe93447b6e3e9b165d077d2050bbd75 Please run scripts/checkpatch.pl on the patches and fix reported warnings. After that, run also 'scripts/checkpatch.pl --strict' on the patches and (probably) fix more warnings. Some warnings can be ignored, especially from --strict run, but the code here looks like it needs a fix. Feel free to get in touch if the warning is not clear. You CC-ed an address, which suggests you do not work on mainline kernel or you do not use get_maintainers.pl/b4/patman. Please rebase and always work on mainline or start using mentioned tools, so correct addresses will be used. Best regards, Krzysztof
On Tue, Aug 19, 2025 at 08:42:55AM +0200, Krzysztof Kozlowski wrote: > On 19/08/2025 06:50, Dongjin Kim wrote: > > Very poor network performance is observed on the ODROID-M1 Board > > (REV 1.0 20220613) when running iperf3 (under 200Mbits/sec), and > > this problem can be resolved after changing the value of TXD > > timing to 0x35 from 0x4f. > > > > Signed-off-by: Dongjin Kim <tobetter@gmail.com> > > Change-Id: Idecd246e3fe93447b6e3e9b165d077d2050bbd75 > > > Please run scripts/checkpatch.pl on the patches and fix reported > warnings. After that, run also 'scripts/checkpatch.pl --strict' on the > patches and (probably) fix more warnings. Some warnings can be ignored, > especially from --strict run, but the code here looks like it needs a > fix. Feel free to get in touch if the warning is not clear. Thanks. I realized that I sent unmodified file that includes "Change-Id:". > > You CC-ed an address, which suggests you do not work on mainline kernel > or you do not use get_maintainers.pl/b4/patman. Please rebase and always > work on mainline or start using mentioned tools, so correct addresses > will be used. I've rebased to the master branch, so let me send the patch again. > > Best regards, > Krzysztof
© 2016 - 2025 Red Hat, Inc.