
armbianでNanoPi NEO2が正式サポートに戻ったのは良いんだけど、11月に入ってCPUの最大クロックが1008?から816MHz、DRAMクロックが672から648MHzに落とされた。そんなに安定しないのかしら?
H5ってカタログスペックでは最大1500MHzだった筈が816MHzだと54%でしかない。1GHz?のときで67%しか性能発揮できないのかと残念に思っていたのに更に約20%ダウンはちょっとどうなの。
なお、SoCがH5とA64のデバイスがそうなったということでNanoPi NEO2という機種だけがクロックを下げられたということではないので念の為。
今回使用したのはARMBIAN 5.34 user-built Debian GNU/Linux 9 (stretch) 4.13.11-sunxi64。例によって最新ソースを標準カーネルオプションで自分でビルドしたもの。
armbianの押しディスはUbuntuということでDebian版の新しいイメージファイルは提供されてこなかったが、昨日か一昨日からNanoPi NEO2のダウンロードページでUbuntu版と共にダウンロードできるようになっている。
永らくarmbianのNanoPi NEO2用はCPUの周波数周りの制御と表示ができないという状態が続いていたが、現在はできるようになっているのでその辺りを絡めて再度UnixBenchを実行してみた。
$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 244 us.
hardware limits: 408 MHz - 1.01 GHz
available frequency steps: 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 480 MHz and 816 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 408 MHz.
cpufreq stats: 408 MHz:72.84%, 648 MHz:0.18%, 816 MHz:26.85%, 912 MHz:0.02%, 960 MHz:0.03%, 1.01 GHz:0.07% (205)
analyzing CPU 1:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 244 us.
hardware limits: 408 MHz - 1.01 GHz
available frequency steps: 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 480 MHz and 816 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 408 MHz.
cpufreq stats: 408 MHz:72.84%, 648 MHz:0.18%, 816 MHz:26.85%, 912 MHz:0.02%, 960 MHz:0.03%, 1.01 GHz:0.07% (205)
analyzing CPU 2:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 244 us.
hardware limits: 408 MHz - 1.01 GHz
available frequency steps: 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 480 MHz and 816 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 408 MHz.
cpufreq stats: 408 MHz:72.84%, 648 MHz:0.18%, 816 MHz:26.85%, 912 MHz:0.02%, 960 MHz:0.03%, 1.01 GHz:0.07% (205)
analyzing CPU 3:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 244 us.
hardware limits: 408 MHz - 1.01 GHz
available frequency steps: 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 480 MHz and 816 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 408 MHz.
cpufreq stats: 408 MHz:72.84%, 648 MHz:0.18%, 816 MHz:26.85%, 912 MHz:0.02%, 960 MHz:0.03%, 1.01 GHz:0.07% (205)
ちゃんと表示される安心感。
$ cpufreq-info -p
480000 816000 ondemand
CPUの周波数が可変のガバナーで480〜816MHzで切り替わるのが初期値らしい。
$ cpufreq-info -s
408000:714935, 648000:1071, 816000:330629, 912000:99, 960000:98, 1008000:384 (461)
起動直後だけ912, 960, 1008MHzで動くこともあるが、その後は648, 816, 408MHzだけが使われているよう。ところで上の表示では使うことを指定している低い側のクロックは480MHzだった筈だが何で実際に使われてるのは408MHzなの?初期設定値を直す必要あり?
11月16日にarmbian本家で修正入った模様。
1 2 3 4 | ENABLE=true
MIN_SPEED=480000 #←これ408000に直す?
MAX_SPEED=816000
GOVERNOR=ondemand
|
# ./Run -c 1 -c 4
中略
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: nanopineo2: GNU/Linux
OS: GNU/Linux -- 4.13.11-sunxi64 -- #5 SMP Sat Nov 4 16:56:56 JST 2017
Machine: aarch64 (unknown)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
01:42:33 up 35 min, 1 user, load average: 0.20, 0.05, 0.01; runlevel 5
------------------------------------------------------------------------
Benchmark Run: Mon Nov 06 2017 01:42:33 - 02:11:06
0 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 4037506.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 762.7 MWIPS (10.0 s, 7 samples)
Execl Throughput 979.7 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 119840.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 36258.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 251207.9 KBps (30.0 s, 2 samples)
Pipe Throughput 315941.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 42966.4 lps (10.0 s, 7 samples)
Process Creation 2282.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1664.0 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 475.1 lpm (60.1 s, 2 samples)
System Call Overhead 553484.4 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 4037506.0 346.0
Double-Precision Whetstone 55.0 762.7 138.7
Execl Throughput 43.0 979.7 227.8
File Copy 1024 bufsize 2000 maxblocks 3960.0 119840.4 302.6
File Copy 256 bufsize 500 maxblocks 1655.0 36258.0 219.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 251207.9 433.1
Pipe Throughput 12440.0 315941.3 254.0
Pipe-based Context Switching 4000.0 42966.4 107.4
Process Creation 126.0 2282.5 181.2
Shell Scripts (1 concurrent) 42.4 1664.0 392.5
Shell Scripts (8 concurrent) 6.0 475.1 791.9
System Call Overhead 15000.0 553484.4 369.0
========
System Benchmarks Index Score 273.8
------------------------------------------------------------------------
Benchmark Run: Mon Nov 06 2017 02:11:06 - 02:39:51
0 CPUs in system; running 4 parallel copies of tests
Dhrystone 2 using register variables 16239851.6 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3049.2 MWIPS (10.0 s, 7 samples)
Execl Throughput 2082.2 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 204322.2 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 60596.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 498464.9 KBps (30.0 s, 2 samples)
Pipe Throughput 1262859.8 lps (10.0 s, 7 samples)
Pipe-based Context Switching 154271.9 lps (10.0 s, 7 samples)
Process Creation 4550.7 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 3752.3 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 488.6 lpm (60.2 s, 2 samples)
System Call Overhead 2122985.7 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 16239851.6 1391.6
Double-Precision Whetstone 55.0 3049.2 554.4
Execl Throughput 43.0 2082.2 484.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 204322.2 516.0
File Copy 256 bufsize 500 maxblocks 1655.0 60596.0 366.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 498464.9 859.4
Pipe Throughput 12440.0 1262859.8 1015.2
Pipe-based Context Switching 4000.0 154271.9 385.7
Process Creation 126.0 4550.7 361.2
Shell Scripts (1 concurrent) 42.4 3752.3 885.0
Shell Scripts (8 concurrent) 6.0 488.6 814.3
System Call Overhead 15000.0 2122985.7 1415.3
========
System Benchmarks Index Score 673.7
以前のUnixBenchの結果だとシングルが298.9、4パラレルが771.2だったので92%, 87%とそれぞれ1割程度低下している。もっと落ちるかと思ったけど意外と下がっていない。
/etc/default/cpufrequtils1 2 3 4 5 6 | ENABLE=true
#MIN_SPEED=480000
#MAX_SPEED=816000
MIN_SPEED=0
MAX_SPEED=0
GOVERNOR=ondemand
|
以前にやったように最低・最高クロックの指定を0にすることで利用可能なクロックの最低・最高クロックが使用されるようになる。
なお、MAX_SPEED=0では最大クロックにならない場合はMAX_SPEED=1008000など最大値を具体的な数値で指定する。
# systemctl restart cpufrequtils
(管理者権限で)cpufrequtilsを再起動して設定を反映させる。またはシステムの再起動。
$ cpufreq-info -p
408000 1008000 ondemand
最低408MHz, 最高1008MHzになった。
$ cpufreq-info -s
408000:34184, 648000:808, 816000:27, 912000:22, 960000:74, 1008000:321836 (399)
最大クロックの1008MHzが盛大に使用されているので上手く行った。
一時的に最大クロックを上げるだけであれば以下。
# cpufreq-set -u 1000M 最大クロックの値を1000MHzに変更 # cpufreq-set -f 1000M 最大クロックを1000MHzに固定
ということで最大クロック1008MHzで再度UnixBenchを実行。
======================================================================== BYTE UNIX Benchmarks (Version 5.1.3) System: nanopineo2: GNU/Linux OS: GNU/Linux -- 4.13.11-sunxi64 -- #5 SMP Sat Nov 4 16:56:56 JST 2017 Machine: aarch64 (unknown) Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8") 13:16:03 up 1 min, 1 user, load average: 0.15, 0.11, 0.04; runlevel 5 ------------------------------------------------------------------------ Benchmark Run: Tue Nov 07 2017 13:16:03 - 13:44:24 0 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 5010045.8 lps (10.0 s, 7 samples) Double-Precision Whetstone 942.9 MWIPS (10.0 s, 7 samples) Execl Throughput 1198.3 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 142718.7 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 45978.9 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 290244.0 KBps (30.0 s, 2 samples) Pipe Throughput 393585.1 lps (10.0 s, 7 samples) Pipe-based Context Switching 66809.4 lps (10.0 s, 7 samples) Process Creation 2907.4 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 1975.3 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 546.8 lpm (60.0 s, 2 samples) System Call Overhead 678989.9 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 5010045.8 429.3 Double-Precision Whetstone 55.0 942.9 171.4 Execl Throughput 43.0 1198.3 278.7 File Copy 1024 bufsize 2000 maxblocks 3960.0 142718.7 360.4 File Copy 256 bufsize 500 maxblocks 1655.0 45978.9 277.8 File Copy 4096 bufsize 8000 maxblocks 5800.0 290244.0 500.4 Pipe Throughput 12440.0 393585.1 316.4 Pipe-based Context Switching 4000.0 66809.4 167.0 Process Creation 126.0 2907.4 230.7 Shell Scripts (1 concurrent) 42.4 1975.3 465.9 Shell Scripts (8 concurrent) 6.0 546.8 911.3 System Call Overhead 15000.0 678989.9 452.7 ======== System Benchmarks Index Score 340.3 ------------------------------------------------------------------------ Benchmark Run: Tue Nov 07 2017 13:44:24 - 14:12:52 0 CPUs in system; running 4 parallel copies of tests Dhrystone 2 using register variables 20123717.5 lps (10.0 s, 7 samples) Double-Precision Whetstone 3770.7 MWIPS (10.0 s, 7 samples) Execl Throughput 2364.6 lps (29.9 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 252706.0 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 75117.0 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 544883.8 KBps (30.0 s, 2 samples) Pipe Throughput 1557000.2 lps (10.0 s, 7 samples) Pipe-based Context Switching 251637.6 lps (10.0 s, 7 samples) Process Creation 5481.4 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 4346.2 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 548.7 lpm (60.3 s, 2 samples) System Call Overhead 2613135.0 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 20123717.5 1724.4 Double-Precision Whetstone 55.0 3770.7 685.6 Execl Throughput 43.0 2364.6 549.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 252706.0 638.1 File Copy 256 bufsize 500 maxblocks 1655.0 75117.0 453.9 File Copy 4096 bufsize 8000 maxblocks 5800.0 544883.8 939.5 Pipe Throughput 12440.0 1557000.2 1251.6 Pipe-based Context Switching 4000.0 251637.6 629.1 Process Creation 126.0 5481.4 435.0 Shell Scripts (1 concurrent) 42.4 4346.2 1025.1 Shell Scripts (8 concurrent) 6.0 548.7 914.5 System Call Overhead 15000.0 2613135.0 1742.1 ======== System Benchmarks Index Score 824.7
あれっ?(明確に)1008MHzだと以前より数値上がった。ということは・・・これまで(クロックが表示されないので不明だったのと、そう言われていたから)1008MHzで動いていたと思ったのが間違いで実は912MHzあたりで動いていた?
4パラレル824.7って凄いな・・(ボソッ)
関連記事:- アッチッチなNanoPi NEO3を冷やしたい パッド交換
- NanoPi NEO3冷却力強化後のUnixBench
- アッチッチなNanoPi NEO3を冷やしたい
- NTPサーバの時刻ソースに対するズレの調整
- NanoPi NEO3をv6プラスのルーターにする systemd-networkd + nftables
- NanoPi NEO3のUSB3.0ポートのネットワーク速度
- NanoPi NEO3でArmbian よきところでUnixBench
- NanoPi NEO3が届いた
- NanoPi NEOにRTCモジュールを付ける
- 新しい中華GPSモジュールとChronyで作るNTPサーバ (中編)
- 新しい中華GPSモジュールとChronyで作るNTPサーバ (前編)
- Prometheus2とGrafana6によるシステム監視 シングルボードコンピュータの温度表示
- NanoPi NEOでNTPサーバ再構築 (全まとめ)
- NanoPi NEO2をv6プラスのルーターにする 後編
- NanoPi NEO2をv6プラスのルーターにする 前編
- ELK Stackでシステム監視 FilebeatでNTP統計ログ取得 Logstashで加工
- NanoPi NEO2(arm64)用にFilebeatをビルド
- NanoPi NEO2を超コンパクトなアルミケースに入れる
- NanoPi NEO2用armbian 5.41 Debian 9 Stretch next 4.14.18
- NanoPi NEO2を100均の灰皿に入れてみた
- NanoPi NEO2のシステム監視 RPi-Monitorとnetdata
- NanoPi NEOとGPSモジュール用アルミケースを作る
- NanoPi NEO2 + DACで音楽プレーヤーVolumioを使う
- NanoPi NEO2にDACを接続
- NanoPi NEO2の最大クロック引き下げ後のUnixBench 再び
- NanoPi NEO2用armbian 5.32 Debian 9 Stretch 4.13.0-RC6
- NanoPi NEO2用armbian 5.32 Debian jessie 4.13.0-RC6
- NanoPi NEOをSIP電話機にする 後編 (その2)
- NanoPi NEO2とICカードリーダーでタイムレコーダーを作る(実用化編)
- NanoPi NEO2とICカードリーダーでタイムレコーダーを作る
NanoPiの記事とても参考になります。
NanoPiNeo(H3のほう)で高負荷の実験をしたのですが、1.2GHzだとヒートシンクがあるにもかかわらず、すぐに70度を超えてリミッターに当たるようで、クロックが下げられ、温度が下がるとまたクロックが上がり、電源の電流計でみていると数秒毎に消費電流がふらつく動作をします。
ヒートシンクにドライヤーで冷風を当てると40度くらいで安定して1.2GHz動作しました。
高負荷で動かすには小さいCPUクーラーが必要なようです。
今はNeo2(H5)のほうで実験中です。
ありがとうございます。
家では高負荷で動かすときは空気清浄機の吹き出し口の風がヒートシンクに当たるようにして冷やしてます。FriendlyELEC(FriendryARM)のヒートシンクはフィンがすごく小さくて見るからに冷却力が低そうですが、高負荷で動かすなら本当に冷却力が足りないのでまともなものを使う方が良さそうです。ヒートシンクだけでなく、SoCとヒートシンクの間に挟むシリコンスポンジの熱伝導パッド(放熱パッド)も高性能な熱伝導グリスやシートなどと比べると圧倒的に性能が低いので、それも使うのをやめて金属プレートのアダプタ+グリス+大型ヒートシンクが良さそうです。
でも、低負荷ならFriendlyELECのNEO用ヒートシンクでもダメじゃない。コンパクトなのが売りなんだし。