コグノスケ

もっと前

2018年 12月 17日 -
2018年 12月 8日

もっと後

未来から過去へ表示(*)
link

過去から未来へ表示

日々

2018年 12月 15日

link permalink

ARM ワンボード PC のネットワーク

Raspberry Pi 対抗ボードの多くは Raspberry Pi 3 の Ethernet が遅いこと（USB 接続らしい）を引き合いに出し、ネットワークが速いことを宣伝文句にしています。

宣伝文句自体は疑っていませんが、どの程度の差があるかは知らないので、測定してみました。ちょうど Tinker Board も購入しましたし、Rockchip 同士の比較もしてみたいと思います。

測定方法

測定は簡単です。受信側の PC で下記を実行します。

$ iperf3 -s -p 11111

送信側の各種ボードで下記を実行します。

$ iperf3 -c (PC の IP アドレス) -p 11111

受信側の PC の CPU は Ryzen 7 2700 で、マザーボードは ASUS B450-F GAMING です。OS は Debian GNU/Linux amd64 の Testing 版です。測定時点でのカーネルは 4.18.0-2-amd64 というバージョンになっていました。

測定結果

結果だけ先に言うと Tinker Board（RK3288）の方が速いです。ROCK64（RK3328）の方が後発の SoC なのですが、Ethernet は遅いみたいですね。

ちなみに Raspberry Pi 3 は 94Mbps でした。そもそも Gigabit Ether じゃないので、比べ物になりません。

Tinker Board: 942Mbits/sec
ROCK64: 805Mbits/sec
Raspberry Pi 3 Model B: 94Mbits/sec

念のため各ボードの Ethernet ケーブルを入れ替えてみましたが、結果は変わりませんでした。

参考までにファイルサーバとして使っている Pentium J のマシンから、同様の計測を行ったところ 942Mbits/sec でした。

測定のログ

結果はこんな感じでした。

Tinker Board (RK3288) での iperf3 実行結果

katsuhiro@linaro-alip:~$ iperf3 -c 192.168.1.2 -p 11111
Connecting to host 192.168.1.2, port 11111
[  4] local 192.168.1.16 port 58608 connected to 192.168.1.2 port 11111
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   113 MBytes   950 Mbits/sec    0    358 KBytes
[  4]   1.00-2.00   sec   112 MBytes   942 Mbits/sec    0    358 KBytes
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    358 KBytes
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    358 KBytes
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    358 KBytes
[  4]   5.00-6.00   sec   112 MBytes   943 Mbits/sec    0    406 KBytes
[  4]   6.00-7.00   sec   112 MBytes   941 Mbits/sec    0    406 KBytes
[  4]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0    406 KBytes
[  4]   8.00-9.00   sec   112 MBytes   941 Mbits/sec    0    406 KBytes
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec    0    406 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec                  receiver

iperf Done.

Rock64 (RK3328) での iperf3 実行結果

katsuhiro@rock64:~$ iperf3 -c 192.168.1.2 -p 11111
Connecting to host 192.168.1.2, port 11111
[  4] local 192.168.1.102 port 54768 connected to 192.168.1.2 port 11111
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  97.6 MBytes   819 Mbits/sec    0    356 KBytes
[  4]   1.00-2.00   sec  96.4 MBytes   808 Mbits/sec    0    395 KBytes
[  4]   2.00-3.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   3.00-4.00   sec  95.7 MBytes   803 Mbits/sec    0    395 KBytes
[  4]   4.00-5.00   sec  95.8 MBytes   803 Mbits/sec    0    395 KBytes
[  4]   5.00-6.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   6.00-7.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   7.00-8.00   sec  95.7 MBytes   803 Mbits/sec    0    395 KBytes
[  4]   8.00-9.00   sec  95.8 MBytes   804 Mbits/sec    0    395 KBytes
[  4]   9.00-10.00  sec  95.8 MBytes   803 Mbits/sec    0    395 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   960 MBytes   805 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   958 MBytes   804 Mbits/sec                  receiver

iperf Done.

Raspberry Pi 3 Model B での iperf3 実行結果

katsuhiro@raspberrypi:~ $ iperf3 -c 192.168.1.2 -p 11111
Connecting to host 192.168.1.2, port 11111
[  4] local 192.168.1.105 port 46476 connected to 192.168.1.2 port 11111
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  11.3 MBytes  94.6 Mbits/sec    0   29.7 KBytes
[  4]   1.00-2.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   2.00-3.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   3.00-4.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   4.00-5.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   5.00-6.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   6.00-7.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   7.00-8.00   sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
[  4]   8.00-9.00   sec  11.2 MBytes  94.2 Mbits/sec    0   29.7 KBytes
[  4]   9.00-10.00  sec  11.2 MBytes  94.1 Mbits/sec    0   29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  94.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  94.2 Mbits/sec                  receiver

iperf Done.

[編集者: すずき]

[更新: 2018年 12月 16日 01:11]

編集する

コメント一覧

コメントはありません。

この記事にコメントする

2018年 12月 14日

link permalink

不具合再現せず

Tinker Board でサウンド周りを有効にして linux-next を動かしてみたものの、指摘された不具合（2018年 12月 5日の日記参照）が出ません。

メールでは DMA ドライバのどこかでクラッシュした、と言われました。サウンド周りのハードウェアは I2S とコーデックが居ますが、DMA を使うのは I2S だけです。コーデック max98090 は SoC 外部に居ますから、SoC 内部の DMA を使う術がありません。

I2S が原因ならば、SoC 内部のハードウェア起因ですから、Tinker Board だろうが Chromebook C201 だろうが、ボードに関わらず現象が再現しても良さそうなのに。

Chromebook で使われているグルードライバ rockchip-snd-max98090 の影響も疑って、Chromebook C201 のデバイスツリー（rk3288-veyron-speedy.dts）からデバイスノードの設定をパクってきて、max98090 を spdif-transimtter に差し替えて（Tinker Board に max98090 は搭載されていない）、無理やり動かしてみましたが、特に何事も無く動いてしまいました。

どうやっても Chromebook C201 じゃないと再現しないのかな？良くわからないバグだ……。

Tinker Board のアナログオーディオ出力

ROCK64 のときはアナログオーディオ出力でも HDMI 出力でも、SoC 内蔵の I2S ハードが動作しましたが、Tinker Board はちょっと事情が違います。

Tinker Board にもアナログオーディオ端子は付いていますが、接続先は RK3288 ではなくオンボードの USB Audio（Realtek ALC4040）です。アナログオーディオのためにわざわざ専用 USB デバイスを載せるとは、豪華なボードだなあ〜。

というわけで、Tinker Board で SoC 内蔵の I2S が動くかどうか試すには、アナログオーディオ端子ではダメで、HDMI 出力じゃないと本当に動作しているかどうかわからないです。我が家にはデジタルテレビならありますが、ボードからケーブルが届かないですね。

できれば HDMI が映せて、音も出せて、ボードの隣に置いても邪魔にならないくらい小さいモニタがあるとベストですが、我が家にそんなもんは無い……。

メモ: 技術系の話は Facebook から転記しておくことにした。少し加筆した。

[編集者: すずき]

[更新: 2018年 12月 16日 00:37]

編集する

コメント一覧

コメントはありません。

この記事にコメントする

2018年 12月 11日

link permalink

Tinker Board と linux-next

先日購入（2018年 12月 5日の日記参照）した Tinker Board で linux-next を動かしてみたら、特に何も引っかかることなく起動しました。素敵。しかし調子に乗ってコンフィグをガチャガチャ弄ってたら起動しなくなってしまいました。

ちょっと焦りましたが、同時に Rock64 も起動しなくなっていたので、原因はコンフィグじゃなくて、linux-next の 12月 11日版を引っ張ってきたことのようです。先週もなってたなあ。またか〜。

やたらデカい vmlinux

AArch32 と AArch64 のビルドを往復でやっていて、vmlinux のリンク速度が全然違うことに気づきました。AArch64 の方が桁違いに遅いです。

AArch32 だと vmlinux のサイズは 20MB くらいですが、AArch64 向けにビルドするとなぜか vmlinux が 300MB とかになります。なぜこんなにデカいんでしょう。リンクが遅くて辛いです。

U-Boot もおかしい

Tinker Board は U-boot で saveenv すると二度と起動しなくなります。linux-next を起動するコマンドを save したかったのですが、できません。ちょっと不便です。

この症状 ROCK64 も同じでした。Rockchip の U-boot は何かおかしいんだろうか……？

メモ: 技術系の話は Facebook から転記しておくことにした。少し加筆。

[編集者: すずき]

[更新: 2018年 12月 16日 00:12]

編集する

コメント一覧

T4
> Rockchip の U-boot は何かおかしいんだろうか……？

おかしかったんですよ
"saveenv を実行すると自身のコード領域に書き込んでしまう"
ってのが有りました。

但し、これもう一年以上前の話で、既に直ってたハズなんですけど…
具体的にどのツリーを使ったか明示してもらえれば、ココだと提示できますけど
使ったツリーが不明なんで、提供できるのはこの程度の情報だけです。

> vmlinux が 300MB とかになります。
おそらくですが、それデバッグ・シンボルが引っ付いてますね。
だた、next はもう用が済んでるんで最新のもので実際に確認したわけではありません
少なくても、ちょい前にaarch64で弄ってた時は(ver 4.19.0)、20MB程度でした。

(2018年12月18日 13:31:41)
すずき
> 但し、これもう一年以上前の話で、既に直ってたハズなんですけど…
> 具体的にどのツリーを使ったか明示してもらえれば、ココだと提示できますけど
> 使ったツリーが不明なんで、提供できるのはこの程度の情報だけです。

ASUS のサイトからダウンロードできる下記のイメージをそのまま使っています。日付を見るとほぼ 1年前ですね。

http://dlcdnet.asus.com/pub/ASUS/mb/Linux/Tinker_Board_2GB/20170417-tinker-board-linaro-stretch-alip-v1.8.zip

> おそらくですが、それデバッグ・シンボルが引っ付いてますね。
> だた、next はもう用が済んでるんで最新のもので実際に確認したわけではありません
> 少なくても、ちょい前にaarch64で弄ってた時は(ver 4.19.0)、20MB程度でした。

ご指摘の通りで、arm64 の場合、make defconfig で CONFIG_DEBUG_INFO=y
になってしまうらしく（なんでこんな設定になってるんだろ…）、
デバッグシンボルが全力で付いていました。

CONFIG_DEBUG_INFO を外せば 30MB 程度になります。

(2018年12月19日 11:54:59)
T4
私は、Tinker Board を持ってないんで、これに付いては何も語れません

気になったのは↓方です。
> この症状 ROCK64 も同じでした。

(2018年12月21日 10:14:56)
すずき
失礼しました。Rock64 の方は、

U-Boot 2017.09-rockchip-ayufan-1025-g482cd6ec8b

でした。これも 1年位前のままですね…。

saveenv で U-Boot が潰れるかどうかは再確認していません。もし起動しなくなると、戻すのが大変面倒なので…。
(2018年12月22日 02:10:48)
T4
再現しませんね

確かに、過去にそう言うバージョンはありました。
しかし、提示のバージョンに関しては、コードを見ても既に直してありますし
また、実際に "MicroSD / SPI-FLASH" の双方で試してみても問題は発生しませんでした。

申し訳ないが、指摘の事項は正しいと思えない。
（＊再確認していません。と書いてあるしね）

でも、敢て確認する必要は有りません
万が一環境を壊して戻せなくなったら、目も当てられない

過去に有った問題の該当箇所は、↓に関連した部分です
https://github.com/ayufan-rock64/linux-u-boot/commit/60cc9f538b03e5c1dc1163192d338a8f78e44141#diff-efde2e212b5355a080e3baf561e01218

----
<最初のブート>
DDR version 1.13 20180428
....
U-Boot 2017.09-rockchip-ayufan-1025-g482cd6ec8b (Jul 26 2018 - 08:18:38 +0000)

Model: Pine64 Rock64
DRAM: 4 GiB
MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
...

Hit any key to stop autoboot: 0
=> setenv devnum 3
=> saveenv
Saving Environment to SPI Flash...
SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
Erasing SPI flash...Writing to SPI flash...done

----
=> reset
<２回目のブート>
DDR version 1.13 20180428
....

Hit any key to stop autoboot: 0
=> printenv devnum
devnum=3

(2018年12月25日 12:45:54)
すずき
確認いただいてありがとうございます。直っているなら良かったです。

今は、あえて試そうとは思わないですが、U-Boot に興味が沸いたら見てみます。
(2018年12月27日 00:22:09)