べつになんでもないこと

2009年1月1日午前9時にうるう秒が挿入されます。
W32Timeで時刻合わせしてますので、うるう秒がどのように処理されるか調べてみました。

うるう秒に関する Windows タイム サービスの処理

うるう秒が発生すると、Windows タイム サービスを実行している NTP クライアントが、実際の時刻より 1 秒進むことになります。この差は、次の同期のときに解決されます。

まあそれはいいのだけど、デフォルトだとslewモードが1秒になってるので、ゆっくり時間が合うことになります。

このゆっくりのペースが知りたいのだけど、それらしい資料にたどり着けないでいます（前回、slewモードにふれなかったのはそういう理由だったり）。
資料ではないけど、http://www.atmarkit.co.jp/fwin2k/operation/winntp02/chart.gifにゆっくり補正される様子があるのですが、10^-3ペースぐらいかな？

もっとも、NTPサーバにゆっくり補正なんてされたら、クライアントが補正されるのはいつの話が分かったものではありませんので、サーバの
[HKEY_LOCAL_MACHINE¥SYSTEM¥ControlSet001¥Services¥W32Time¥Config]
MaxAllowedPhaseOffsetは0にしてます。
逆に、時間が逆戻りすると支障のあるアプリが動いていたら、デフォルトの1秒では短すぎる訳でドメイン参加時のデフォの300秒くらいがいいでしょうか？

---

ここから先は単なるボヤキ。
とりあえず、ブラブラしていてたどり着いた資料。
Windows Time Service Tools and Settings: Windows Time Service
英語読めないorz

[HKEY_LOCAL_MACHINE¥SYSTEM¥ControlSet001¥Services¥W32Time¥Config]
LargePhaseOffset（×10^-7秒ずれていると時間を補正する）
PhaseCorrectRate（補正量を決めるなにか？小さい方が早く補正されるけど、不安定になるとかデフォはドメイン参加が1スタンドアロンが7）
UpdateInterval（補正タイミング？この値のシステムクロック毎に介入？）

MaxAllowedPhaseOffset（n秒までの誤差をslewモードで補正する）
と思っていたのだけど、なんか次の式を満たさないといけないらしい……300までが無難ってことかも
|CurrentTimeOffset| / (PhaseCorrectRate*UpdateInterval) < SystemClockRate / 2
よく分からないのですが、この式をみてると、PhaseCorrectRate*UpdateIntervalクロック毎に補正介入するという理解でいいのかな？だからPhaseCorrectRateを小さくし過ぎると、介入回数が多くなって時間は早く合うけど、ブレが大きくなりすぎて不安定になる。と理解すると上の話と一致するかなぁ。

相変わらず補正量が分からないのですけど……なんだかグダグダ。
だから触れたくなかったんだ。orz