freebsd-arm Digest, Vol 740, Issue 7 (Rock64 Ethernet testing)
Mark Millard
marklmi at yahoo.com
Tue Jul 7 06:22:22 UTC 2020
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 at 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 at FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1300100 1300092
>
> # ifconfig
> dwc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=80008<VLAN_MTU,LINKSTATE>
> ether #
> hwaddr #
> inet # netmask # broadcast #
> media: Ethernet autoselect (1000baseT <full-duplex>)
> status: active
> nd6 options=29<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=progress2 --delete -r /usr/obj/clang-cortexA53-installworld-poud.tar X at Y:/tmp/
>
> 4.01G 100% 28.91MB/s 0:02:12 (xfr#1, to-chk=0/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=progress2 -r /tmp/clang-cortexA53-installworld-poud.tar /tmp/mmjnk.tar
> 4.01G 100% 38.48MB/s 0:01:39 (xfr#1, to-chk=0/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=progress2 --delete -r /usr/obj/clang-cortexA53-installworld-poud.tar X at Y:/tmp/
> 4.01G 100% 77.32MB/s 0:00:49 (xfr#1, to-chk=0/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=progress2 --delete -r /tmp/clang-cortexA53-installworld-poud.tar X at Y:/tmp/
> 4.01G 100% 21.35MB/s 0:02:59 (xfr#1, to-chk=0/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=1200
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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list