NanoPi NEOの時刻のズレを直したい

時計

5つ前のPPSの記事でやったようなことで普通のPCならPPSを時刻ソースとしてNTPサーバが一応正常に動く筈なんだけど、NanoPi NEOだと数分でNMEAとPPSの両方の同期が切れてしまう。
でも、ネットワーク上の他のNTPサーバとの同期は切れないんだよなぁ。そこが解せん。
何故かなと調べてたらRTCの時刻のズレ方がとんでもない凄さ。使用中なら20分で5分、アイドル状態放置でも8時間で45分ほどズレてしまう。RTCの時刻を表示する度にどんどんズレてくのでウワァって感じ。カーネルビルドのオプション指定間違えてるのだろうか?

# ppswatch -a /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
timestamp: 1490575231, sequence: 37551, offset:  1276715
timestamp: 1490575232, sequence: 37552, offset:  1279569

眺めているとoffsetの値が急激に増大または減少する。さらには増大してるかと思ったら突然減少に反転、或いはその反対ということも起こる。これはおかしい?
RTCを狂わせてる原因は何かしら?

$ lsmod
Module                  Size  Used by
cfg80211              192770  0 
bluetooth             263753  0 
rfkill                 10928  2 bluetooth,cfg80211
evdev                   9979  0 
sun8i_ths               3134  0 
gpio_keys               8517  0 
cpufreq_dt              3522  0 
uio_pdrv_genirq         3354  0 
uio                     8012  1 uio_pdrv_genirq
thermal_sys            43232  2 cpufreq_dt,sun8i_ths
pps_gpio                2897  1 
g_serial                3737  0 
libcomposite           34692  1 g_serial
fuse                   70718  1 

どう見てもcfg80211やbluetoothなど幾つかは要らない。
そこで /etc/modprobe.d/fbdev-blacklist.conf に追記

1
2
3
blacklist bluetooth
blacklist cfg80211
blacklist evdev
# systemctl list-unit-files
UNIT FILE                                  STATE
中略
bluetooth.service                          enabled
中略
dbus-org.freedesktop.nm-dispatcher.service enabled
中略
fake-hwclock.service                       enabled
後略

こいつらも停めてしまうことにする。

# systemctl stop bluetooth.service
# systemctl disable  bluetooth.service
# systemctl stop dbus.service
# systemctl disable dbus.service
# systemctl stop fake-hwclock.service
# systemctl disable fake-hwclock.service

さて、一番アヤシイのはCPUのクロックがコロコロ変わること。これを固定させたい。
まずは状態を確認。

$ 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: 4.24 ms.
  hardware limits: 120 MHz - 1.01 GHz
  available frequency steps: 120 MHz, 240 MHz, 312 MHz, 480 MHz, 624 MHz, 816 MHz, 1.01 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 816 MHz and 816 MHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 816 MHz (asserted by call to hardware).
  cpufreq stats: 120 MHz:0.00%, 240 MHz:0.00%, 312 MHz:0.00%, 480 MHz:0.01%, 624 MHz:0.00%, 816 MHz:97.42%, 1.01 GHz:2.58%  (2)

以下、CPUのコア数分の表示が行われる。

CPUのクロックは120 MHz, 240 MHz, 312 MHz, 480 MHz, 624 MHz, 816 MHz, 1.01 GHzが指定できると書かれているが、1.01GHzは数字を丸めたっぽい。

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
120000 240000 312000 480000 624000 816000 1008000

指定可能な最大のクロックは1008000だ。←指定するときはこの数字でないと弾かれる(というか指定可能などれか近いのになる)

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil

使用可能なガバナーは6つ、これはcpufreq-infoまたはcpufreq-info -gで表示されるものと同じ。

システム起動中の指定変更にはcpufreq-setを使うということになっているが、システム起動時用の設定ファイルとしては/etc/default/cpufrequtilsが用意されているようだ。

1
2
3
4
ENABLE=true
MIN_SPEED=0
MAX_SPEED=0
GOVERNOR=performance

システムを再起動してみる。

現在の設定を確認する。

# cpufreq-info -p
120000 1008000 performance

表示上は最低クロックが12000最大クロックが1008000となっているが、ガバナーが指定された最大値固定のperformanceなので1008000以外にはならない(ことになっている)。

暫く使った後に本当にクロックが固定されているか確認する。

# cpufreq-info -s
120000:0, 240000:0, 312000:0, 480000:0, 624000:0, 816000:0, 1008000:33629  (1)

1008000以外の使用が0ということなので固定されていると見てよさそう。クロックの後の数字の単位は不明。

1
2
3
4
ENABLE=true
MIN_SPEED=0
MAX_SPEED=816000
GOVERNOR=performance

最大速度を中間の値(816000)で指定してみた。

$ cpufreq-info -s
120000:0, 240000:0, 312000:0, 480000:2, 624000:0, 816000:14583, 1008000:439  (2)

816000以外で動かない筈だが、システム起動中の固定設定になる前に1008000で動いた時間があるようだ。480000にも2というのがあるがこれは無視して良さそう。
もちろん、performanceガバナーが有効になった後は816000以外では動かないはずなのでこの後にcpufreq-info -sで表示すると816000以外では数値は増えない(筈)。

同様にMIN_SPEEDを指定してpowersaveガバナーを使用するとMIN_SPEEDのクロックで固定される。MIN_SPEEDが0なら選択可能な一番低いクロックで固定。

ondemandとconservativeガバナーを選択した場合はクロックの切り替わりの挙動が異なるようだが、どちらも負荷に応じてMIN_SPEEDからMAX_SPEEDの間でクロック可変となる。MIN_SPEEDとMAX_SPEEDを0指定にしていれば選択可能な一番低いクロックから選択可能な一番高いクロックの間で可変。

で、NanoPi NEOのCPU(っていうかH3の)のカタログスペック上の最大値って1.2GHz (1200000)じゃなかったっけ?
以前の記事の古いカーネルでは1.2GHzまで使えたけどカーネル4.10系では2017年3月30日時点では1GHzまでらしい。
もっともクロック最大でブン回すと熱が出るのでこの手のSBCだと寧ろ使用する機能に影響しない範囲で如何に低いクロックを設定するかに苦心するところだろうけど。

さて、CPUクロックを固定してみたが、RTCのズレ具合は改善しただろうか?

全然ダメ

殆ど全くというレベルで改善していない。何だろうCPU動くたびに仕事量に応じてズレてるとしか思えない。

そういえばtimedatectlにRTCをNTPに同期させてくれる機能ってのが付いてたような。

$ timedatectl status
      Local time: Tue 2017-03-30 13:04:38 JST
  Universal time: Tue 2017-03-30 04:04:38 UTC
        RTC time: Tue 2017-03-30 04:04:38
       Time zone: Asia/Tokyo (JST, +0900)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a


# timedatectl set-ntp yes   ←RTCをNTPに同期させる


$ timedatectl status
      Local time: Tue 2017-03-30 13:04:58 JST
  Universal time: Tue 2017-03-30 04:04:58 UTC
        RTC time: Tue 2017-03-30 04:04:57
       Time zone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a

表示上はRTCの時刻のズレ方がメチャクチャというのは直った。でも、ぴったり合うというわけでもないみたい。
そして、相変わらずNTPのソースとしてのNMEAとPPSは同期してくれない、もしくは同期してもすぐに切れてそのまま。
やはり見かけじゃない部分でRTC自体がズレていて本来正しい方のNMEAとPPSの時刻を異常と思って同期を切ってると考えるのが正しいよねぇ。でも、他のNTPサーバとの同期は切れないのは何で?
こうなるとRTCモジュールを買ってみるしかない?でも負けたみたいで嫌だなぁ。
引き続き他の対策も考えたい。

関連記事:

NanoPi NEO2ベンチマーク

NanoPi NEO2 6
左が新しく届いたNanoPi NEO2、右側がNanoPi NEO(無印)

前の記事では開封しただけだったがNanoPi NEO無印と並べて比べてみた。意外なところで、ネットワークのコネクタの上下が反対になっていた。NEO2ではストッパーの爪が上向き。
また、microSDカードのスロットのコストを抑えたのかバネ式ではなくただの差し込み式に変わっている。一度深く差し込んで固定、もう一度深く差し込むと取り出せるバネ式は壊れやすくはあるけど振動には強い。NEO2のは壊れにくくても振動を与え続けるとmicroSDカード抜けちゃうという点、この手のシングルボードコンピュータ用としてはどうかなと思う。テープで貼って抜けないようにするか。

動かしてみた。

使用したOSはarmbianのサイトでイメージファイルが配布されていたUbuntu XenialのNightly releases。NanoPi NEO2用のレガシーカーネル版は3月30日時点では配布されているイメージファイルは存在しなかった。

$ uname -a
Linux nanopineo2 4.10.0-sun50iw2 #19 SMP Wed Mar 29 03:39:20 CEST 2017 aarch64 aarch64 aarch64 GNU/Linux
# cat /proc/cpuinfo
processor	: 0
Processor	: AArch64 Processor rev 4 (aarch64)
Hardware	: sun50iw1p1
BogoMIPS	: 48.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1
Processor	: AArch64 Processor rev 4 (aarch64)
Hardware	: sun50iw1p1
BogoMIPS	: 48.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 2
Processor	: AArch64 Processor rev 4 (aarch64)
Hardware	: sun50iw1p1
BogoMIPS	: 48.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 3
Processor	: AArch64 Processor rev 4 (aarch64)
Hardware	: sun50iw1p1
BogoMIPS	: 48.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

cpuinfoの内容はNanoPi NEO(無印)と比べてむしろまともになった。

本題でNanoPi NEO2のベンチマークを取ってみた。

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

   System: nanopineo2: GNU/Linux
   OS: GNU/Linux -- 4.10.0-sun50iw2 -- #19 SMP Wed Mar 29 03:39:20 CEST 2017
   Machine: aarch64 (aarch64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   05:29:42 up 23 min,  1 user,  load average: 0.15, 0.03, 0.01; runlevel 5

------------------------------------------------------------------------
Benchmark Run: Thu Mar 30 2017 05:29:42 - 05:58:22
0 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        4305348.7 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      757.2 MWIPS (10.0 s, 7 samples)
Execl Throughput                               1018.7 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        127571.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           39044.1 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        294973.7 KBps  (30.0 s, 2 samples)
Pipe Throughput                              343244.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  49034.8 lps   (10.0 s, 7 samples)
Process Creation                               2552.6 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1855.0 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    566.0 lpm   (60.1 s, 2 samples)
System Call Overhead                         652966.5 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    4305348.7    368.9
Double-Precision Whetstone                       55.0        757.2    137.7
Execl Throughput                                 43.0       1018.7    236.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     127571.1    322.1
File Copy 256 bufsize 500 maxblocks            1655.0      39044.1    235.9
File Copy 4096 bufsize 8000 maxblocks          5800.0     294973.7    508.6
Pipe Throughput                               12440.0     343244.7    275.9
Pipe-based Context Switching                   4000.0      49034.8    122.6
Process Creation                                126.0       2552.6    202.6
Shell Scripts (1 concurrent)                     42.4       1855.0    437.5
Shell Scripts (8 concurrent)                      6.0        566.0    943.3
System Call Overhead                          15000.0     652966.5    435.3
                                                                   ========
System Benchmarks Index Score                                         301.9

------------------------------------------------------------------------
Benchmark Run: Thu Mar 30 2017 05:58:22 - 06:27:24
0 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       17213507.3 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     3027.8 MWIPS (10.0 s, 7 samples)
Execl Throughput                               2493.6 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        211654.8 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           60859.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        578036.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1363863.5 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 185178.3 lps   (10.0 s, 7 samples)
Process Creation                               6086.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4448.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    577.2 lpm   (60.3 s, 2 samples)
System Call Overhead                        2485418.6 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   17213507.3   1475.0
Double-Precision Whetstone                       55.0       3027.8    550.5
Execl Throughput                                 43.0       2493.6    579.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     211654.8    534.5
File Copy 256 bufsize 500 maxblocks            1655.0      60859.5    367.7
File Copy 4096 bufsize 8000 maxblocks          5800.0     578036.5    996.6
Pipe Throughput                               12440.0    1363863.5   1096.4
Pipe-based Context Switching                   4000.0     185178.3    462.9
Process Creation                                126.0       6086.3    483.0
Shell Scripts (1 concurrent)                     42.4       4448.5   1049.2
Shell Scripts (8 concurrent)                      6.0        577.2    962.0
System Call Overhead                          15000.0    2485418.6   1656.9
                                                                   ========
System Benchmarks Index Score                                         761.2

今回の計測時のCPUクロックがちょっとわからない。/sys/devices/systemの下にそれらしきものが無いんだけど何処で情報を得ることができるんだろ。
クロック表示以外もNightly releasesということもあるのか、そもそもNanoPi NEO2への適応が足りないのかあちこち不完全さが目立つ。
取り敢えず、今回は情報不足ではあるけどご了承の程を。

NanoPi NEOベンチマークではCPUクロックが912MHz(初期値)で計測してインデックススコアがシングル164.1、4パラレルが429.0だった。
それと比べるとスコア的にはNEO2はシングルで183%、同じく4パラレルで177%ということになる。
実際、NEO無印と比べるとNEO2は体感できるほど反応が速いというか軽いからスコアの差は嘘ではないと思う。
見た目はほぼ同じだけどまるで別物。まぁ、実際SoCがピン互換ってだけで別物なんだけど。

あの白いので例えるとMkIIくらいを期待してたらZを飛び越してZZが来ちゃったくらい。(実はよく知らない)

関連記事:

Up