我が家のデータストレージの主役は、玄箱である。昨年の夏から使っている。

玄箱は、元々、NAS(Network Attached Storage)なのだが、Linux で動くのを良い事に Debian を入れて、各種サーバーとして使ってい出した。サーバーなので、一度電源を入れたら、何日も何ヶ月も付けっぱなしである。

昨年11月からノンストップで、Wiki とか、掲示板のサーバーに使っていたら、書き込み時刻がエラク狂っていることに気が付いたのが、今年の１月である。

どうやら、一日に３分くらい進んでいたようだ。２カ月弱連続で使っていたので、３時間近く進んでいたので、気が付いたのだ。

試しに電源を一度ＯＦＦし再起動したら、時刻は、ほぼ正確になった。

このことから、リアルタイムクロックは問題なく、狂っているのは、システムクロックの方だと判った。

パソコンも同じだが、玄箱にもクロックが２つあり、一つがリアルタイムクロックで、もう一つがシステムクロックだ。

リアルタイムクロックは、本体の電源が入っていなくても、動いている時計だ。システムクロックは、ＣＰＵの駆動クロックを源振にした時計で、当然ながら、本体の電源が切れている時は動かない。

電源投入時には、リアルタイムクロックから時刻を呼び出し、システムクロックに反映する。その後、電源が入っている間は、システムクロックを使う。

元々、玄箱は、NAS つまり外付きの HDD の一種なので、連続で使用するのは、せいぜい数時間程度と想定されて作られたようだ。このような使い方なら、リアルタイムクロックさえ正確なら多少システムクロックが狂おうと構わない。

しかし、私のようにサーバーとして連続運転で使う場合は問題だ。

ネットを調べたら、同じく玄箱をサーバーとして使っていて、時刻が狂う事を気にしている人が居た。そこには、ＣＰＵクロックからシステムクロックにする時、分周比を変えることで調整する方法があった。

試行錯誤の末、２月にはシステムクロックが満足できる精度を得た。

何事もなく、数カ月が過ぎたが、７月になって、今度は一日に５分も遅れる状態になった。

気温に依存するのだろうか？　再び調整して、満足できる精度を得た。

９月に入り、再び、システムクロックが進み始めた。

いい加減あきれたので、ntpdate を使って時刻を自動更新することにした。

システムクロックは、わざと遅れるように設定しておいて、一日に一回午前４時にネット上の時刻サーバーを呼びだしシステムクロックを訂正する。システムクロックをわざと遅れるようにしたのは、時刻更新後、続けて時刻サーバーを呼び出さないようにするためだ。

ついでに、時刻更新の時、修正時間を記録した。

その記録をグラフ化して、最初に見た時、「こりゃ、温度に依存するかも」と思って、ネット上から東京の最高気温と最低気温の情報を得て、並べてみた。（本当は松戸に住んで居るのだが、松戸のデータは無かった。そのため、最も近い東京のデータを使った。）

グラフの通り、見事に気温と関係している。先にも述べた通り、システムクロックが１日３５秒も遅れているのは、わざとだが、細かい変動は気温に依存している。

気温が高ければシステムクロックは遅れ、気温が低ければ進み気味になる。

振り子式の機械時計も気温と進み遅れが関係する。気温が高ければ、振り子が伸びて周期が長くなって遅れる。気温が低ければ、振り子が縮み進む。

私の腕時計も機械式で、全体としては進む傾向なのだが、夏はやや遅れ気味に、冬は更に進み気味になる。一週間に一度、日曜日の朝に合わせることにして居るが、夏場だと５秒強進み、冬場だと４０秒前後進む。

「全く、玄箱の時計も機械式並みだなあ。クォーツの風上にもおけないな」（詳しく調べた訳じゃ無いが、玄箱のクロックも水晶発振だと思うので）

・・と思って居たのだが、詳細にグラフを見て居るうちに、思い違いに気が付いた。

私の腕時計は、一日あたりだと、夏場は１秒程度進み、冬場は６秒程度進む訳だから、温度による変動分は５秒程度だ。

これに対し、玄箱のシステムクロックの遅れは、35.2 秒から 35.5 秒の間を変動して居る。

つまり、一日あたりの変動は、わずか 0.3 秒だ。

ただし、グラフで示した範囲は、真夏と真冬は記録されておらず、最高気温が１６度から３３度、最低気温が１２度から２５度の範囲内だ。

気温の範囲は、記録期間の気温変動範囲の３倍を超ることは在り得ないだろう。すると玄箱のシステムクロックの変動範囲は、0.9 秒以下と推測される。

一日あたりの変動が、１秒以下なら、機械式の時計より、ずっと良い。

だが、先にも書いたように「２月に満足できる精度の調整したシステムクロックが、７月になると一日に５分も遅れ、９月には元に戻った。」と言う事実に反する。

メモを頼りに再現すると、１月末から２月にかけては、一日あたり 35.1 秒の遅れがあったらしい。これは、完全に上記のグラフの延長線に乗る。

だが、７月の頭は、一日あたり 368 秒も遅れて居たらしい。これは、上記のグラフから逸脱して居る。

どうやら、７月初めから８月の末の期間、グラフのような温度依存性の線形範囲を超えて居たようだ。

最高気温が、３５度を超るような『超真夏日』では、玄箱の中で、何かがあったようだ。原因は何だろう？

７月から８月の間の詳細なデータが無いのが悔やまれる。

来年の夏が楽しみだ。

（恒温槽にほうり込めば良い・・等と言わないこと。流石にこわい）

== 参考リンク ==

・玄箱の時刻合わせ adjtimex を使って、玄箱のシステムクロックを合わせる方法。

・気温データのページ 毎日の最高気温・最低気温が記録されて居る。気温データの使用を快諾して下さった中村さんに感謝！！

注意

ブログのコンテンツの内、「告知」など時期よって情報価値が無くなるのは除いてある。また、コンテンツに付いたコメントは書き込み者に著作権があるものと判断し、ここに持ってきていないので、コメントを見るときは、元々のブログコンテンツを参照してもらいたい。

その他、ブログ発表後、コメントなどの内容を反映するなど、内容を変更しているものもあるので、注意してほしい。