Date: Tue, 7 Jul 2020 09:42:51 +0300 From: Sleep Walker <s199p.wa1k9r@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>, Peter Jeremy <peter@rulingia.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) Message-ID: <CAHa8N890eoXu0K9oAunNNt3wn5tvx8rytxtnmJ7XBrfL3MAJpA@mail.gmail.com> In-Reply-To: <EB92D6CC-940A-4429-A257-7D17955B8379@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> <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.com> <EB92D6CC-940A-4429-A257-7D17955B8379@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! On NanoPC-T4 root@nanopc-t4:~ # uname -aUK FreeBSD nanopc-t4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362798M 0fb6ad5-c996(nanopi): Mon Jul 6 10:38:48 MSK 2020 root@dev.kubsu.ru:/usr/crochet/work/obj/usr/crochet/src-13.0/arm64.aarch64/= sys/FREENAS arm64 1300100 1300100 root@nanopc-t4:~ # sysctl dev.cpu.0.freq dev.cpu.0.freq: 1416 root@nanopc-t4:~ # iperf3 -c 192.168.1.100 iperf3: error - unable to connect to server: Connection refused root@nanopc-t4:~ # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 65449 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 60.6 MBytes 509 Mbits/sec 0 418 KBytes [ 5] 1.00-2.00 sec 60.0 MBytes 504 Mbits/sec 0 592 KBytes [ 5] 2.00-3.00 sec 59.8 MBytes 501 Mbits/sec 0 724 KBytes [ 5] 3.00-4.00 sec 59.8 MBytes 501 Mbits/sec 0 835 KBytes [ 5] 4.00-5.00 sec 59.8 MBytes 501 Mbits/sec 0 847 KBytes [ 5] 5.00-6.00 sec 59.8 MBytes 501 Mbits/sec 0 847 KBytes [ 5] 6.00-7.00 sec 59.8 MBytes 501 Mbits/sec 0 847 KBytes [ 5] 7.00-8.00 sec 59.8 MBytes 501 Mbits/sec 0 848 KBytes [ 5] 8.00-9.00 sec 59.8 MBytes 501 Mbits/sec 0 848 KBytes [ 5] 9.00-10.00 sec 59.8 MBytes 501 Mbits/sec 0 848 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 599 MBytes 502 Mbits/sec 0 sende= r [ 5] 0.00-10.34 sec 599 MBytes 486 Mbits/sec receiver iperf Done. root@nanopc-t4:~ # iperf3 -R -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.101 port 57851 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 3.99 MBytes 33.1 Mbits/sec [ 5] 1.01-2.01 sec 3.78 MBytes 31.6 Mbits/sec [ 5] 2.01-3.01 sec 4.86 MBytes 40.9 Mbits/sec [ 5] 3.01-4.01 sec 2.19 MBytes 18.4 Mbits/sec [ 5] 4.01-5.00 sec 2.78 MBytes 23.4 Mbits/sec [ 5] 5.00-6.00 sec 6.57 MBytes 55.3 Mbits/sec [ 5] 6.00-7.00 sec 4.15 MBytes 34.8 Mbits/sec [ 5] 7.00-8.01 sec 3.42 MBytes 28.2 Mbits/sec [ 5] 8.01-9.01 sec 5.13 MBytes 43.2 Mbits/sec [ 5] 9.01-10.00 sec 2.26 MBytes 19.2 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.33 sec 39.2 MBytes 31.8 Mbits/sec 1276 sender [ 5] 0.00-10.00 sec 39.1 MBytes 32.8 Mbits/sec receiver iperf Done. root@nanopc-t4:~ # iperf3 -u -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.101 port 60441 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 90 [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 89 [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 90 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/898 (0%) sender [ 5] 0.00-10.04 sec 1.25 MBytes 1.04 Mbits/sec 0.018 ms 0/898 (0%) receiver iperf Done. root@nanopc-t4:~ # =D0=B2=D1=82, 7 =D0=B8=D1=8E=D0=BB. 2020 =D0=B3. =D0=B2 09:22, Mark Millard= via freebsd-arm < freebsd-arm@freebsd.org>: > On 2020-Jul-6, at 23:03, Mark Millard <marklmi at yahoo.com> wrote: > > > > On 2020-Jul-6, at 14:21, Mark Millard <marklmi at 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. > >> > >> 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. > > > > I put a copy of the -r362982 *debug* kernel from > > artifacts.ci.freebsd.org on the Rock64 V2.0 that > > I sometimes have access to. There are no hardware > > mods to the Rock64 V2.0. > > > > It did DHCP to pick up an address just fine during > > the boot. I ssh'd into it just fine after the boot. > > > > # uname -apKU > > FreeBSD Rock64orRPi4 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362982: Tue > Jul 7 03:41:02 UTC 2020 > root@FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm= 64.aarch64/sys/GENERIC > arm64 aarch64 1300100 1300092 > > > > # ifconfig > > dwc0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu > 1500 > > options=3D80008<VLAN_MTU,LINKSTATE> > > ether # > > hwaddr # > > inet # netmask # broadcast # > > media: Ethernet autoselect (1000baseT <full-duplex>) > > status: active > > nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > > . . . > > > > I'll note that the Rock64 is the only thing running a debug > > kernel for this note. > > > > An rsync copying an approximately 4 GiByte tar file to the Rock64 > > reported: > > > > # rsync -axHh --info=3Dprogress2 --delete -r > /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > > > > 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1) > > > > I'll note that at times it listed over 32MB/s. The storage media > > is a USB3 SSD plugged into the USB3 port. It has the Rock64's > > root filesystem. > > > > For reference, locally duplicating the file on the Rock64 via > > rsync reported: > > > > # rsync -axHh --info=3Dprogress2 -r > /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar > > 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=3D0/1) > > > > (from/to: same media). I do not expect that the rsync over the > > network was limited by the target media on the Rock64. > > > > Copying from the same machine to a large, fast machine instead > > of to the Rock64: > > > > # rsync -axHh --info=3Dprogress2 --delete -r > /usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > > 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=3D0/1) > > > > So that should not be the side constraining the to-Rock64 > > rate. > > > > Copying from the Rock64 to the large, fast machine: > > > > rsync -axHh --info=3Dprogress2 --delete -r > /tmp/clang-cortexA53-installworld-poud.tar X@Y:/tmp/ > > 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=3D0/1) > > > > It did not list figures much higher than above, so slower than > > the copy to the Rock64 fairly generally. > > > > All this activity is over the local network, nothing remote. > > All machines were running head -r360311 (non-debug), except > > for the Rock64 having the -r362982 *debug* kernel instead. > > > > I hope that the above helps. > > > > I see that there are now iperf3 usage instructions so at some > > point I may get that going and report the results, including > > doing a non-debug kernel build and install. > > > > Still using the debug kernel, but I figured I'd show > the results from proving that I can get iperf3 to do > the requested type of testing: > > # iperf3 -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > [ 5] local 192.168.1.109 port 17015 connected to 192.168.1.122 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 45.4 MBytes 381 Mbits/sec 0 730 KBytes > > [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 KBytes > > [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 KBytes > > [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes > > [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes > > [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 KBytes > > [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 KBytes > > [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 KBytes > > [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 KBytes > > [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 450 MBytes 377 Mbits/sec 0 > sender > [ 5] 0.00-10.62 sec 450 MBytes 355 Mbits/sec > receiver > > # iperf3 -R -c 192.168.1.122 > Connecting to host 192.168.1.122, port 5201 > Reverse mode, remote host 192.168.1.122 is sending > [ 5] local 192.168.1.109 port 54738 connected to 192.168.1.122 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec > [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec > [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec > [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec > [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec > [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.61 sec 614 MBytes 486 Mbits/sec 28 > sender > [ 5] 0.00-10.00 sec 613 MBytes 515 Mbits/sec > receiver > > I'll note that I run with the following in /etc/sysctl.conf : > > # The Rock64 does not seem to automatically adjust from 600MHz, > # so do so manually. (The specifics likely would not be > # appropriate to the RPi4/3.) > dev.cpu.0.freq=3D1200 > > It is a historical artifact that I've not checked on the > status of in a very long time: it works so I leave it > there. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHa8N890eoXu0K9oAunNNt3wn5tvx8rytxtnmJ7XBrfL3MAJpA>