がとらぼ
INTAA.NET

NanoPi NEOでBitcoinのMining(採掘)

Bitcoin
©いらすとや.

記事を書いといてなんだけど、超強力専用ハードウエアを使ってさえ投資と日本の電気代を考えると採算が合わないのが今のBitcoinの採掘。当然NanoPi NEOごときでは広大な畑を耳かきで土をすくって耕そうとするようなもので、非効率すぎて利益になることは100%ない。2017年の今となっては(NanoPiを母艦にして)USBのASIC採掘機を使ってもそれは基本的に変わらない。Bitcoin以外の割の良い暗号通貨でもNanoPiで採掘は利益が出ることはない、というか利益を考えること自体ナンセンス。
とりあえずNanoPiでもやろうと思えばできなくはないよ程度。

まず、マイニング用のソフトウエアを用意する。今回はpooler's cpuminerを使うこととする。

素のarmbianではpooler's cpuminerのコンパイルに必要なものが幾つか足りないので入れておく。

# apt-get install libcurl4-openssl-dev
# apt-get install libjansson-dev
# apt-get install autogen

もちろん入れたいパッケージ名を並べてapt-get 1回でも構わない。
入手したpooler's cpuminerのディレクトリ(ZIPで入手したなら展開したディレクトリ内)で以下。

$ ./autogen.sh
$ ./configure CFLAGS="-O3"
$ make

ここまで最新版のビルド方法。(/usr/内にインストールするならmake installするなり)
NanoPi NEOのarmbianには幾つか前の記事にも書いたarmbianmonitorで何故かpooler's cpuminerをインストールできる。当然こちらの方が圧倒的に簡単。

# armbianmonitor -p

minerdが出来ている筈なので確認がてら使用方法を見る。

$ ./minerd --help 　←上のGitHubからの場合
$ minerd --help 　　←上のarmbianmonitorでインストールした場合
Usage: minerd [OPTIONS]
Options:
  -a, --algo=ALGO       specify the algorithm to use
                          scrypt    scrypt(1024, 1, 1) (default)
                          scrypt:N  scrypt(N, 1, 1)
                          sha256d   SHA-256d
  -o, --url=URL         URL of mining server
  -O, --userpass=U:P    username:password pair for mining server
  -u, --user=USERNAME   username for mining server
  -p, --pass=PASSWORD   password for mining server
      --cert=FILE       certificate for mining server using SSL
  -x, --proxy=[PROTOCOL://]HOST[:PORT]  connect through a proxy
  -t, --threads=N       number of miner threads (default: number of processors)
  -r, --retries=N       number of times to retry if a network call fails
                          (default: retry indefinitely)
  -R, --retry-pause=N   time to pause between retries, in seconds (default: 30)
  -T, --timeout=N       timeout for long polling, in seconds (default: none)
  -s, --scantime=N      upper bound on time spent scanning current work when
                          long polling is unavailable, in seconds (default: 5)
      --coinbase-addr=ADDR  payout address for solo mining
      --coinbase-sig=TEXT  data to insert in the coinbase when possible
      --no-longpoll     disable long polling support
      --no-getwork      disable getwork support
      --no-gbt          disable getblocktemplate support
      --no-stratum      disable X-Stratum support
      --no-redirect     ignore requests to change the URL of the mining server
  -q, --quiet           disable per-thread hashmeter output
  -D, --debug           enable debug output
  -P, --protocol-dump   verbose dump of protocol-level activities
  -S, --syslog          use system log for output messages
  -B, --background      run the miner in the background
      --benchmark       run in offline benchmark mode
  -c, --config=FILE     load a JSON-format configuration file
  -V, --version         display version information and exit
  -h, --help            display this help text and exit

マイニング実行

$ ./minerd --url=http://example.com:1234 --userpass=user:password

採掘用のプールとして例えばSlush Poolを使っているとするならURLはstratum+tcp://stratum.slushpool.com:3333。東アジア直指定ならstratum+tcp://sg.stratum.slushpool.com:3333 (シンガポール)。ユーザー名とワーカー名をピリオドで繋ぐ、それとパスワードをコロン「:」で繋ぐ。パスワードは何でも。他の採掘者になりすますバカはいないのでそれで良いかと。今回はBitcoinなのでアルゴリズムはsha256dを指定する。Litecoinなどはscryptだが、これはminerdの初期値なので指定無しで良い。(非力なCPUやGPUで採掘するならASICが力を発揮できないscryptで採掘する暗号通貨の方が良さげ。)

こんな感じ
$ ./minerd --algo=sha256d --url=stratum+tcp://sg.stratum.slushpool.com:3333 --userpass=username.worker1:anything

上の例ではフォアグラウンドで実行しているので逐次状況が表示される。

[2017-02-28 19:47:31] thread 0: 21110861 hashes, 351.63 khash/s
[2017-02-28 19:47:32] thread 2: 21161664 hashes, 352.48 khash/s
[2017-02-28 19:47:32] thread 3: 21123848 hashes, 352.21 khash/s
[2017-02-28 19:47:32] thread 1: 21115858 hashes, 352.07 khash/s
[2017-02-28 19:48:23] thread 0: 18122136 hashes, 351.00 khash/s
[2017-02-28 19:48:23] accepted: 1/1 (100.00%), 1408 khash/s (yay!!!)

しばらくというか数時間ほど様子を見て上のように(yay!!!)が表示されるなら正常。(booooo)ばかり表示されるなら何かがおかしいかも。
表示されているハッシュレートの数字の可愛らしいこと。ASICのAvalon6が3.5Thash/s (消費電力980W)、Avalon721が6Thash/s (同900W)ということらしいのでやはりASICとは桁桁桁違い。

なお、Slush PoolではcgminerとBFGminerだけをサポートしていてminerdは非サポートと明示している。ASIC以外はお呼びじゃないとのこと。pooler's cpuminerで上手くいかなくても文句は言えない。

Bitcoin採掘時
Bitcoin採掘時、CPU使用率は100%張り付き(紫線・左目盛り)、CPUクロックは最高値の1.2GHz(緑線・右目盛り)張り付きだが、ちょうど左目盛り100%と右目盛り1.2GHzが重なる高さにあるので緑線が紫線に隠れている。SoCの温度(水色線・左目盛り)は、前回までと同様に机の上に置いて風に当てない状態だと60℃まで上昇してオーバーヒート防止の為のクロックダウンが発生してしまうので空気清浄機から吹き出す風が僅かに当たる場所に置いたところ全力運転で30℃前後に抑えられている。
なお、グラフ左の方の23時台に2回縦線が発生しているところは短時間だがBitcoinの採掘を停止したのが反映されている。

関連記事:

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で見る

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を使ってるなら簡単かも。

関連記事:
Up