Date: Mon, 13 Nov 2023 20:27:05 +0100 From: =?utf-8?Q?S=C3=B8ren_Schmidt?= <soren.schmidt@gmail.com> To: titus <titus@edc.ro> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: eqos(4) throughput Message-ID: <5C1C084D-00A2-4FF3-9A14-34017DC9A4EE@gmail.com> In-Reply-To: <0FA5C2FB-B336-4DFA-AD32-05C414DDB6F7@edc.ro> References: <0FA5C2FB-B336-4DFA-AD32-05C414DDB6F7@edc.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Nov 2023, at 16.40, titus <titus@edc.ro> wrote: > i have this problem with eqos(4) on a rk3566 board (orangepi 3b) > when there is enough RX traffic the TX sinks packets (not all the = packets are transmitted) > this causes a max tcp uplink throughput of about 300mb/s > testing udp tx only will get to 900mbs+ > testing with iperf -c <server> -u -b 700m -d > will show 25-30% of the tx packets lost > the 25-30 percent can be decreased slightly if i fiddle with dtb = ethernet tx_delay but 19% is the best i could get >=20 > can somebody running 14+ on an rk356x board test this > on box1=20 > (server) iperf -s -u > on box2 rk356x (client) > iperf -c <server_ip> -b 700m -u -d > and check the packets lost by client send stream ? I can confirm this on the boards I have access to here, quartz64, = Nanopi5, firefly station m2/p2. around 400mbit bandwitdth and 16% loss, thats running CPU at 2.2Ghz. If I set 400Mhz CPU clock I get 375mbit and 0.6% loss, thats odd at = least. Anyhow the eqos driver is far from perfect, its single queue only etc, = so there is possibly much to be gained. -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C1C084D-00A2-4FF3-9A14-34017DC9A4EE>