コグノスケ

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

過去から未来へ表示

もっと前

2018年12月15日 >>> 2018年12月2日

もっと後

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)

コメント一覧

コメントはありません。

この記事にコメントする

Tinker Boardでは不具合再現せず

目次: ROCK64/ROCKPro64

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から転記しておくことにした。少し加筆した。

編集者:すずき(2023/05/15 04:02)

コメント一覧

コメントはありません。

この記事にコメントする

2018年12月11日

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さん(2018/12/18 13:31)
> Rockchip の U-boot は何かおかしいんだろうか……？

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

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

> vmlinux が 300MB とかになります。
おそらくですが、それデバッグ・シンボルが引っ付いてますね。
だた、next はもう用が済んでるんで最新のもので実際に確認したわけではありません
少なくても、ちょい前にaarch64で弄ってた時は(ver 4.19.0)、20MB程度でした。
すずきさん(2018/12/19 11:54)
> 但し、これもう一年以上前の話で、既に直ってたハズなんですけど…
> 具体的にどのツリーを使ったか明示してもらえれば、ココだと提示できますけど
> 使ったツリーが不明なんで、提供できるのはこの程度の情報だけです。

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 程度になります。
T4さん(2018/12/21 10:14)
私は、Tinker Board を持ってないんで、これに付いては何も語れません

気になったのは↓方です。
> この症状 ROCK64 も同じでした。
すずきさん(2018/12/22 02:10)
失礼しました。Rock64 の方は、

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

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

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

確かに、過去にそう言うバージョンはありました。
しかし、提示のバージョンに関しては、コードを見ても既に直してありますし
また、実際に "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/27 00:22)
確認いただいてありがとうございます。直っているなら良かったです。

今は、あえて試そうとは思わないですが、U-Boot に興味が沸いたら見てみます。

この記事にコメントする

2018年12月9日

permalink

編集する

最初に触ったPC

私は、比較的PCと出会った時期は遅い（※）ので、パソコン原始時代をほとんど知らないですが、それでも当時のマシンと、今使っているRyzen 7マシンを比べると隔世の感があります。

（※）初めて触ったのは中学校にあったPC9821-Cb2、買ったのはPC9821-V7でCPUはPentium/75MHzだった、はず。

中学生で思い出しましたが、Aboutページの写真（Facebookのアイコンでもある）は中学2年生の時の顔です。現像した写真のスキャンではなく、当時珍しかった「デジカメ」で撮った写真です。機種は覚えていませんが、フロッピーに記録するタイプでした。

当時とそんなに顔は変わっていませんが、髪はかなり白くなりました。何でだろ、体質なのかな……？

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

編集者:すずき(2018/12/12 02:09)

コメント一覧

コメントはありません。

この記事にコメントする

2018年12月6日

permalink

編集する

PCの進歩

Ryzen 7は8コア16スレッドCPUですが、5万円もしません。10万円あれば、Ryzen 7 2700, 32GB DDR4, NVMe SSD, マザーボードを買ってもお釣りが来てしまいます。

これほどお安く16並列ビルド（make -j16）に耐えうるCPU, I/O, メモリが購入できる時代が来るとは思いませんでした。一昔前なら、サーバー用の異常に高価なシステムでしか実現できなかったことです。

技術の進歩って素晴らしいですね。

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

編集者:すずき(2018/12/16 00:00)

コメント一覧

コメントはありません。

この記事にコメントする

2018年12月5日

permalink

編集する

デグレ確認のためASUS Tinker Board購入

目次: ROCK64/ROCKPro64

ASUS Tinker Boardを買いました。RK3288搭載のボードです。RK3288は2014年に登場した32bit CPU（Cortex-A17 x 4）なSoCです。今となっては少し古く感じます。

今あえてTinker Boardを買った理由は、私がlinux-nextに入れた変更（2018年11月10日の日記参照）でRK3288搭載のASUS Chromebook C201がデグレしたらしく、再現環境が欲しかったからです。

パッチに対し、海外の方からの指摘が来ており、症状としてはDMACのコードのどこかでカーネルが吹き飛んでしまうとのことですが、手元のROCK64（RK3328）では再現しません。

Chromebook C201を買うのが一番良いんですが、5万円近くしますし、買っても使う予定がないので、あまり買いたくありませんでした…。

対してTinker Boardなら1万円しませんし、同じRK3288搭載ですし、症状が再現しないかなあ、なんてことを期待しています。

今はDebianを起動しただけで特に何も触っていませんが、週末辺りにでもカーネル入れ替えにトライしてみようと思います。

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

編集者:すずき(2023/05/15 04:01)

コメント一覧

コメントはありません。

この記事にコメントする

2018年12月4日

permalink

編集する

突然動かなくなるlinux-next

いつものようにlinux-nextを最新版にrebaseしたら、ROCK64が起動しなくなってしまいました。起動時に恐ろしい量のエラーが出てpanicします。エラーメッセージを斜め読みするとDMACとSPIのエラーに見えたので、無効化してみましたが、今度はeMMCが死んでrootfsが読めずやっぱりpanicします。これはダメだ。

調べてみると、DMA関連のパッチ（LKMLへのリンク）が原因でした。MLの議論を見ると、原因も判明しているようですし、そのうちlinux-nextも直るでしょう（後日談: 次の日に直っていました）。

今回初めてまともにlinux-nextをgit bisectしましたが、git bisect goodもしくはbadを打つ度に、ほぼ毎回フルビルドになってしまい、とにかくビルドの時間が掛かって辛かったです。

先日Ryzen 7にCPUを換装していなかったら、間違いなく途中で諦めていたと思います……。

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

編集者:すずき(2018/12/12 01:51)