Date: Mon, 6 Jul 2020 23:43:59 -0700 From: Mark Millard <marklmi@yahoo.com> To: Oleksandr Tymoshenko <gonzo@bluezbox.com>, Peter Jeremy <peter@rulingia.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) Message-ID: <EFA17CEC-A2A2-4B0D-B63F-DB4E98CB2672@yahoo.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
On 2020-Jul-6, at 23:22, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Jul-6, at 23:03, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>=20
>> On 2020-Jul-6, at 14:21, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>> On 2020-Jul-6, at 13:47, Oleksandr Tymoshenko <gonzo at =
bluezbox.com> wrote:
>>>=20
>>>> Furkan Salman (furkan@fkardame.com) wrote:
>>>>> Hello Peter,
>>>>>=20
>>>>> 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.
>>>>=20
>>>>=20
>>>> Hi Furkan,
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> It did DHCP to pick up an address just fine during
>> the boot. I ssh'd into it just fine after the boot.
>>=20
>> # 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/arm64=
.aarch64/sys/GENERIC arm64 aarch64 1300100 1300092
>>=20
>> # 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>
>> . . .
>>=20
>> I'll note that the Rock64 is the only thing running a debug
>> kernel for this note.
>>=20
>> An rsync copying an approximately 4 GiByte tar file to the Rock64
>> reported:
>>=20
>> # rsync -axHh --info=3Dprogress2 --delete -r =
/usr/obj/clang-cortexA53-installworld-poud.tar X@Y:/tmp/
>>=20
>> 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=3D0/1)
>>=20
>> 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.
>>=20
>> For reference, locally duplicating the file on the Rock64 via
>> rsync reported:
>>=20
>> # 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)
>>=20
>> (from/to: same media). I do not expect that the rsync over the
>> network was limited by the target media on the Rock64.
>>=20
>> Copying from the same machine to a large, fast machine instead
>> of to the Rock64:
>>=20
>> # 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)
>>=20
>> So that should not be the side constraining the to-Rock64
>> rate.
>>=20
>> Copying from the Rock64 to the large, fast machine:
>>=20
>> 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)
>>=20
>> It did not list figures much higher than above, so slower than
>> the copy to the Rock64 fairly generally.
>>=20
>> 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.=20
>>=20
>> I hope that the above helps.
>>=20
>> 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.
>>=20
>=20
> 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:
>=20
> # 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 =20
> [ 5] 1.00-2.00 sec 45.4 MBytes 380 Mbits/sec 0 730 =
KBytes =20
> [ 5] 2.00-3.00 sec 44.9 MBytes 376 Mbits/sec 0 730 =
KBytes =20
> [ 5] 3.00-4.00 sec 45.3 MBytes 380 Mbits/sec 0 730 =
KBytes =20
> [ 5] 4.00-5.00 sec 44.7 MBytes 375 Mbits/sec 0 730 =
KBytes =20
> [ 5] 5.00-6.00 sec 45.2 MBytes 378 Mbits/sec 0 730 =
KBytes =20
> [ 5] 6.00-7.00 sec 44.7 MBytes 376 Mbits/sec 0 730 =
KBytes =20
> [ 5] 7.00-8.00 sec 44.6 MBytes 374 Mbits/sec 0 730 =
KBytes =20
> [ 5] 8.00-9.00 sec 44.7 MBytes 375 Mbits/sec 0 730 =
KBytes =20
> [ 5] 9.00-10.00 sec 45.3 MBytes 380 Mbits/sec 0 730 =
KBytes =20
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ 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
>=20
> # 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 =20=
> [ 5] 1.00-2.00 sec 61.3 MBytes 514 Mbits/sec =20=
> [ 5] 2.00-3.00 sec 61.3 MBytes 515 Mbits/sec =20=
> [ 5] 3.00-4.00 sec 61.4 MBytes 515 Mbits/sec =20=
> [ 5] 4.00-5.00 sec 61.4 MBytes 515 Mbits/sec =20=
> [ 5] 5.00-6.00 sec 61.2 MBytes 513 Mbits/sec =20=
> [ 5] 6.00-7.00 sec 61.4 MBytes 515 Mbits/sec =20=
> [ 5] 7.00-8.00 sec 61.3 MBytes 514 Mbits/sec =20=
> [ 5] 8.00-9.00 sec 61.4 MBytes 515 Mbits/sec =20=
> [ 5] 9.00-10.00 sec 61.3 MBytes 514 Mbits/sec =20=
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ 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
>=20
> I'll note that I run with the following in /etc/sysctl.conf :
>=20
> # 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
>=20
> 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.
Looks like it will be some time before I deal with
updating to a more modern kernel/world (non-debug).
But I switched back to my non-debug head -r360311
kernel (and dtb) build and here are the iperf3
results for that context:
# iperf3 -c 192.168.1.122
Connecting to host 192.168.1.122, port 5201
[ 5] local 192.168.1.109 port 39541 connected to 192.168.1.122 port =
5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 73.6 MBytes 617 Mbits/sec 0 1.07 MBytes =
=20
[ 5] 1.00-2.00 sec 72.9 MBytes 612 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 2.00-3.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 3.00-4.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 4.00-5.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 5.00-6.00 sec 72.9 MBytes 611 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 6.00-7.00 sec 72.7 MBytes 610 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 7.00-8.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 8.00-9.00 sec 72.8 MBytes 611 Mbits/sec 0 1.60 MBytes =
=20
[ 5] 9.00-10.00 sec 72.8 MBytes 610 Mbits/sec 0 1.60 MBytes =
=20
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 729 MBytes 611 Mbits/sec 0 =
sender
[ 5] 0.00-10.32 sec 729 MBytes 593 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 50696 connected to 192.168.1.122 port =
5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec =20
[ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 3.00-4.00 sec 84.4 MBytes 708 Mbits/sec =20
[ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec =20
[ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec =20
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.31 sec 1.07 GBytes 892 Mbits/sec 55 =
sender
[ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec =
receiver
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFA17CEC-A2A2-4B0D-B63F-DB4E98CB2672>