おつです。
愛用していた Shure SE210 ですが、過酷な利用により断線してしまいました。
ということで、後継を探していたのですが、SE215 もケーブルが長くて、
久々に別のメーカーとかもあさってみようと思い、二つほど買ってみました。
■ZERO AUDIO ZH-BX500
「スタジオモニターとして使用する」とか「原音を忠実に」という謳い文句に反応。
# 基本的には味付け (強調) の少ない音質が好きなので。
うん。結構いい感じです。Shure も、もともとは味付けの少ない部類に入ると
思いますので、Shure が好きな人は結構好きな音質だと思います。
欠点は、Shure とかと比べてちょーっとだけ音漏れが大きいかな？というところ。
ただまぁ、インナーイヤーですし、よほど静かなところで大音量で聞いていなければ
ほとんど気にならないレベルのはず。
■Logicool Ultimate Ears 400
とりあえず、amazon でもそれなりに評価があったのと、個人的に好きな
スポンジのイヤーパッドがついているそうなので、買ってみることに。
んが、低域がちょっとぼやぼやしてる (いい意味で言えば強調される) のが気になる。
Shure のような音質が好きな方にはちょっと微妙な気がします。
---
いまのところ、ZERO AUDIO ZH-BX500 を使っています。
本当はスポンジ (低反発) なイヤーパッドのほうが遮音感があっていいんですが、
まぁそこはとりあえず妥協しました。
MCP 70-649 合格しました
おつです。
去る 3/17 に 70-649 試験を受けまして、無事合格しましたー。
この試験、結構しんどかったです。
Active Directory のほうは、RODC とか ADFS とか、出題分野の予想がある程度
ついていたので比較的すんなり解けたんですが、ネットワーク分野が勉強不足でした orz
Direct Access とか、IPv6 とか、微妙に覚えきれてなかったので危なかったです ＾＾；
あとは、結構 IIS 関連と、リモートデスクトップ (旧ターミナルサーバ) がらみの話が
でてくるので、そこはきっちり勉強しておいたほうがいいと思います。
# そういや WSUS はほとんど出なかったな…
去る 3/17 に 70-649 試験を受けまして、無事合格しましたー。
この試験、結構しんどかったです。
Active Directory のほうは、RODC とか ADFS とか、出題分野の予想がある程度
ついていたので比較的すんなり解けたんですが、ネットワーク分野が勉強不足でした orz
Direct Access とか、IPv6 とか、微妙に覚えきれてなかったので危なかったです ＾＾；
あとは、結構 IIS 関連と、リモートデスクトップ (旧ターミナルサーバ) がらみの話が
でてくるので、そこはきっちり勉強しておいたほうがいいと思います。
# そういや WSUS はほとんど出なかったな…
IBM のコンソールのキーボードを TrackPoint USB にした。
おつです。
ひっさしぶりに更新です。。
ということで、IBM のコンソールのキーボードを USB TrackPoint Keyboard
にしました。
理由は、タッチパッドな部分が嫌いだから。
親指側の手のひらにタッチパッド部分が当たって誤動作することが多いので…
「ほんとにはまるかな？」という懸念も杞憂でした。ぴったり。
PS2 への変換器が見つからないので、KVM のリプレースが必要になりそうですが、
今のところ、どうしても接続が必要なのは 1 台だけにおさめているので、保留。
# そういう意味では、切替器よりも他のものを買いたいかも・・
ひっさしぶりに更新です。。
ということで、IBM のコンソールのキーボードを USB TrackPoint Keyboard
にしました。
理由は、タッチパッドな部分が嫌いだから。
親指側の手のひらにタッチパッド部分が当たって誤動作することが多いので…
「ほんとにはまるかな？」という懸念も杞憂でした。ぴったり。
PS2 への変換器が見つからないので、KVM のリプレースが必要になりそうですが、
今のところ、どうしても接続が必要なのは 1 台だけにおさめているので、保留。
# そういう意味では、切替器よりも他のものを買いたいかも・・
【甘味】Luce シュークリーム
おつです。
ということで、Luce のシュークリームです。
外の生地はちょびっと厚めですが、サクサクしてます。パイシューみたいな感じ。
中はカスタードクリームで、かなり量も多めです。が、特に飽きは来ないです。
これで 200 円なんだから安いもんです。
ということで、Luce のシュークリームです。
外の生地はちょびっと厚めですが、サクサクしてます。パイシューみたいな感じ。
中はカスタードクリームで、かなり量も多めです。が、特に飽きは来ないです。
これで 200 円なんだから安いもんです。
Microsoft-Windows-Time-Service : Event ID : 50 について
おつです。
さて、Windows Time Service 関連で、ある問題が発生しているときに
下記のログが記録されることがあります。
---
ソース : Microsoft-Windows-Time-Service
Event ID : 50
説明 :
タイム サービスにより 900 秒間で 5000 ミリ秒を超える時間差が検出されました。
時間差が発生した原因として、正確度の低いタイム ソースと同期した、
またはネットワークの状態が最適でなかったことが考えられます。
タイム サービスは現在同期されておらず、他のクライアントへの時間の提供、
またはシステム クロックの更新を行うことができません。
タイム サービス プロバイダーから有効なタイム スタンプが受信されると、
タイム サービスは自動的に訂正されます。
---
(参考) Event ID 50 Local Time Synchronization
これの意味、色々な解釈ができそうな説明文ですが、要はこういうことです。
---
ある一定 (この場合 900 秒) の間、ずっと NTP サーバとの時刻差が
一定 (この場合 5000 ミリ秒) 以上の状態が続いていた。
なので、現状 NTP サーバとしての動作をやめている。
---
ちょっと文章からは判断つきにくいかなぁと思いますが、
検証 (Windows Server 2008、2008 R2) の結果、こんな結論に至りました。
ちなみに、900 秒は SpikeWatchPeriod レジストリ値が、
5000 ミリ秒は LargePhaseOffset レジストリ値が該当します。
(参考) Windows Time Service Tools and Settings: Windows Time Service
なお、「NTP サーバとの時刻差」は、Windows Time Service のデバッグログや、
w32tm コマンドに stripchart オプションをつけることで、確認できます。
さて、Windows Time Service はある一定以上の時刻差がある場合には即時同期
しますし、その範囲内にある場合でも、SLEW モードで時刻同期します。
(参考) w32timeデバッグ・ログとw32tmコマンド − ＠IT
このため、ふつーな状態だと、900 秒間も 5000 ミリ秒以上の時刻差がでることは
あまり考えられません。
ではなぜこういうことが起こるか、という点については、下記の KB が参考になる
かもしれません。
When SpecialPollInterval is used as a polling interval, the Windows
Time service does not correct the time if the service gets into Spike state
つまり、「SpecialPollInterval を使って、NTP サーバと同期している」 かつ、
「Type 値 が NTP で時刻同期している (※)」 ときに、受け取った時刻情報が
Spike であると判断された場合、SpikeWatchPeriod で設定している分の時間が
経過しないと正常に時刻同期を行わない、そうです。
(※) 下記レジストリキーの "Type" 値が "NTP" のとき
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
(参考) Windows Time Service Tools and Settings: Windows Time Service
時刻が Spike であると判断されるのは、大抵の場合、「受け取った時刻が今までに
受け取っている時刻情報よりも大きくずれてしまっている」時です。
(上記の KB では「LargePhaseOffset 以上の時刻差がある場合」と書かれて
いますが、LargePhaseOffset 以上の時刻差があっても、Spike と判断されず、
正常に時刻同期できてしまう場合がありました。ちょっと謎。)
なので、参照先 NTP サーバの時刻がある瞬間に変わってしまった場合、それ以降の
時刻情報が Spike であると判断され、SpikeWatchPeriod の時間分、時刻同期を
行わない、すなわち、Event ID : 50 発生の条件を満たしてしまう、ということです。
これを回避するには、NTP サーバを指定する際に、NTP サーバ名 (または IP アドレス)
の後に ",0x8" をつける (つまりSpecialPollInterval を使わないこととする) こと。
まだまだ Windows Time Service の動作は不思議がいっぱいですね。。。
---
と、書いたものの、これ SpecialPollInterval 使ってなくても発生しますね…
",0x8" をつけた環境であっても、参照先 NTP サーバの時刻進めたら、
Spike フラグが一定期間 (SpikeWatchPeriod) 外れなくなりました…
ということは、根本的な解決には、「参照先 NTP サーバが外部と時刻同期した
際にも、Spike と見なされないようにする」 しかないのかも。
となると、「参照先 NTP サーバが頻繁に時刻同期するようにする」とか、
「参照先 NTP サーバが Slew モードで時刻同期する」とか、
「NTP クライアントの LargePhaseOffset を大きくする」とか、くらいなのかなぁ。。。
さて、Windows Time Service 関連で、ある問題が発生しているときに
下記のログが記録されることがあります。
---
ソース : Microsoft-Windows-Time-Service
Event ID : 50
説明 :
タイム サービスにより 900 秒間で 5000 ミリ秒を超える時間差が検出されました。
時間差が発生した原因として、正確度の低いタイム ソースと同期した、
またはネットワークの状態が最適でなかったことが考えられます。
タイム サービスは現在同期されておらず、他のクライアントへの時間の提供、
またはシステム クロックの更新を行うことができません。
タイム サービス プロバイダーから有効なタイム スタンプが受信されると、
タイム サービスは自動的に訂正されます。
---
(参考) Event ID 50 Local Time Synchronization
これの意味、色々な解釈ができそうな説明文ですが、要はこういうことです。
---
ある一定 (この場合 900 秒) の間、ずっと NTP サーバとの時刻差が
一定 (この場合 5000 ミリ秒) 以上の状態が続いていた。
なので、現状 NTP サーバとしての動作をやめている。
---
ちょっと文章からは判断つきにくいかなぁと思いますが、
検証 (Windows Server 2008、2008 R2) の結果、こんな結論に至りました。
ちなみに、900 秒は SpikeWatchPeriod レジストリ値が、
5000 ミリ秒は LargePhaseOffset レジストリ値が該当します。
(参考) Windows Time Service Tools and Settings: Windows Time Service
なお、「NTP サーバとの時刻差」は、Windows Time Service のデバッグログや、
w32tm コマンドに stripchart オプションをつけることで、確認できます。
さて、Windows Time Service はある一定以上の時刻差がある場合には即時同期
しますし、その範囲内にある場合でも、SLEW モードで時刻同期します。
(参考) w32timeデバッグ・ログとw32tmコマンド − ＠IT
このため、ふつーな状態だと、900 秒間も 5000 ミリ秒以上の時刻差がでることは
あまり考えられません。
ではなぜこういうことが起こるか、という点については、下記の KB が参考になる
かもしれません。
When SpecialPollInterval is used as a polling interval, the Windows
Time service does not correct the time if the service gets into Spike state
つまり、「SpecialPollInterval を使って、NTP サーバと同期している」 かつ、
「Type 値 が NTP で時刻同期している (※)」 ときに、受け取った時刻情報が
Spike であると判断された場合、SpikeWatchPeriod で設定している分の時間が
経過しないと正常に時刻同期を行わない、そうです。
(※) 下記レジストリキーの "Type" 値が "NTP" のとき
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
(参考) Windows Time Service Tools and Settings: Windows Time Service
時刻が Spike であると判断されるのは、大抵の場合、「受け取った時刻が今までに
受け取っている時刻情報よりも大きくずれてしまっている」時です。
(上記の KB では「LargePhaseOffset 以上の時刻差がある場合」と書かれて
いますが、LargePhaseOffset 以上の時刻差があっても、Spike と判断されず、
正常に時刻同期できてしまう場合がありました。ちょっと謎。)
なので、参照先 NTP サーバの時刻がある瞬間に変わってしまった場合、それ以降の
時刻情報が Spike であると判断され、SpikeWatchPeriod の時間分、時刻同期を
行わない、すなわち、Event ID : 50 発生の条件を満たしてしまう、ということです。
これを回避するには、NTP サーバを指定する際に、NTP サーバ名 (または IP アドレス)
の後に ",0x8" をつける (つまりSpecialPollInterval を使わないこととする) こと。
まだまだ Windows Time Service の動作は不思議がいっぱいですね。。。
---
と、書いたものの、これ SpecialPollInterval 使ってなくても発生しますね…
",0x8" をつけた環境であっても、参照先 NTP サーバの時刻進めたら、
Spike フラグが一定期間 (SpikeWatchPeriod) 外れなくなりました…
ということは、根本的な解決には、「参照先 NTP サーバが外部と時刻同期した
際にも、Spike と見なされないようにする」 しかないのかも。
となると、「参照先 NTP サーバが頻繁に時刻同期するようにする」とか、
「参照先 NTP サーバが Slew モードで時刻同期する」とか、
「NTP クライアントの LargePhaseOffset を大きくする」とか、くらいなのかなぁ。。。
