がとらぼ
INTAA.NET

NanoPi NEO2 最大クロック引き下げ後のUnixBench

NanoPi NEO2

数日前にarmbianは(SoCが) H5の機種向けにDRAMのクロック速度を672MHzから624MHzに約7%引き下げる設定ファイルが入った。それとは別にCPUの最大クロックも1008MHzから912MHzに約10%ほど引き下げる設定ファイルも入っている。OSが起動しないことがあるのでその対処らしい(間違ってたらｽﾏﾝｽ)が結構大胆に引き下げてくれるもんだなぁ。

この記事はNanoPi NEO2用に書いてるけどクロック引き下げの対象はNanoPi NEO2だけでなくOrangePi PC 2やOrangePi Prime、OrangePi Zero Plus 2、NanoPi M1 Plus2らしいけど、未販売の機種も入ってるので販売中で実際に影響を受けるのはNanoPi NEO2 と OrangePi PC 2くらい？

早速armbianの最新版をビルドしてUnixBenchで測ってみた。

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

   System: nanopineo2: GNU/Linux
   OS: GNU/Linux -- 4.10.0-gatolabo-sun50iw2 -- #3 SMP Sat Apr 29 12:24:39 JST 2017
   Machine: aarch64 (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   14:31:43 up 26 min,  1 user,  load average: 0.15, 0.03, 0.01; runlevel 5

------------------------------------------------------------------------
Benchmark Run: Sat Apr 29 2017 14:31:43 - 15:00:07
0 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        4285257.4 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      488.6 MWIPS (10.0 s, 7 samples)
Execl Throughput                               1095.6 lps   (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        128956.2 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           39086.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        299577.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              357585.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  58523.9 lps   (10.0 s, 7 samples)
Process Creation                               2808.7 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1751.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    554.7 lpm   (60.1 s, 2 samples)
System Call Overhead                         644220.7 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    4285257.4    367.2
Double-Precision Whetstone                       55.0        488.6     88.8
Execl Throughput                                 43.0       1095.6    254.8
File Copy 1024 bufsize 2000 maxblocks          3960.0     128956.2    325.6
File Copy 256 bufsize 500 maxblocks            1655.0      39086.5    236.2
File Copy 4096 bufsize 8000 maxblocks          5800.0     299577.0    516.5
Pipe Throughput                               12440.0     357585.9    287.4
Pipe-based Context Switching                   4000.0      58523.9    146.3
Process Creation                                126.0       2808.7    222.9
Shell Scripts (1 concurrent)                     42.4       1751.3    413.0
Shell Scripts (8 concurrent)                      6.0        554.7    924.6
System Call Overhead                          15000.0     644220.7    429.5
                                                                   ========
System Benchmarks Index Score                                         298.9

------------------------------------------------------------------------
Benchmark Run: Sat Apr 29 2017 15:00:07 - 15:28:37
0 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       17136928.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1952.3 MWIPS (10.0 s, 7 samples)
Execl Throughput                               2712.4 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        214728.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           62979.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        594746.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1425779.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 256029.3 lps   (10.0 s, 7 samples)
Process Creation                               6800.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4473.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    573.9 lpm   (60.2 s, 2 samples)
System Call Overhead                        2386890.0 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   17136928.1   1468.5
Double-Precision Whetstone                       55.0       1952.3    355.0
Execl Throughput                                 43.0       2712.4    630.8
File Copy 1024 bufsize 2000 maxblocks          3960.0     214728.3    542.2
File Copy 256 bufsize 500 maxblocks            1655.0      62979.3    380.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     594746.0   1025.4
Pipe Throughput                               12440.0    1425779.2   1146.1
Pipe-based Context Switching                   4000.0     256029.3    640.1
Process Creation                                126.0       6800.9    539.8
Shell Scripts (1 concurrent)                     42.4       4473.5   1055.1
Shell Scripts (8 concurrent)                      6.0        573.9    956.6
System Call Overhead                          15000.0    2386890.0   1591.3
                                                                   ========
System Benchmarks Index Score                                         771.2

インデックススコアだけ比較してみるとシングルはクロック引き下げ前の前回が301.9、今回が298.9なので1%減少。
4パラレルでは前回が761.2で今回が771.2で(何故か)1%増加。
1%じゃ誤差の範囲なんだけど、10%の引き下げどこ行った？

ところで、未だにNanoPi NEO2用のarmbianではCPUクロックが幾つで動作しているのか知る方法が無い。
つまり、これまでも1008MHz(1.0GHz)で動いていたかもわからないし、現在も912MHzで動いているか不明。クロック固定なのか動的なのかもわからない(たぶん固定だろうけど)。
当然、NanoPi NEO(無印)でCPUクロックを変更する記事のようなことは全て行えない。

今のところ、この機種用のarmbianはこのCPU/DRAMクロック周りが全然整っていないことが最大の問題だよねぇ。

関連記事:

Windows 管理者権限でコマンド実行

コマンドプロンプト 1

Windows10のCreators Updateで以前と変わったと感じる部分は人それぞれだろうが個人的にとまどってるのは、従来スタートボタンを右クリックしたら表示されていた「コマンドプロンプト」が無くなって、代わりにPowerShellになったこと。
ここ数年でWindowsを使い始めた人にとっては「コマンドプロンプト何それ美味しいの？」とか「クソ使い勝手の悪い化石ﾌﾟｷﾞｬｰw」くらいなものかもしれないが、DOS時代から使ってたオッサンとしては突然「これからはモッダーンなPowerShellをお使いくださいませ」と言われても正直困る。
感覚としては、日本で右ハンドルの車しか運転したことが無いのに、いきなり道路標識とか交通法規全く知らないアメリカで左ハンドルのクルマに乗せられてじゃあ運転してねって言われてるような感じ。

更に正直に書くとバッチというかスクリプトで何かしたいときは実はPowerShellの方がいいなとは思い始めてるけど・・・

コマンドプロンプトはスタートメニューから消えただけで廃止されたわけではないのでショートカット作るだけ。

2017年7月15日追記: 「コマンド プロンプト」は最近は[スタートボタン]左クリック⇢[Windows システムツール]の下に居るみたい

  • C:Windows\system32\cmd.exe 32ビット版
  • C:Windows\SysWOW64\cmd.exe 64ビット版

基本的にはcmd.exeを実行すればコマンドプロンプトが起動する。

簡単に起動したいならcmd.exeのショートカットを作成してデスクトップなりスタートメニューなりに置けばいい。
ショートカットを右クリックして「管理者として実行」を選んで実行する、またはショートカットのプロパティを開いて「ショートカット」タブを選択し「詳細設定」ボタンを押して「管理者として実行」にチェックを付けておけばショートカットから起動すると管理者権限のコマンドプロンプトが開く。普通のショートカットと管理者権限のショートカットの両方を用意すればCreators Update前にスタートボタン右クリックで表示された「コマンド プロンプト」と「コマンド プロンプト(管理者)」と同様になる。

また、PowerShellを起動してcmdを実行すれば紺画面だけどコマンドプロンプトになる。PowerShell(管理者)を起動してcmdを実行すれば管理者権限のコマンドプロンプトになる。
コマンドプロンプトから抜けてPowerShellに戻る時はexit。ここらへんは普通。

以上。

じゃなくて、オッサンは足掻く。
ここからはCreators Updateは関係ない。Windowsでコマンドを打って管理者権限で実行させる方法について。

コマンドプロンプトを使うにあたり、不便だなと思うのが、管理者権限でちょっと何かしたいってときにコマンドラインからLinuxでよく使われるような「sudo ホニャララ」みたいな、そのときだけ1回限りで管理者権限でコマンド実行する機能がないこと。
UNIX系OSで従来から使われている「su ユーザー名」や「su -」でシェルを他のユーザーや管理者に切り替えて使えるようなのは一応runasが備わってるのでできなくもないんだけど、Windowsの管理者IDであるadministratorがWindows Vista以降では標準で無効化されてるので事実上使い物にならない。困ったOSだわね。

runasで管理者に切り替える (Windows10 Home不可)

まず、administratorユーザーを無効から有効に変える。

コマンドプロンプト 2
[Win]+[R]キーを押して lusrmgr.msc と入力して[OK]

コマンドプロンプト 3
Windows10 Homeエディションだとローカルユーザーとグループ管理ツールは使えない。本当にHomeはとことん何もできないゴミ。

コマンドプロンプト 4
Proエディション以上なら使える。
「ユーザー」をクリック。

コマンドプロンプト 5
中央のユーザーリストからAdministratorをダブルクリック。

コマンドプロンプト 6
「アカウントを無効にする」にチェックが入っているので外す。[OK]を押す。

コマンドプロンプト 7
ユーザーリストからAdministratorを右クリック。
「パスワードの設定」をクリック。

コマンドプロンプト 8
脅かしのポップアップが出るけど無視して[続行]。

コマンドプロンプト 9
administrator用の新しいパスワードを2回入力する。[OK]を押す。

これでAdministratorユーザーが利用可能になった。

コマンドプロンプト 10
[Win]+[R]キーを押して runas /user:administrator cmd と入力して[OK]。
runasはシステムフォルダにあるrunas.exeの拡張子省略形。
cmdの部分は実行したいコマンド。今回はコマンドプロンプトを実行したいのでcmd.exeの拡張子省略形でcmd。

コマンドプロンプト 11
懐かしい黒画面のコマンドプロンプトが表示される。
なお、administratorという別ユーザーとして実行したのでadministratorのパスワードの入力が求められる。

パスワード認証が通れば後は普通に管理者権限のコマンドラインとして利用できる。

ただし、この方法は何でadministratorが標準で無効になったかというのを無視したものなのでたぶんオススメできないものかと。

PowerShellから管理者権限でコマンド実行 (Windows10 Home可)

PowerShell内から

Start-Process -Verb runas 実行したいコマンドorアプリファイル名

Powershell外から

powershell -command "Start-Process -Verb runas 実行したいコマンドorアプリファイル名"

つまり

コマンドプロンプト 12
[Win]+[R]キーを押して powershell -command "Start-Process -Verb runas 実行したいコマンドorアプリファイル名"

コマンドプロンプト 13
上の画像のようにcmd.exeを管理者権として実行した場合は一瞬PowerShellが開いた後に黒画面の従来のコマンドプロンプトが開く。
左上に「管理者: C:Windows\system32\cmd.exe」と表示されているので管理者として開いているのがわかる。

Windows用sudo

で、結局のところコマンド入力で「管理者として〜を実行」というのはちょっと面倒。もっと簡単にできんのかい？って思ったらみむらの手記手帳というページを見つけた。

テキストエディタで新しいテキストファイルに下の1行を書く。ファイル名をsudo.cmdとして保存する。(この時点では任意のフォルダ) 
@powershell -command "Start-Process -Verb runas %1"

c:\windows\system32の下にでも放り込む。

sudo 実行したいコマンド/アプリファイル名

Linuxなどで慣れ親しんだ形で管理者権限でコマンド実行可能になる。
先のリンクのページ読んでようやく「おーっ、その手があったか」っていうか、何故上でStart-Process -Verb runas hoge ってやってる時点で思い至らなかった？

そもそもMicrosoftが何で用意しないのか？
だから、「山田くん、Microsoftのざぶとん全部取ってsudo.cmdのスクリプト作った人に2枚差し上げて」って気分。

関連記事:
Up