Date: Mon, 6 Jul 2020 23:03:42 -0700 From: Mark Millard <marklmi@yahoo.com> To: Oleksandr Tymoshenko <gonzo@bluezbox.com>, peterz@rulingia.com Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing) Message-ID: <0C77695E-A9D0-410A-B105-5B69823E17E2@yahoo.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
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:
>=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.
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/arm64=
.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.=20
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.
=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?0C77695E-A9D0-410A-B105-5B69823E17E2>