がとらぼ - ページ 330 - では、主にコンピューターハードウエア・ソフトウエア・ネットワーク・ウェブ関係の技術的な情報を提供します

NanoPi NEO CPUクロック変更

NanoPi NEO
画像は使い回し

NanoPi向けのarmbianにはh3consumptionというSoCがH3なボードの制御用スクリプトが標準で入っている。これで簡単にクロックの変更やI/Oのオン・オフなどの制御ができる。
もしも入っていないならGitHubのh3consumptionからスクリプトを取ってくる。

使い方

# h3consumption -h
Usage: h3consumption [-h/-H] [-p] [-g on|off] [-m max_cpufreq] [-c 1|2|3|4]
       [-d dram_freq] [-D dram_freq] [-u on|off] [-e on|off|fast] 

############################################################################

 This tool allows to adjust a few consumption relevant settings of your
 H3 device. Use the following switches

 -h|-H           displays help or verbose help text
 -p              print currently active settings
 -g on|off       disables GPU/HDMI for headless use
 -m max_cpufreq  adjusts maximum allowed cpu clockspeed (mhz)
 -c 1|2|3|4      activate only this count of CPU cores
 -d dram_freq    adjusts dram clockspeed (408 - 624 mhz)
 -D dram_freq    like -d but as low as 132 mhz possible (experimental!)
 -u on|off       enables/disabled all USB ports
 -e on|off|fast  enables/disables Ethernet, the fast switch
                 forces 100 mbits/sec negotiation on gigabit devices
 -w on|off       enables/disables Wi-Fi powermanagement when interface
                 supports this and is controlled by network-manager

############################################################################

初期状態の状態取得

# h3consumption -p
Active settings:

cpu       912 mhz allowed, 1200 mhz possible, 4 cores active

dram      408 mhz

hdmi/gpu  off

usb ports active

eth0      100Mb/s/Full, Link: yes

値の変更

# h3consumption -e fast ←NICの速度変更 効き目なし
# h3consumption -g on ← GPUをOFFからON 変更できた
# h3consumption -m 1200 CPUクロック変更 変更できた
# h3consumption -d 624  DRAMクロックの変更 少しだけ

上では個別にやってるけど並べて指定して実行しても良いっぽい。

値を変更したらNanoPiを再起動する。

変更後の状態取得

# h3consumption -p
Active settings:

cpu       1200 mhz allowed, 1200 mhz possible, 4 cores active

dram      432 mhz

hdmi/gpu  active

usb ports active

eth0      100Mb/s/Full, Link: yes

NICの速度変更はNanoPi NEOはダメっぽい。
GPUをオンにできたけど使い途あるかしら？
DRAMのクロックは624MHzを指定してみたが、408から432MHzになっただけだった。
USBポートのオフ/オンは試していない。
CPUの有効コア数の変更も試していない。

UNIX Benchmarksで計測

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: nanopineo: GNU/Linux
   OS: GNU/Linux -- 3.4.113-sun8i -- #10 SMP PREEMPT Thu Feb 23 19:55:00 CET 2017
   Machine: armv7l (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   06:38:57 up 1 min,  1 user,  load average: 0.40, 0.20, 0.07; runlevel 5

------------------------------------------------------------------------
Benchmark Run: Mon Feb 27 2017 06:38:57 - 07:19:53
0 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        3867822.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      561.2 MWIPS (10.0 s, 7 samples)
Execl Throughput                                351.1 lps   (29.2 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         91428.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           28802.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        202544.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              245420.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  25399.7 lps   (10.0 s, 7 samples)
Process Creation                               1163.1 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1210.7 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    371.5 lpm   (60.1 s, 2 samples)
System Call Overhead                         663878.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    3867822.1    331.4
Double-Precision Whetstone                       55.0        561.2    102.0
Execl Throughput                                 43.0        351.1     81.6
File Copy 1024 bufsize 2000 maxblocks          3960.0      91428.4    230.9
File Copy 256 bufsize 500 maxblocks            1655.0      28802.5    174.0
File Copy 4096 bufsize 8000 maxblocks          5800.0     202544.4    349.2
Pipe Throughput                               12440.0     245420.0    197.3
Pipe-based Context Switching                   4000.0      25399.7     63.5
Process Creation                                126.0       1163.1     92.3
Shell Scripts (1 concurrent)                     42.4       1210.7    285.5
Shell Scripts (8 concurrent)                      6.0        371.5    619.1
System Call Overhead                          15000.0     663878.8    442.6
                                                                   ========
System Benchmarks Index Score                                         197.4

------------------------------------------------------------------------
Benchmark Run: Mon Feb 27 2017 07:19:53 - 08:01:36
0 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       15450436.6 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2236.7 MWIPS (10.0 s, 7 samples)
Execl Throughput                               1539.2 lps   (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        143093.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           43271.2 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        315071.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                              979400.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 122014.1 lps   (10.0 s, 7 samples)
Process Creation                               3950.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2962.2 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    391.4 lpm   (60.3 s, 2 samples)
System Call Overhead                        2509185.9 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   15450436.6   1323.9
Double-Precision Whetstone                       55.0       2236.7    406.7
Execl Throughput                                 43.0       1539.2    357.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     143093.7    361.3
File Copy 256 bufsize 500 maxblocks            1655.0      43271.2    261.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     315071.5    543.2
Pipe Throughput                               12440.0     979400.4    787.3
Pipe-based Context Switching                   4000.0     122014.1    305.0
Process Creation                                126.0       3950.9    313.6
Shell Scripts (1 concurrent)                     42.4       2962.2    698.6
Shell Scripts (8 concurrent)                      6.0        391.4    652.4
System Call Overhead                          15000.0    2509185.9   1672.8
                                                                   ========
System Benchmarks Index Score                                         536.4

前回の弩ノーマル時のベンチマークと比較すると1パラレル(シングル)で120%、4パラレルで125%の数値が出ている。CPUのクロックは131%、DRAMのクロックは106%になっているので結果はそんなもんかという感じ。
SoCの冷却ができていてバッテリー駆動じゃないならCPUクロックはずっと1.2GHzでいいんじゃないだろうか。

OPi-Monitorで見る

h3consumptionでCPUクロック等を変更したのが14:30～14:40頃、UnixBenchの1パラレル計測が14:40～15:15頃、4パラレル計測が15:15～16:00過ぎ。
CPUクロックの緑の線の上限が14:30過ぎに0.9から1.2(GHz)に変わっている。(グラフ右側の目盛り)
DRAMのクロックは基本的には変わらないのでグラフでは紫の線でギザギザになってない方。同じく14:30過ぎに408から432MHzに変更になったのでそこでわずかに高さが変わっている。これも目盛りはグラフの右側の数値(GHz)で見る。
同じく紫のグラフで激しくギザギザになっているのがCPUの使用率。これはグラフ左側の目盛りで見る。
水色のグラフはSoCの温度で、最も負荷が高くなった4パラレル計測時に50℃ということで今の時期は十分な冷却ができているといえる。これもグラフ左側の目盛りで見る。

残念ながらGPU (Mali)をオンにするだけで例えば動画のエンコード・デコードの支援を得られるわけではないので、GPUを使いたいとなったら今のところは色々苦労しなければならないっぽい。1つ前の記事NanoPi NEOでウェブカメラみたいにH.264でエンコードしたいというときにこそGPU支援が欲しいのでここは頑張って使えるようにしたい。
NanoPi NEOじゃなくてディスプレイ出力付きのボードでデスクトップ版のarmbianを使ってるなら簡単かも。

NanoPi NEOの続き。
この手のシングルボードコンピュータを買ってやりたいことの1つは監視カメラ。
シングルボードコンピュータとUSBのウェブカメラがあれば取り敢えずは動画を取得してネットワークに撒くことはできる。しかも非常に低消費電力。

以前にOpenSUSE用ウェブカメラの記事でも書いたがLinuxでウェブカメラを使うのはとても簡単。UVC対応なら特に考えずに接続するだけ。なのでNanoPi NEO + armbian (Linux)でもUVC対応のウェブカメラをUSBポートに繋ぐだけ。

この記事を書く時に実際に使用したウェブカメラ(の広告)

一応接続後に認識されているか確認。

$ ls /dev

video0というのが存在すれば認識されていると思って良い。

それだけじゃ雑すぎだろということならlsusbで見る。

$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 003: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 004 Device 002: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

上の例だとDevice003にWebcam C270というのが認識されている。

ソフトウエア側は今回はVLCを使うことに。

# apt-get install vlc

おそらく素のarmbianだとドッサリとパッケージを入れられるだろうけど待ち時間はそんなでもない。

あとはVLCを実行するだけの筈が、ここからが大変。

とりあえずVLCを実行する。

$ cvlc -vvv v4l2:///dev/video0 --sout '#transcode{vcodec=jpeg,acodec=none}:rtp{sdp=rtsp://:8554/}'

おそらくベースとなるコマンドはこんな感じ。
なお、VLCはrootユーザーでは実行できないのでroot以外のユーザーになって実行するか、rootであるならsudoで他のユーザー指定で実行。もっともLinuxの流儀だと基本的にrootでオペレーションしない筈。
上の指定は、入力は/dev/video0 (ウェブカメラ)、ビデオエンコードはMotion JPEG、音声無し、出力はRTSP、ポート番号は本来のRTSPの554ではなく取り敢えず8554。

実行してから他の端末でRTSPで受信して動画を表示する。
例えばWindowsやLinuxにVLCが入っていてそれで表示するなら

$ vlc -vvv rtsp://192.168.0.82:8554/

上はNanoPiのIPアドレスが192.168.0.82の場合
Windowsの場合はVLCのPath付きで実行してやらないとおそらくVLCが起動しない筈。

若しくはVLCプレーヤーを起動して[メディア][ネットワークストリームを開く]を選択、「ネットワークURLを入力して下さい」にrtsp://192.168.0.82:8554/ を入力する。なお、192.168.0.82の部分はNanoPiのIPアドレスを指定。ポート番号の後の / を忘れずに指定。

Motion JPEGなので軽い方ではあるけどNanoPiで動かすとそうでもない不思議。
あと、Motion JPEGでは動画の幅が640pxまで。

armbian用に作られたVLCはPC用の普通とは少し違う様で、VLCで良く使うコーデック名を指定しても殆どがエラーになる。いろいろ試して使えたのはjpeg, mpgv, h264, theoだけ。
次はMPGV (MPEG-2)で実行

$ cvlc -vvv v4l2:///dev/video0 --sout '#transcode{vcodec=mpgv,vb=1200,width=640,height=360,acodec=none}:rtp{sdp=rtsp://:8554/}'

vcodecにmpgvを指定すると共にvb = 帯域、width,height = 動画の横幅,高さを指定。

MPGVは軽いかと思ったがMotion JPEGで遅いくらいなので全然重い (動画が表示されるまでの時間は短い)。そしてなんか扱いにくい。上の指定では帯域を1200Kbps取っているがこれでも画像はかなり荒い。値をもっと大きくするか指定を外すと綺麗。

次はH.264。

$ cvlc -vvv v4l2:///dev/video0 --sout '#transcode{vcodec=h264,width=640,height=360,acodec=none}:rtp{sdp=rtsp://:8554/}'

VLC 1
三角コーンが表示されたままなので失敗かなと思うくらい待たされる。

VLC 2
やっと映ったかなと思ったら暫くこんなの。また、頻繁に動画からこの状態になる。

VLC 3
映った。(上の画像はイメージです)

予想はしてたがアホみたいに重い。動画が表示されるまでに数十秒待たされて、灰色か緑一面が表示されてしばらくしてやっと正常に表示されたかなと思うとすぐに灰色。これじゃ全然使い物にならない。遅延も酷すぎ。
decoder/packetizer fifo full (data not consumed quickly enough), resetting fifo! というメッセージ多発。

そこで、少しはまともに使えるようにオプションを追加。

transcodeにthreads=4を追加。これで4コア使う？
transcodeにfps=10を追加。動画の動きの滑らかさはなくなるが監視カメラとしては実用的に。
transcodeにvenc=x264指定を追加。(以下)
vencのx264にpreset=ultrafastを追加。綺麗さより動き最優先。
vencのx264にtune=zerolatencyを追加。遅延の少ないチューニング。
vencのx264に他幾つか。

こうなった。

$ cvlc -vvv v4l2:///dev/video0 --sout '#transcode{vcodec=h264,venc=x264{preset=ultrafast,tune=zerolatency,intra-refresh,lookahead=10,keyint=15},width=640,height=360,threads=4,fps=10,acodec=none}:rtp{sdp=rtsp://:8554/}'

FPSを10に抑えたこととスレッドを4にしたのがかなり効いたようで移動する被写体の消滅やワープはなくなった。また、遅延も2秒以内と実用に耐える範囲。解像度が640x360でこの程度ならまぁまぁじゃないかな？

できればもっと軽くて柔軟な指定が可能なコーデックを使いたいところだが良い方法あるかな？VLCを作り直す？

2017年2月28日追記
次の記事のクロック変更を行ってCPUを高速化させた上でFPSを10から5～6 (7はギリギリダメかも)程度に落とすと1280x720の解像度でFIFOバッファの溢れ&リセットが発生せずに安定して動くことを確認。ただし、画像は1280x720の解像度を疑いたくなるほどはっきりしない。要するにボケた感じ。

NEOでウェブカメラ (実用化編) この記事の続き
NEOでウェブカメラ ←いまここ