Date: Mon, 6 Jul 2020 22:12:18 -0700 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 Message-ID: <20200707051218.GA16838@bluezbox.com> In-Reply-To: <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com> References: <mailman.75.1593950402.45034.freebsd-arm@freebsd.org> <1731fbded28.10a3342f0357159.8148813293316485882@fkardame.com> <20200706204707.GA94158@bluezbox.com> <0A2E974E-39D3-46C8-8791-3BD914EBE7E9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Millard (marklmi@yahoo.com) wrote: > > > On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko <gonzo at bluezbox.com> wrote: > > > Furkan Salman (furkan@fkardame.com) wrote: > >> Hello Peter, > >> > >> I have rockpiE which is somewhat similar to Rock64, If s133pwa1k9r@ or gonzo@ can confirm if rockpie can be used to test RK3328 Lan issue then I am happy to help with testing. > > > > > > Hi Furkan, > > > > Yes, RockPi E seems to be a good test target. If you could check the > > GigE interface before and after the patch. Whether it works/doesn't work > > and if it works in both cases - try testing performance with iperf3, > > just to see if performance was affected in any way. > > For folks not familiar with the general type of activity > or specifically with iperf3 (or other specifics), more > detailed information to "collect and report . . ., collecting > the information via the commands . . ." could help: more > step-by-step. Good idea. To test inteface performance you need two instances of the iperf3 program: server and client. Server can be FreeBSD, Linux, or macOS machine, shouldn't matter. Should be connected to the wired network though, as close to the board as possible, to make sure we're testing the board's interface and not the narrowest link between client and server. On the server machine install iperf3 package and run iperf -s On the board run iperf3 -c <serverip>. This is normal mode: client sends as much data as possible and server receives, so the results are TX speed. Output should look like this: Connecting to host 192.168.10.1, port 5201 [ 5] local 192.168.10.117 port 56650 connected to 192.168.10.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 55.3 MBytes 464 Mbits/sec 0 403 KBytes [ 5] 1.00-2.00 sec 54.6 MBytes 458 Mbits/sec 0 567 KBytes [ 5] 2.00-3.00 sec 54.2 MBytes 455 Mbits/sec 0 692 KBytes [ 5] 3.00-4.00 sec 54.0 MBytes 453 Mbits/sec 0 798 KBytes [ 5] 4.00-5.00 sec 54.1 MBytes 454 Mbits/sec 0 892 KBytes [ 5] 5.00-6.00 sec 54.5 MBytes 457 Mbits/sec 0 927 KBytes [ 5] 6.00-7.00 sec 54.5 MBytes 457 Mbits/sec 0 927 KBytes [ 5] 7.00-8.00 sec 54.7 MBytes 459 Mbits/sec 0 929 KBytes [ 5] 8.00-9.00 sec 54.7 MBytes 459 Mbits/sec 0 929 KBytes [ 5] 9.00-10.00 sec 54.3 MBytes 455 Mbits/sec 0 929 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec 0 sender [ 5] 0.00-11.15 sec 545 MBytes 410 Mbits/sec receiver To test RX speed run "iperf3 -R -c <serverip>". -R is for reverse mode: server sends and client receives. The output format is simmilar: root@:/ # iperf3 -R -c 192.168.10.1 Connecting to host 192.168.10.1, port 5201 Reverse mode, remote host 192.168.10.1 is sending [ 5] local 192.168.10.117 port 36908 connected to 192.168.10.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 18.7 MBytes 156 Mbits/sec [ 5] 1.00-2.01 sec 8.31 MBytes 69.0 Mbits/sec [ 5] 2.01-3.01 sec 18.3 MBytes 154 Mbits/sec [ 5] 3.01-4.00 sec 20.3 MBytes 171 Mbits/sec [ 5] 4.00-5.01 sec 9.92 MBytes 82.6 Mbits/sec [ 5] 5.01-6.00 sec 20.3 MBytes 171 Mbits/sec [ 5] 6.00-7.01 sec 11.4 MBytes 95.5 Mbits/sec [ 5] 7.01-8.00 sec 22.3 MBytes 188 Mbits/sec [ 5] 8.00-9.00 sec 20.8 MBytes 174 Mbits/sec [ 5] 9.00-10.00 sec 20.2 MBytes 170 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-11.00 sec 171 MBytes 130 Mbits/sec 1789 sender [ 5] 0.00-10.00 sec 170 MBytes 143 Mbits/sec receiver As you can see, download on my Firefly-RK3399 is much slower and high number of Retr indicates either packet corruption or packets dropped. > Also: Do you care between debug kernels vs. non-debug > kernels? Debug ones of the appropriate vintage for head > are available via artifacts.ci.freebsd.org but there > might be performance consequences to using such. TX speed difference between GENERIC-NODEBUG and GENERIC on the Firefly is ~40%, so I'd prefer results for NODEBUG, but even with DEBUG kernel it'd be nice to know if there is any effect of the commit. -- gonzo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200707051218.GA16838>