蛍光灯焦げる、そして毒ガス

脱衣室兼洗面所で服を脱いで隣りにある風呂に入っていたら、風呂の扉越しに洗面所の鏡のランプがピカピカ数回点滅したかと思ったら突然少し暗くなった。そして、1分もせずに、風呂の扉を締めているにも関わらず何かが焼け焦げた臭いともう一つ別種類のなんともいえないイヤな臭い。風呂から出るために扉を開けるとさらに強烈に臭う。洗面所の鏡のランプが2つある内の1つが切れていた。密閉の照明ケースでなくてカバーが帯のようになって上下が開放の照明なのでどんなランプが使われているのかは下から丸見えのもの。スパイラル蛍光灯のようだったので寿命は長くはないだろうし球切れにはなるのは仕方がない。しかし、今回の切れ方はちょっと違った。普通は蛍光灯が切れたからといって臭いはしないよね。

芳しい蛍光灯の断末魔 1
ブランドはNEC。12Wの電球型蛍光灯で、管を巻いたスパイラルタイプ。一時期流行って各社出してた記憶はある。基本的にはもう生産中止の筈。

芳しい蛍光灯の断末魔 2
お約束のメイドインチャイナ。調光器付きの器具では使用するなと書かれているが、もちろん洗面所の鏡のところの照明は調光機能付きのものではなくこのEFD15ENを使用するように指定書きが付いたもの。

芳しい蛍光灯の断末魔 3
ベース部分の管が出るところの周辺がメッチャ焦げてる。まぁこのタイプでは多いみたいね。

芳しい蛍光灯の断末魔 4
画面中央。蛍光管に穴が開いてる。どういう風に穴が開いたのかは全く不明だが、焦げ臭さとは違う部屋に充満するイヤな臭いはここから漏れ出たガスらしい。蛍光管のガスには水銀が含まれてて、それは昔と比べて使用量が減ってはいるらしいが、ゼロではない筈。臭いが部屋に充満してた風呂にも流れ込んできたということは水銀も一緒に吸った?

風呂入ってたらガス責めってナチスの収容所じゃないんだから勘弁して欲しい。
LEDにもトラブルはあるとはいえ取って代わられるわな、これじゃ。

蛍光灯というと正直あまり良い思い出がない。
学生時代にナショナルブランドの3本か4本の短いガラス管が筏みたいに並んだタイプで眼が疲れないインバーター付き2段調光っていう当時としてはお高めだった電気スタンドをちょっと奮発して買ったら普通の蛍光灯よりはるかに激しくチカチカしまくってフザケンナって思った。これが最初で最後に買ったナショナル製品になった。

次が、東芝ダイナブックのバックライト。最近はLEDだけどCCFLの頃のやつ。一時期のダイナブックでは冷陰極管自体が切れるのではなくFLインバーターが設計ミスなのかやたらと壊れまくった。バックライトが切れる度に秋葉原のチチブデンキに行って店のおっちゃんに相談して交換用のFLインバーターを購入して自分で取り替えた。FLインバーターは糞高いものではないし作業も難しくはないけどそれでも数が多いのでやっぱりフザケンナって思った。

3つめ、オフィスの掃除で簡易的なハタキのようなものを作ってテキトーにパタパタやってたら間違って天井の蛍光管にコツンと当たった。そしたらパンッってなって上から細かいのが降り注いだ。フザケンナ自分って思った。

アッチッチなNanoPi NEO3を冷やしたい

先日から我が家のIPv4専用ルーターになったNanoPi NEO3だが、既に書いたようにとっても熱い。CPUが忙しいときに熱くなるのはまぁ理解できるとしてアイドル時もクロックが下がらずむしろ上限に上がるくらいで、NanoPi NEO3のケースに風を当てても80〜90℃程度。夏場で室温が高いこともあるせいもあるかもしれないけどだいぶ高い。仕方がないので最大1.5GHzで動ける(Armbian)ところを1GHzに落として使っている。それで60〜70℃程度。 アルミケースに入れてケース放熱させているNanoPi NEO, NanoPi NEO2は同じ室温で40℃程度。そこまで贅沢は言わないので現状から10℃程度は落として50℃程度にしたい。

NanoPi NEO3の冷却力を高める 1
手持ちの材料が右側のPC用CPU冷却ファン付きヒートシンク。これはおそらく何かのAMDのCPUを購入したときに付属したヒートシンク+冷却ファンで使わなかったやつ。PCのCPU用としてはファンもヒートシンクも小さめなので冷えなさそうと思って別のを使ったのかと。中央の「税込390」と書かれたのはサーマルグリス。これはおそらく購入して10年くらい?放置してたやつ。左側が20 x 20mmの銅パッド厚さはこれは0.5mm。たしか2mmまで数種類ほど購入してたと思ったがどうしても見つからなかった。意外とよく使うのでもしかしたら使った後に買い足し忘れてる可能性はある。グリスと銅パッドの下にあるのは放熱用のシリコンパッド。これは1mm厚。今回は銅パッドとグリスを使うつもりだけど、どうしても収まりが悪いときには使うかも程度。

NanoPi NEO3の冷却力を高める 2
ヒートシンクの裏側にカバーが付いていてヒートシンク中央に最初から塗ってあるグリスが全くそのままなので新品らしい。ただし、なんか丸い穴が空いてる箱に入っていたので冷却ファンとヒートシンクのフィンの付いた側はホコリだらけだった。

NanoPi NEO3の冷却力を高める 3
今回はPC用の冷却ファンは使わないので4隅のネジを外して冷却ファンには再び永い眠りについて貰う。NanoPi NEO3には冷却ファン用のコネクタが付いているが2ピンなのでこの4ピン冷却ファンには合わないのよね。

NanoPi NEO3の冷却力を高める 4
中のグリスは新品。ただし、いつからあったかわからないものなので劣化はあるかも。仮に新しいものでもこの最初から塗ってあるグリスって使わないよね。

NanoPi NEO3の冷却力を高める 5
ウェットティッシュなどでグイっとしてやれば大部分は簡単に落とせる。ヒートシンクのヘアラインに入り込んでるのは落とせないかも。だからこの画像でも落としきれていないのがうっすら見えている。これは気にしない。

NanoPi NEO3の冷却力を高める 6
NanoPi NEO3のケースは届いたばかりのときには開け方(ツメの位置)が判らないということで開けるのを諦めたが、Twitterで開けた写真を上げてくれてた人がいたので参考にさせて貰った。上の画像の辺りから紙のカードを差し込む。テレホンカードの類だと素材としては少し硬すぎてケース側を傷めるかも。あまりガッチリしたツメではないようなので写真くらいの深さに挿してグルっと1周通せばケースにキズ付けずに綺麗に外れる。

NanoPi NEO3の冷却力を高める 7
角を上手く通すのがコツ。紙カードだと適度に柔らかいので上手く通る。

NanoPi NEO3の冷却力を高める 8
ケースの上下がツメで固定されているだけで中身はネジなどで固定されてはいないのでケースを開けばそのまま基板が抜けてくる。落とさないよう注意した方が良いくらい。右側に見えているケース半分の内側の斜めの長方形っぽい部分に小型の基板が留められそうな感じなので、そういうオプション基板が出る(出てる)のかしら?

NanoPi NEO3の冷却力を高める 9
ヒートシンクはFriendlyElecのWikiの写真で見て知ってたけどSoCの発熱に対してあまりにも小さすぎるんじゃないかしら。このヒートシンクは小さいネジ2本で基板に留められているだけなので簡単に外せる。

NanoPi NEO3の冷却力を高める 10
ヒートシンクの裏側はいつものシリコン熱伝導パッド。爆熱SoCに使用するには厚手すぎるよねぇ。
SoCとシリコンパッドが接する部分は何か液体が塗ってあった。固着防止のためかしら。上の写真でもSoCの右下の方が少し濡れているように見えるのがそれ。

NanoPi NEO3の冷却力を高める 11
2cm x 2cmの銅パッドをSoCにグリスで引っ付ける。SoCは2cm x 2cmより小さいが、SoCの周りは結構広く空いているので問題なし。今回は2mm厚の銅パッドが見当たらなかったので熱伝導的には良くないだろうが0.5mm厚の銅パッドをサーマルグリスで合わせて4枚重ねる。サーマルグリスはできれば薄めに塗ってしっかり押し付けて漏れ出たグリスを拭う。ただし、すぐに剥がれるようだとパッドに歪みがあってパッドとパッドが密着できないのかも。そういう場合は諦めてグリスを中心に多めに塗って中央から押し付ける。はみ出たら拭う。上の写真は銅パッドとヒートシンクのくっつきが付きが悪かったので塗り直しで中央に多め。しっかり押し付けて端までグリスを行き渡らせる感じ。
これで真横から見たら銅パッドがわずかにケースの縁より高い状態。ケースの縁より銅パッドが低いとヒートシンクと銅パッドが接しないのでNG。

NanoPi NEO3の冷却力を高める 12
PCのCPU用のヒートシンクにはCPUソケットに固定するための金具が付いている。金具にはCPUソケットの両サイドに飛び出た凸にひっかけるための穴が空いているのでその穴を利用してタイバンド(結束バンド)のヘッド部分を引っ掛ける。NanoPi NEO3の上を通して反対側の金具の穴に通す。

NanoPi NEO3の冷却力を高める 13
もう1本タイバンドを用意して、ヘッド部から1cmで切断。そのヘッド部分だけの方で反対側から伸ばしたタイバンドを受ける。テンションがかかるまでギチギチと締めて余りは切断。これで簡単にすっきり固定できる。ただし、タイバンド剥き出しなので見た目は悪い。

NanoPi NEO3の冷却力を高める 14
反対側もこんな感じでmicroSDカードの出し入れも問題なし。

タイバンドは消耗品なので置いといて、それ以外は削ったり穴を開けたり破壊したりは一切していないので元に戻すのも簡単。簡易な方法なので誰でもできると思う。見た目がアレなので真似したいと思うかという問題はあるけど。

NanoPi NEO3の冷却力を高める 15
このグラフは48時間のNanoPi NEO3のSoC温度推移。
グラフの右の方で途切れたところがケースを弄る作業で計測していなかったところ。その右側のグラフが冷却力を高めた状態での計測になる。SoCのクロックは1.008GHzのまま変更していない。10℃ちょっと下がっているといえる。なお、ケースを弄る前はNanoPi NEO3に風を当てていたが、ケースを弄った後は風を当てない自然冷却状態。わずかに自然な空気の対流はあるかも。ヒートシンクにUSB給電タイプの冷却ファンを付けるともう少し下がるかもしれない。その状態でクロック1.5GHzで50℃くらいまで下がって欲しいところ。(後日試して追記したい。)

0.5mm厚の銅パッド4枚重ねというのはあんまり気分が良くないのでできたら2mm厚の1枚に交換したい。ただ、この手の小型パッドは厚みが増すほど販売されてるのが見つからないのね。特に1.5mm厚以上が少ない。自分のために2mm厚有りの商品リンクを置いておく。1ロットの枚数が多すぎると思ったらそのページの下方にある関連商品から探すと適当なのが見つかるかも。

関連記事:

NTPサーバの時刻ソースに対するズレの調整

最近Chronyを使ったNTPサーバ動かしてみたが、Chronyは設定と統計情報の出力がntpdとはちょっと違う。しかも内容がよくわからない。
一応、統計情報をNode Exporterに読ませてPrometheusに送るところまではできるのだけど、その送った情報が何の値を示しているのかが判らないのでそれをグラフにしてもまぁ判らないのね。つまり、Chronyは動かすまでは簡単だけど動かしてからがだいぶ困る。

/etc/chrony.conf (の統計情報出力部分)
1
2
logdir /var/log/chrony
log measurements statistics tracking refclocks
統計ログとして4種類出力する指定。
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#!/bin/sh

refclocklog="/var/log/chrony/refclocks.log"
measurelog="/var/log/chrony/measurements.log"
name="node_ntp_peerstats"
outdir="/tmp/node-exporter/"

offset1="# HELP node_ntpstats_offset_seconds Time offset in between local system and reference clock."
offset2="# TYPE node_ntpstats_offset_seconds gauge"
delay1="# HELP node_ntpstats_delay_seconds Time delay in between local system and reference clock."
delay2="# TYPE node_ntpstats_delay_seconds gauge"
disps1="# HELP node_ntpstats_dispersion_seconds Time dispersion in between local system and reference clock."
disps2="# TYPE node_ntpstats_dispersion_seconds gauge"
skew1="# HELP node_ntpstats_skew_seconds Time skew in between local system and reference clock."
skew2="# TYPE node_ntpstats_skew_seconds gauge"

pps='PPS'  #リファレンスドライバのrefidで指定した識別名
ppsdata=`/bin/cat ${refclocklog} | /bin/grep ${pps} | /usr/bin/tail -1`
ppsoffset=`echo ${ppsdata} | sed -e 's/ \+/ /g' | cut -d " " -f 7` 
ppsdelay=`echo ${ppsdata} | sed -e 's/ \+/ /g' | cut -d " " -f 8`
ppsdisps=`echo ${ppsdata} | sed -e 's/ \+/ /g' | cut -d " " -f 9`
#ppsskew=`echo ${ppsdata} | sed -e 's/ \+/ /g' | cut -d " " -f 8`
ppsl1="node_ntpstats_offset_seconds{device=\"pps\"} ${ppsoffset}"
ppsl2="node_ntpstats_delay_seconds{device=\"pps\"} ${ppsdelay}"
ppsl3="node_ntpstats_dispersion_seconds{device=\"pps\"} ${ppsdisps}"
#ppsl4="node_ntpstats_skew_seconds{device=\"pps\"} ${ppsskew}"

nmea='NMEA'  #リファレンスドライバのrefidで指定した識別名
nmeadata=`/bin/cat ${refclocklog} | /bin/grep ${nmea} | /usr/bin/tail -1`
nmeaoffset=`echo ${nmeadata} | sed -e 's/ \+/ /g' | cut -d " " -f 7`
nmeadelay=`echo ${nmeadata} | sed -e 's/ \+/ /g' | cut -d " " -f 8`
nmeadisps=`echo ${nmeadata} | sed -e 's/ \+/ /g' | cut -d " " -f 9`
#nmeaskew=`echo ${nmeadata} | sed -e 's/ \+/ /g' | cut -d " " -f 8`
nmeal1="node_ntpstats_offset_seconds{device=\"nmea\"} ${nmeaoffset}"
nmeal2="node_ntpstats_delay_seconds{device=\"nmea\"} ${nmeadelay}"
nmeal3="node_ntpstats_dispersion_seconds{device=\"nmea\"} ${nmeadisps}"
#nmeal4="node_ntpstats_skew_seconds{device=\"nmea\"} ${nmeaskew}"	

echo "${offset1}\n${offset2}\n${ppsl1}\n${nmeal1}\n${srv1l1}\n${srv2l1}\n${srv3l1}\n${delay1}\n${delay2}\n${ppsl2}\n${nmeal2}\n${srv1l2}\n${srv2l2}\n${srv3l2}\n${disps1}\n${disps2}\n${ppsl3}\n${nmeal3}\n${srv1l3}\n${srv2l3}\n${srv3l3}\n${skew1}\n${skew2}" > ${outdir}${name}.prom.$$

/bin/mv ${outdir}${name}.prom.$$ ${outdir}${name}.prom
/bin/chmod 666 ${outdir}${name}.prom

原始的だがこんな感じで統計情報をNode Exporterで読める情報にする。ただし、このスクリプトではoffsetだのdelayだのskewだのを○○ログの○番目の要素として抜き出す具体例が書かれているが、実際には○○ログの○番目の要素が何を示しているのか「がとらぼ」の人がよく判ってなくて作ったのでこれをそのまま真似るのはダメ。

一応頑張ってみたが、結局のところアタマが悪いのでドキュメントを見てもChronyのそれぞれのログの値が実際に何を示しているのか判らな過ぎてChronyを諦めてntpdに戻した。

「え? えぇっっっっ?!」

スンマセン

ntpdで統計情報をNode Exporterに渡すのは以前にPrometheus2とGrafana6によるシステム監視 NTP統計情報の表示で書いた。統計情報をグラフ化できないと調整は難しいと思うので、PrometheusとかElastic Searchとかの統計情報を収集する仕組みが無いという場合は、ntpdが出力する統計情報ファイルをNTP plotterに読ませてグラフ化するというようなのでも良い。Windowsならこれが簡単。何にしても、ntpdで時刻の調整をするには相当な時間〜日数で誤差を録り続けないとどれだけズレてるのかがそもそも判らない。

「がとらぼ」の人の調整の考え方

基本的にはPPSが秒替わりの間隔は一番正確。ただし、PPSはそのタイミングしか判らなくて、しかも微妙に遅延してるかも。
NMEAは秒の変わるタイミイグはだいぶデタラメだけど何時何分何秒が判る。
PPSとNMEAは衛星からのデータをGPSモジュールで受信してPCに伝えるまでの遅延がそれぞれどの程度あるのかが判らない。
インターネット上の公開NTPサーバの中には正確な時間を持っているものがあってそれをNTPサーバで参照すると個々の瞬間ではバラツキはあるけど長い時間では遅延を考慮した正しい時間を取得できる。
そこで、ネットから取得した時間とPPS/NMEAの差分を求めてPPS/NMEA側を調整する。つまり時刻自体はインターネット上のNTPサーバから取得した時刻に合わせて、秒のタイミングはインターネット上のNTPサーバに寄せてPPSの遅延(ズレ)を調整し、おまけでPPSに寄せてNMEAを調整するという感じ。PPSとネットの時刻ソースがあればNMEAは無くても良いが、ネットが切れた場合に備えてオマケで組み入れておく。

ntpdでは1つのリファレンスクロックドライバでNMEAとPPSをを組み合わせて日時+秒変わりタイミングを得る方法もあってそれが正確で良いとも聞くが、「がとらぼ」では172.172.20.xでNMEA、172.172.22.xでPPSの2つのリファレンスクロックドライバを使う方法を採用している。(GPSモジュールは1つ)

ntpdの設定で統計ファイルを出力する設定にしていないのであれば、ntpq -p の出力を監視という方法もある下のコマンドはLinux用)
#目視で監視するなら(まぁ無駄)
$ watch -n0.5 "ntpq -p | grep .NMEA."
#ファイルに出力するなら
$ watch -n0.5 "ntpq -pn | grep .NMEA. | tee --append nmea.log"

-n0.5は0.5秒毎に更新の指定。ntpq -pの出力を見るなら1秒よりは小さい方が数値がどう変化するのかよく判る。.NMEA.の部分は/etc/ntp.confのrefidで指定した文字列(上の例ではNMEA)の前後にピリオドを付けたもの。refidで指定した文字列がユニークなものなら前後のピリオドはなくても間違って抽出されることはないと思う。

GPSモジュール交換前
怪しい中華GPSモジュール(ATGM332D)を購入したという記事を書いたときに挙げた何かおかしいGPSモジュール(NEO 6M)のNMEAのグラフ。これがどう見ても異常なので新しいGPSモジュールを購入した。
それでOSも最新版で気分一新してこの記事に挑んでいる。そこで以前の「NanoPi NEOとGPSモジュールでNTPサーバ PPS解決編」では「効果が無い」と書いたsetserialにも再挑戦。

$ sudo apt install setserial    #setserialインストール

$ sudo setserial -g -a /dev/ttyS1    #setserial未適用で/dev/ttyS1の状態を確認
/dev/ttyS1, Line 1, UART: undefined, Port: 0x0000, IRQ: 38
        Baud_base: 1500000, close_delay: 50, divisor: 0
        closing_wait: 3000
        Flags: spd_normal

$ dmesg | grep serial   #システムがシリアルポートをどう認識しているか確認
[    2.472691] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 37, base_baud = 1500000) is a U6_16550A
[    2.494480] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 38, base_baud = 1500000) is a U6_16550A

/var/lib/setserial/autoserial.conf (編集 or 新規)
中身無しまたはコメントの行だけにする。

低遅延と速度115200bpsを指定(手動の場合)
$ sudo setserial /dev/ttyS1 low_latency spd_vhi
/dev/ttyS1が対象のシリアルポート、low_latencyが低遅延、spd_vhiが115200bpsの指定。
/lib/systemd/system/ntp.service (編集)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Unit]
Description=Network Time Service
Documentation=man:ntpd(8)
After=network.target
#After=rc-local.service
Conflicts=systemd-timesyncd.service

[Service]
Type=forking
# Debian uses a shell wrapper to process /etc/default/ntp
# and select DHCP-provided NTP servers if available
ExecStart=/usr/lib/ntp/ntp-systemd-wrapper
ExecStartPre=/usr/bin/bash -c '/usr/bin/mkdir -p /tmp/ntpstats 2> /dev/null'
ExecStartPre=/usr/bin/chmod 777 /tmp/ntpstats
ExecStartPre=/usr/bin/bash -c '/usr/bin/echo "B5 62 06 00 14 00 01 00 00 00 D0 08 00 00 00 C2 01 00 07 00 03 00 00 00 00 00 C0 7E" | xxd -r -p > /dev/ttyS1'
ExecStartPre=/usr/bin/setserial /dev/ttyS1 low_latency spd_vhi
ExecStartPre=/usr/sbin/ntpdate ntp1.v6.mfeed.ad.jp
ExecStartPre=/usr/sbin/hwclock -w
#PrivateTmp=true

[Install]
WantedBy=multi-user.target

15行目でubloxのGPSモジュールに115200bpsに合わせるようコマンドを送ってから16行目setserialでttyS1ポートを115200bpsのlow_latencyにセット。それからntpdateでネット上のNTPサーバを使って時刻合わせをしてRTCに時刻を書き込み。ここまでExecStartPreで実行してからntpdがサービスをスタートする。
以前の記事でsetserialでlow_latencyを使っても結果が変わらないと書いたが、長い期間で見るとNMEAの振れ幅が少し改善しているように見えたので今回はサービス起動時にsetserialを適用することにした。setserialは使わないということであれば、上の /lib/systemd/system/ntp.service の16行目は要らないと思う。
シングルボードコンピュータ用のLinux(Armbian含む)で /lib/systemd/system/ntp.service 内に PrivateTmp=true の行があったらその行を削除するかコメント化して無効にする。でないと統計情報等の出力先が設定ファイルに書いた出力先を無視?して /var/log.hdd 下になるのでワケワカランことに。理解した上で/var/log.hdd下に置くつもりならそれは構わないが、microSDカードの寿命を縮めることになるので頻繁に書き込むファイルをこの場所に置くのはオススメしない。あと、2020年7月のArmbianではlogrotateの設定の初期値が/var/log.hdd下のファイルしか面倒みないようになっていたので/var/log下のファイルがローテートされずに放置される。長期稼働を予定しているホストであれば/var/log下もローテートする設定を追加する。でないと/var/log(メモリディスク)がパンクする。ただし、logrotateサービス自体がPrivateTmp=trueになっていると/var/log.hdd以外を操作できないので /lib/systemd/system/logrotate.service の PrivateTmp=true も無効化する。/etc/logrotate.d以下も触らないといけないし、他のサービス設定も触らないといけないかも。ヘタに触ると収拾がつかなくなるので悩みどころ。

$ sudo systemctl daemon-reload
/lib/systemd/system/にある *.service を変更したらデーモンリロードしておく。もしくは変更したサービスを無効化して再度有効化する。システム再起動だけでは変更後の設定が適用されない。
/etc/ntp.conf (重要な変更部分)
1
2
3
#前略
server 127.127.20.0 mode 81 minpoll 4 prefer
#後略

忘れやすいが、GPSモジュール側のシリアル速度を変更したらntp.conf側でもmodeで速度を合わせること。(参照クロックドライバ127.127.20.xのmode 81 = 80:115200bps + 1:RMC)

/etc/ntp.conf (ズレ調整のない設定)
1
2
3
4
5
6
7
#前略
server 127.127.20.0 mode 81 minpoll 4 prefer   #NMEA mode 81: 115200bps + RMC
fudge  127.127.20.0 refid NMEA

server 127.127.22.0 minpoll 4 maxpoll 4 true   #PPS
fudge  127.127.22.0 refid PPS
#後略
$ sudo systemctl restart ntp.service
NTPサービスを再起動して24時間以上様子を見る。
「がとらぼ」ではNode ExporterでNTPの統計情報を取得してPrometheusで蓄積、Grafanaでグラフ化していつでも監視できるようにしている。

NTPのズレ調整 1
NMEAのoffsetのグラフ。これは上で書いたsetserialの未適用の状態。これだと表示中の48時間で平均が-154msになっている。ただし、グラフがところどころ数百msも下方向に伸びてしかも数分〜1時間もその状態が続いている。この平均ズレ時間をそのまま信じるのはちょっと考えもの。しかし、おおよそ150〜180msと考える。まぁ、NMEAはオマケで合わせる方針なので調整は後回しでも構わない。

NTPのズレ調整 2
ネット上の時刻ソースとの同期のグラフ。3つのNTPサーバの48時間のoffsetが描かれている。画像では上下に大きく波打っているが振れ幅としては実は2ms程度でしかないので、上のNMEAより150倍も精度が高い。でも本当はそれはちょっとおかしい。というかNMEAの振れ幅が大きすぎる。 平均は3つで1.6〜1.7msほど。これから調整するNTPサーバではこの時刻を正しい時間として合わせる。つまり、現在は設定するNTPサーバが1.6msズレているということにする。

NTPのズレ調整 3
PPSのoffset。これから調整するこのNTPサーバは現在はこのPPSの時刻が正しいと思っているのでズレは0を中心に上下にそれぞれ振れ幅10μmでグラフが描かれている。未調整でこれが上か下にズレていたらNTPサーバが何に時刻を合わせているのかを確認する必要がある。

/etc/ntp.conf (PPSの設定部分 未変更含む)
1
2
server 127.127.22.0 minpoll 4 maxpoll 4 true
fudge   127.127.22.0 time1 0.0017 refid PPS

PPS側。参照クロックドライバが127.127.22.xでは時刻のズレの調整はtime1で行う。単位は「秒」なので1.7msであれば0.0017となる。 他所の設定例のようにflag3 1なんかを設定するとPPSのoffsetが設定分ズレてワケが解らなくなるので「がとらぼ」ではflag3は設定しない。
変更したらNTPサーバを再起動する。このときdriftファイルを指定しているならnet.serviceを停止してdriftファイルの中身を消してnet.serviceを起動する。(driftファイルの中身を消してntp.serviceを再起動してすぐにdriftファイルを確認して空ならそれでもOK.)
36時間以上稼働させて、起動後少なくとも12時間は見ないでその後の24時間のoffsetの平均を見て、まだズレがあるなら更に設定を詰める。なかなか「これかな?」という値が見つからないかもしれないが、それでもおおよそで合わせるしかない。今回設定しているNanoPi NEOの例では6桁程度の精度で設定した。実際には0.00172という設定になった。これはGPSアンテナの設置環境や使用機材など幾つかの要因で値が変わると思うので「がとらぼ」の人が0.00172って書いてたから真似たら全然違ったということになるかと思う。

NMEA側。これはPPSのズレ調整が終わってからの情報で調整した方が良いと思う。この記事のNMEAのグラフではグラフの振れ幅が100ms近くあるけど、なんでこんなに酷いのかわからないが、GPSアンテナがすぐ隣にある別のNTPサーバ(FreeBSDのPCサーバとUSB接続のGPSモジュールを使ったやつ)だと振れ幅が10ms程度なので約1/10。普通はこの10ms以下(もっと小さい?)だと思うのよね。

NTPのズレ調整 4
直前に書いたFreeBSDのPCサーバとUSB接続のGPSモジュールのNTPサーバのNMEAの48時間グラフ。上に5ms、下に5ms程度の振れ幅で平均は表示している48時間でいえば-56μs。(このNTPサーバは調整済みだが、常にわずかにブレるのでこの程度の誤差はあっても異常ではない)

/etc/ntp.conf (NMEAの設定部分 未変更含む)
1
2
server 127.127.20.0 mode 81 minpoll 4 prefer
fudge 127.127.20.0 time2 0.155 refid NMEA
ネットのドキュメントを見ると混乱させられる部分だけど、参照クロックドライバの127.127.20.xでNMEAのオフセットの調整はtime2なので注意。127.127.20.xでPPSも見る場合はtime1も絡んでくるみたい。(未確認)
setserialを有効にしたらそれだけでも10ms以上(僅かだか誤差が少ない方に)ズレた。
調整する設定の単位はこれも「秒」。今回設定しているNanoPi NEOの例では結果的に0.155 (155ms)で設定した。

NTPのズレ調整 5
setserialで低遅延を適用してズレ調整済み状態のNMEAのoffsetのグラフ。
表示している48時間の平均誤差は-378μsとなっているので、振れ幅100msが当たり前の中で約400μmなら優秀ではあるけど、グラフを見たらお判りのように、7/29の早朝に長い時間メチャクチャになってるのが含まれてこれなので「調整完了」とは言い難いと突っ込まれる?でも他の時間帯でもだいたいこれで中央値が0なのよね。
先日記事のようにGPSモジュールを交換して、それでNMEAの結果が改善することを期待したのだが、謎のコノギリ波形から普通のグラフになったのは大改善とはいえ、期待していたより遥かに低い精度なので、もしかしてこのNTPサーバが使っているアンテナ個体が悪いのかな。10cm隣に設置した別のGPSアンテナを使っているFreeBSDのNTPサーバは期待程度には精度があるのでアンテナ設置場所が悪いということではない筈。

NTPのズレ調整 6
インターネット上の公開NTPサーバ3台のoffsetグラフ。7/29の午後にちょっと酷いズレが発生しているが、それで3台の平均では約100μsなのでppsの調整は一応出来ている。

NTPのズレ調整 7
当然だが、ppsのoffsetグラフの振れ幅は変わらず。

まとめ

PPS用のクロックドライバ127.127.22.xでtime1を調整するとネットの時刻ソースのグラフに変化が出るので振れ幅の中央値(≒平均)が0nsに合うようにする。PPSのグラフには変化は出ない。
NMEA用のクロックドライバ127.127.20.xでtime2を調整するとNMEAのグラフに変化が出るので振れ幅の中央値(≒平均)が0nsに合うようにする。

システム監視用のPromethusのデータ保持期間を半月にしていたのにNTPのズレ調整後に暫く放置してしまったので調整前のグラフを取得できなくなってしまった。そこで、8月に入ってからズレ未調整に戻して1週間待って画像を取得した。それでこの記事では7月の画像が調整後で8月の画像が調整前という逆転状態になっている。

関連記事: