2013/12/29(日)WindowsでUSBデバイスが最後に挿された日付を確認する
2013/12/29 16:53
for Windows7。
以下を参考。
NetAgent Official Blog: USBメモリとレジストリ
手順をまとめると、
- そのデバイスのベンダ名、デバイス名を把握する
- HKEY_LOCAL_MACHINE\SYSTEM\MountedDevicesからベンダ名、デバイス名で該当デバイスのGUIDを探す(バイナリデータ内にベンダ名、デバイス名が入っているので頑張って探す)。
- HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2から前項で調べたGUIDを持つキーを探す。
- 前項で得たキーのタイムスタンプを調べる。
以下を参照。
レジストリ・キーの最終更新日時を調べる- @IT
2013/12/13(金)fi-6130のTWAINがフォーカスを取るのを抑止する
2013/12/13 16:27
とりあえずAPIフックで対処可能。
Windows API Hooking Tutorial
上を参考に、SetForegroundWindowを握りつぶせば良い。
最初単にグローバルフック(SetWindowsHookEx)でどうにかなるような気がしていたのだが、WM_ACTIVEAPPメッセージを握りつぶそうとしてもうまくいかなかった(WM_ACTIVEAPPが飛んできたタイミングは捕まえられる。そこで元のウィンドウにフォーカス移すのはちょと……)。
実のところWindowsのメッセージ機構の理解にあやしいところがあって、キーボード・マウス以外のメッセージにキャンセル機構がないのか、SetWindowsHookEx自体の制限か、それともWM_ACTIVEAPPメッセージは通知だけで、ウィンドウのアクティブ処理自体はエクスプローラ側の触れない領域にあるのかといったあたり判断できてない。C++でWin32ネイティブアプリ書いて、WndProc内であれこれやってみれば結論が出るんだろうけど、今回は時間がないので次回以降の課題。
.NET系でもマウス・キーボードのグローバルフックがかけられることは覚えておこう。
ソース整理できたらそのうち載せたいけども、元コードのライセンスがわからないな……
2013/12/13(金)自炊を突き詰めてみた
2013/12/13 15:23
自分が妥協できるやり方で、どれだけ高速化・効率化できるかを突き詰めてみた。
所要時間
突き詰めた結果、こんな感じ。おおざっぱに、前処理 -> スキャン -> 後処理となり、
前処理: 人力
スキャン: 自動
後処理(操作・目視判定): 人力
後処理(自動): 自動
となる。
ページ数依存の時間
200ページ(背厚おおよそ10mm程度)ごとに、5分(スキャン:4分, 後処理(自動):1分)冊数依存の時間
1冊ごとに、3~4分(前処理(裁断・タイトル作成):2分, 後処理(操作・目視判定):1分)その他ミスによって生じるロス時間
ミス1回ごとに、だいたい10分。(ミスのほとんどは、スキャン時に発生。紙サイズ自動判定のミス、ノリ残りによる給紙ミス、紙質混在による給紙ミスがほとんど)
モデルケース
[a]週刊少年誌2冊 = 50mm = 1000ページ => 5分 * 5 + 3分 * 2 = 31分[b]薄い本15冊 = 50mm = 1000ページ => 5分 * 5 + 3分 * 15 = 70分
こんな感じ。正直集中力が続かないので(特に冊数が多い場合)、実作業時間はこれに1.2~1.5掛けになるが最大効率だとこの数字になる。
複数の本を対象にまとめて作業すれば、パイプライン化によって前処理とスキャンを同一時間に行うことは可能(ただし、本当にかかりっきりになる)。
方法
自分のやり方をざっと書いておく。機器構成的には以下のような感じ。
・中国製裁断機(XD-3203A)
・Fujitsu fi-6130
・PC(Core-i5 2500K, 16GB, HDD)
前処理
自炊する対象を決める
最終的にはこれが一番重要。とっとくか、捨てるか、自炊するか即断。裁断
使用している裁断機(XD-3203A)は精度が低いのでちょっとした工夫・コツがいる。突き当ての遊びが大きく垂直が出てないので、突き当てをちょっと刃側に寄せて位置合わせをする。
裁断面が斜めにならないように(特に厚い本で斜め切りになりやすい)、紙押さえ下部と紙押さえの接地部にゴムシートなどの滑り止めを貼っておく(参考: 漫画をスキャナで電子書籍化する初心者向け自炊解説サイト 裁断機で斜めに切断・切れないようにする解決方法)。紙押さえを強く押し下げたあと、ちょっと緩めて押し下げるを何度か繰り返す。さらに裁断時にも左手で紙押さえを押し下げながら裁断する。
ここまでやってもほどほどの精度なので、裁断機は良いもの(自炊裁断機200DXなど)を使った方がよい。
チェック
裁断した束を、スキャナまで移動する間に、以下のことをチェックする。[1]特殊サイズ・特殊紙がないか
[2]くっついているページがないか(特にカラーページ・表紙の周り)
[3]ノリが大きく残っていないか
[1]に該当する場合、スキャナに通るかどうか考える。通らないのであれば追加で裁断をするか、フラットベッドで取り込むか、スキャンを諦めるか決める。
[2][3]に該当する場合、剥がして手当てする。
タイトル作成
本タイトルor誌名、お好みで著者・サークル名・出版社・出版年・ジャンルなどをテキストエディタで作成する。出版された書籍のみを扱うのであれば、バーコード読み込みからタイトルを自動生成するスクリプトなどを生めば効率が上がるかも知れない。
ただし、amazon DBはかなりの表記揺れがあるため、シリーズでタイトル揃えるといった要望を満たせないかも。古い本ではバーコードがなかったり、JANコードがDBになかったりということもある。amazonを万能とは考えないこと。
私は秀丸で、項目(ジャンル, 著者, タイトル)をタブ区切りにしたファイルを作り、マクロでクリップボードへコピーまでやっている。
//一般的な書籍タイトル名を生成するマクロ movetolineno 1, 3; deleteline; movetolineno 1, 2; beginlinesel; copy; paste; //著者名有り replacedown "([^\\t]+)\\t([^\\t]+)\\t([^\\t]+)\\t([^\\t]+)", "(\\1) [\\2 (\\3)] \\4", regular; if(result == 0){ //著者名無し replacedown "([^\\t]+)\\t([^\\t]+)\\t\\t([^\\t]+)", "(\\1) [\\2] \\3", regular; } if(result == 0){ //団体名・著者名無し replacedown "([^\\t]+)\\t\\t\\t([^\\t]+)", "(\\1) \\2", regular; } movetolineno 1, 3; beginlinesel; copy;これを、以前のBTScanTool(AutoIt!でBTScanをちょっと改良 - 色々日記(ざ・めも))にCtrl+A, Ctrl+Vして、フォルダ名をBTScanにセットする。
BTScanの入力開始ボタンを押下して、フォルダを作成。
スキャン
fi-6130の給紙枚数はだいたい10mmくらいまでなのでそれくらいごとにスキャナに通す。このとき、摩擦が少ない紙(カラーページなど)はセット時の束中で一番最後に取り込むように区切るとミスが少ない。fi-6130の給紙能力は素晴らしく優秀だが、紙質混在原稿ではミスをすることがあり、摩擦が大きいページを先に吸ってしまうことがある。
原稿をさばいて、先に給紙するものほど奥に入るように若干斜めにセットする方がミスが少ないのはプリンタと同じ。
スキャナが止まってから束に割ると効率が落ちるため、作業スペースを確保して先に全部束に割ってしまう方がいい。少なくとも次にセットする束は準備しておくと効率がよい。
スキャンは、BTScan + fi-6130(TWAIN)で行う。
基本的に全て両面、300dpi, カラー, bmp, 自動用紙サイズ検出、4桁1始まり連番でスキャン。
特殊紙は都度単体でスキャン。
自動用紙サイズ検出に失敗したケースでは、黒背景でB5,A4等の規定サイズでスキャン。
コミック等表紙については、長尺で取り込めるものについては横向き長尺でスキャン。
現状、BTScan以上に優秀なソフトがないのだが、BTScanはプロファイルを自動更新してしまうなど使い勝手が悪い。スキャンパートは実時間依存大であり、手戻りが多大なロスになるため極力どんな本でも同じ設定で出来るようにすること。BTScanのプロファイルは信用しないこと。
なお、fi-6130含むfi系のTWAINドライバは1枚スキャンするごとにフォーカスを持って行く。これだとスキャン中は他の作業が出来ないため結構きつい。APIフックで何とかする方法はあるのでfi-6130のTWAINがフォーカスを取るのを抑止する - 色々日記(ざ・めも)を参照。
後処理
自作スクリプトとZoner Photo Studio 15, RalphaPlus, SpringM等を駆使する。サイズ取得
スキャンしたフォルダで自作Rubyスクリプトを実行し、最小サイズと全体のずれを取得する。$KCODE = "Shift-JIS" require "rubygems" require "image_size" require 'win32/clipboard' max_width = 0 min_width = 99999 max_height = 0 min_height = 99999 Dir.glob("*.bmp"){ |f| open(f, "rb"){ |fp| img = ImageSize.new(fp.read) if max_width < img.width then max_width = img.width end if max_height < img.height then max_height = img.height end if min_width > img.width then min_width = img.width end if min_height > img.height then min_height = img.height end } } width_diff = ((max_width.to_f-min_width)/max_width*10000).round.to_f/100 height_diff = ((max_height.to_f-min_height)/max_height*10000).round.to_f/100 param = "W/2-#min_width/2,H/2-#min_height/2,#min_width,#min_height\n" output = "" output += "w:#min_width-#max_width #width_diff%ずれ\n" output += "h:#min_height-#max_height #height_diff%ずれ\n" output += "\n" output += param open("c:\\**documents**\\ralpha_trimming_param\\ralpha_trimming_param.txt", "w"){ |wp| wp.write output } Win32::Clipboard.set_data(param) IO.popen "c:\\**program**\\hidemaru\\hidemaru.exe c:\\**document**\\ralpha_trimming_param\\ralpha_trimming_param.txt"適当に書いたのでメチャクチャ。実行すると、秀丸が立ち上がってこんなのが出る。
w:1642-1658 0.97%ずれ h:2041-2045 0.2%ずれ W/2-821,H/2-1020,1642,2041プロンプトでやると閉じ忘れたときに一手間増えるので敢えて秀丸に出力する(スキャンフォルダを削除するときに「使用しているアプリケーションがあるため~」となる)。
最後の1行はRalphaPlusに投げるためのパラメータ。自動的にクリップボードにコピーされている。
ずれが2%を超えているケースは、スキャン時に何かが起こっている可能性が高いので見直しをかける。
目視チェック
サイズ取得と並行して、Zoner Photo Studio 15を立ち上げる。Zoner Photo Studioは起動ディレクトリを指定できないので、AutoIt!で起動ディレクトリを渡してやる。$Title = "Zoner Photo Studio 15 FREE" Run("C:\\**program**\\Zoner\\Photo Studio 15\\Program64\\Zps.exe") WinWaitActive($Title) WinActivate ( $Title ) ControlClick ( $Title, "", 100 ) ClipPut($CmdLine[1]) Send("^VENTER")このAutoIt!のスクリプトにディレクトリ名を引数として渡してやると、Zonerを立ち上げたあとにそのディレクトリに移動してくれる。
ここで、カラーページを選択しRalphaPlusにD&D。Zoner上にいったん戻り、次の作業のためにCtrl+Iして選択を反転。
bmp->jpg(カラー)
ここから先はRalphaPlusでの処理。プロファイルをカラーに切り替え、トリミングのパラメータに"X座標、Y座標、幅、高さ(px)"指定でクリップボードのデータをCtrl+Vする。
カラープロファイルでやっているのは
・レベル補正
・トリミング
・リサイズ
・アンシャープマスク
・ノイズ除去
F5で実行。Ctrl+Delでクリア。
bmp->jpg(モノクロ)
再度、Zonerに戻って現在選択されているファイルをもう一度RalphaPlusにD&D。プロファイルをモノクロに切り替え、トリミングのパラメータに"X座標、Y座標、幅、高さ(px)"指定でクリップボードのデータをCtrl+Vする。
モノクロプロファイルでやっているのは
・グレースケール化
・レベル補正
・トリミング
・リサイズ
・アンシャープマスク
・ノイズ除去
適当なページを選んで、レベル補正のみ確認する。
裏移りが極端に酷い場合、若干白飛ばしを強めにする。
薄いグレースケール・トーン飛びが酷い場合、若干白飛ばしを弱めにする。
F5で実行。
bmp移動
現時点で、スキャンフォルダにbmpとjpgが混在しているため整理する。スキャンフォルダで、backフォルダを作成しbmpファイルをそこに移動するスクリプトを実行。
$BACKUP_DIRNAME = "back" if not File.exist?($BACKUP_DIRNAME) then Dir.mkdir($BACKUP_DIRNAME) end Dir.glob("*.bmp"){ |file| File.rename(file, "back/" + file) }
チェック
Mangameeya等のビューアでざっと後処理したjpgをチェックする。削除
チェックして問題無ければ、bmpの入ったbackフォルダを削除。圧縮
Zoner等がまだひらいていれば閉じるWinRARにスキャンフォルダをD&Dして無圧縮・リカバリレコード付きで圧縮する。
これにて完了。
今後の高速化
スキャンデータストレージとしてHDDをRAMディスク or SSDに変更
スキャン周り・後処理について高速化が期待できる。RAMディスクの場合、今のやり方ではまとめて作業すると簡単に使い切ってしまうのと後続作業を後日に回したいときがネックか。
SSDは効用次第だが、このためだけに導入するのは疑問。
BTScanの上位互換ツールの発見 or 開発
BTScanがもうちょっと使い勝手が良ければ、スキャン時に特殊紙・カラーを選り分ける、jpegでスキャンするなどをした方が効率が上がる可能性がある。現状のBTScanでこれをやると、プロファイル仕様の問題でどうしてもミスが増える。可読性を多少犠牲にする
モノクロとカラーで後処理を分けているが、これを一本化すればかなり人力判定・操作コストが減る。ただし、モノクロページはやはりグレスケ化した方が綺麗ではあるのでどこまで割り切るか。機器の更新
CPUについては、高速化すれば当然後処理が多少早くなる。とはいえ抜本的な改善はintel CPUでは2015年のSkylake待ちである。AMD GPGPUが進めば面白いが…?ドキュメントスキャナについては、fi-6130でも既に準業務機という位置づけなのでこれより早いスキャナはなかなか手に入るような価格では出てこないとは思うが、なにがしか技術革新があるかも知れない。
裁断機については、ダーレ200DX等に変えることで(裁断可能厚そのものは減少するが)、垂直性や斜め切りが改善できるならば結果的に効率化できる可能性がある。
総括
自炊は時間と空間のトレードである。使われる時間はなんら生産的でも文化的でもないため、とにかく辛い。人には絶対勧めない。入手性が高い本であれば手放してまた読みたいときに買い直すも良し、電子版があるならそれを買うも良し。
トレード対象になる時間を鑑みて、本当にその価値があるか考えるようにしたい。特にコミックには手を出さない方が無難。20分で読める本の自炊に最速8分かかるということを肝に銘じる必要がある。解像度が低かろうが、カバー裏が収録されて無かろうが、Kindleがあればもうそれでいいじゃない。amazon万歳。
赤松先生が以前提唱していた、電子化されてない本をアップしたら、版権取りと電子書籍販売まで代行してくれるサービスがあったらいいのに……
2013/11/27(水)電子書籍雑感
2013/11/27 11:08
一応一通りショップ調べたけど、汎用性のKindleと画質のebookJapanという構図でよさそう。
[参考]
週刊少年ジャンプデジタル版の画質をKindle版とeBookJapan版で比較してみた : 見て歩く者 by 鷹野凌
電子書籍の情報をまとめてみる
以下、個人的な使い方とあれこれ考えたことを書き連ねる。
私個人としては、マンガと小説を徐々に電子書籍にシフトしたいという感じ。重くてかさばる技術書や技法書を移行するのが一番いいのだが、課題が結構ある。
・現在の電子書籍(和書)はほぼ全てがDRMあり
・DRMありである以上、読書アプリは固定
・ほとんどの読書アプリがサムネイル表示機能を有しない。ページ移動や動作が重いものも多い。
好きなところから読んだり、ぱらぱらめくって興味を探す的な用途には酷く向かない。他方、先頭から連続的にしか読まないようなデータ、特に小説類では現在の電子書籍でもそこそこの満足が得られそうだ。
将来的に、DRMが無くなってepubやpdfでの提供になればユーザは好きに高機能な読書アプリを選択できる。
DRMが無くなってもフォーマットコンバート手段が出てこない可能性はあるが…… ま、メジャーなものについては誰かが何とかするだろう。たいていのものはepubをDRMの皮でラップしたものだろうし。
DRMフリーのものについては好きにフォーマット変換するのは当たり前のようだ。下のアプリケーションなどが有名どころ。
calibre - E-book management
さて、私が毎号買っている月刊アフタヌーンが電子書籍化した。
1000ページ級の巨人漫画誌アフタヌーンがスマホ&PCで毎月読める「アフタヌーン電子版」配信開始! - アフタヌーン公式サイト - モアイ
大手のコミック誌が継続的に電子書籍を発行するようになったのは一つのマイルストーンと言えるだろう。
アフタヌーンはかさばるわ重いわで電子書籍化のメリットが大きい。電子書籍という物を理解するにもいい素材と判断して移行を決断。なにも考えずに、メジャーどころのKindleで買ってみた。
Kindle版はぶっちゃけ解像度が低い。フキダシは読めるが、ルビやマンガ以外の記事はかなり苦しい。Kindleアプリの最大拡大率が低いこともあって今私が使用しているデバイスではマンガ以外の記事はちょっと読めない。
参考サイトにもあったがebookJapanの方が画質はずっと良さそう。
アフタヌーンではKindle版181.0MBに対して、ebookJapanは238.4MBである。この容量差がそのまま解像度に換算されていれば、縦横それぞれ1.15倍程度の差がありそうだ。
Android Kindleアプリは使い勝手が悪い。
最大拡大率が小さい、サムネイル表示が出来ない、ページジャンプまわりのI/Fが奇っ怪。
良いところもある。複数の端末で最終ページを同期できるのは実本よりも便利だろう。
トータルでは、最初から最後へ読み進めるタイプの本(小説とか)で、文字データならかなり良さそうではあるが、画像タイプの本では不満の方が多い。
一方ebookJapanはというと、使い勝手が聞くだに厳しい。電子書籍を保持できるのは常に1端末。別の端末に移すにはいちいちebookJapan経由で書籍を"トランクルーム"に返す必要がある。とてもやってられそうにない。買って比較するのが正しいのだが、ちょっと意欲が湧かなかった。
どちらを軸にするかを考えると、まあ使い勝手でKindleかなと。
将来的にDRMが無くなるか緩くなってくれば、解像度が高い側で買い直すということは考えられる。
あるいは解像度アップや複数データサイズからの選択制に踏み切る電子書籍書店が出て来るかもしれない(一応amazonに解像度アップの要望は出した)。
どうせ数年内にKindle for PC(日本版)が出て来ると思うので、そこら辺で状況が変化してくると思う。
どこをどう考えても、amazonやAppleが先行してDRMを取っ払い、日本企業が置いてかれて、海外商店の大勝利という構図は見えている。なんだか悲しい。
ま、状況が変わるまではとりあえずアフタヌーンを軸に少量Kindleで買っておきアンテナを張るくらいでいいかな。
2013/11/09(土)HL-5450DNの印刷設定メモ
2013/11/09 4:44
メモしておかないと毎回間違えそうなので残しておく。
最近、BrotherのモノクロレーザープリンタHL-5450DNを導入した。
この機種、True 1200dpi出てグラデーションもかなりよいとの評判。
主にマンガ原稿を印刷する用途としても期待していた。
が、どうも期待した結果通りにならない。
あれこれ試した結果、どうも印刷結果に対して設定項目を誤認しやすい(あるいは自分がレーザプリンタの慣習を知らないだけ)名前になっているようだ。
[Brother HL-5450DN seriesのプロパティ->基本設定->印刷設定]
ここの項目が一番印刷結果に影響を与える。
3種類。
"グラフィックス":
プリンタ側でPhotoShopでの誤差拡散に近い二値化処理を行っている。元画像が二値画像なら(おそらく)これで問題無いが、グレースケールではディザ処理がかかる分汚くなる。
"テキスト":
"グラフィックス"のように二値化をかけずに(そのまま?)出力している。元画像のグレスケ部はインクジェットでのグレスケに近いし、二値・トーン部もしっかり出る。
"手動設定"->"システムのハーフトーンを使う":
一定の閾値を境に二値化がかかる。色々設定を弄ってみたのだが、想定と違ってハーフトーンにならなかった。グレスケを出力する場合白に飛ぶか黒につぶれるかどちらかになりそう。
それ以外に、"手動設定"内部に3種類の改善チェックボックスがある。これらについては確認した限りでON/OFFによる大きな差異は見えなかった。基本外す方向で良いような気がする。
ということで、"テキスト"がすさまじく優秀。マンガ原稿の場合、二値化にしろなんにしろ原稿側で処理してしまうのが基本だろう。"グラフィックス"を意図して選ぶ必要はないと思われる。
"グラフィックス"はお手軽にプリンタ機能だけでハーフトーンかけたいときに使うのが良いんだろうねえ。
最後にオマケで5450DNの雑感を書いておく。これまで使っていたのがMultiWriter 2350Nなので、それと比べてっていうところ。
印刷速度や綺麗さは大変優秀。特に1200dpiはすごい。グレースケールがこんなに綺麗に出て、この印刷速度。サイズも、ギリ卓上と名乗れるくらいでコンパクト。
動作音はかなり五月蠅い。静音モードにしないとちょっと夜間は無理。静音モードにした上でなお壁が薄くなければ使えるか。
心配していたオゾン臭や発熱も、2350Nに比べればずっとマシだった。あとは不満になりやすそうな用紙カールとか印刷の濃さがどうなるか。これらもドライバから制御できるようなので、そこは今後といったところ。
本体にパネルがないのでトラブったときが心配だけれども、とりあえず生きてさえいればブラウザからIPアドレス直打ちで設定・確認できるようなので大丈夫だろうか。
2013/10/17(木)機器入れ替え
2013/10/17 10:43
メモだけ。
■カラーインクジェットプリンタ
HP DJ-955C → Brother DCP-J552N
基本年賀状+イラスト・原稿の出力確認。ほぼ普通紙専用。
DJ-955Cはメカニックは未だにしっかりしているのだが、さすがに古くなってきたし、フチなし印刷がないのが不満だった。
出来るだけ長期間使用しなくてもインク詰まりのない、使いたいときにすぐ使えて、普通紙にそこそこ印刷品質が出るものを調査。
店頭確認したらBrotherの印刷結果が比較的良好だったので、同等程度以上の使い勝手を確保できるだろうと見込んでこれに入れ替えた。
・Epson機はインクの容量・クリーニング時の消費がすごいらしいのでパス。
・(最近の)Canon機は印刷実行から待ちが長い(しょっちゅうクリーニングする?)らしいのでパス。
・HPはあまりに印刷品質が進化してなかった感じだったのでパス。(業務機はそうでもないかも?)
業務機とか色々選択肢あって難しいね。
■モノクロレーザープリンタ
NEC MultiWriter 2350N → Brother HL-5450DN
元々6k位で買ったものだし、ピックアップが怪しくトナーも切れてきたので入れ替えを決断。
A3はほとんど使わなかったので除外。コンパクト・高速かつ、可能ならモノクロでグレースケールが綺麗に出せるものものがほしい。A4両面は必須。
Brotherのグレースケールが良好とのことで、店頭調査。対抗機種のHL-2270DWはコンパクトかつ無線LANがついて値段も安いのだが、印刷品質、特にグレースケールの表現は1200dpi時の5450DNが優る感じだった。消費電力がちと心配だが5450DNに決定。
■サブモニタ
Dell 2001FP → Dell P1914S
2001FPの焼き付き問題が酷くなってきたので入れ替え。
2001FPの焼き付き問題は、複数台で経験したので少なくともロットレベルでこの機種に共通っぽい。それこそ半日~1日レベルでかなりはっきりと見える焼き付きのような輝度差が残る。しばらくすると戻ることもあるのだが、なかなかに不快だった。
このモニタは資料やBGV表示用途なのでピボットは欲しく画面サイズは小さくて良い。
軽量で取り回しがしやすく狭額で、入力端子種類が多く、画角が広く確保できる(IPS/VA系)ものが欲しい。非光沢であるのは大前提。極力低消費電力であると良い。
探したらほとんど選択肢がなかった。正直あんまりDellから買いたくないのだが、消去法でP1914Sに決定。
モニタは今過渡期で、タブレット用などとPC用での乖離が大きくなってしまっている。多分2~3年内に落ち着いてきそうではあるので、それまでのつなぎ。
■サーバ
Compaq nx6110 → Panasonic Let's Note CF-T8(EC6AAS)
サーバにガタが来はじめていたので、入れ替え。
低価格、速度UP、メモリ容量UP、良保守性、コンパクトなものないかなーと思って探していたらCF-T8という選択肢があった。Intel Gigabit EthernetもOK。中古だと激安。うはー。
これはピタリとした一手だったと思う。ノイズ・発熱も今のところは減ったかな。
2013/10/09(水)Windows時刻同期メモ
2013/10/09 17:49
Windows7/XPで、NTPサーバと時刻同期させている(つもり)がずれていることが頻繁にある。
Windowsの標準時刻同期サービスは設定がGUI、サービス、レジストリに分散してしまっていて大変に分かりづらい。機能実装時にActive Directoryが前提だった節もある。しばらく観察して、ずれが解消しないようならpycronやフリーウェアでの調整を考えたい。
要求1: 最低1日1回NTPサーバと同期すること
要求2: 常時、NTPサーバとの時刻ズレが5.0sec以内であること
とりあえず、設定にミスがないか確認する。
・タスクバーの時刻プロパティで"インターネット時刻サーバーと同期する"にチェックされていることを確認。
・管理ツール->サービス->Windows Timeが"開始"かつ"スタートアップの種類"が"自動(遅延実行)"になっていることを確認。
以上の状態でこれから1週間ほど調査する。調査はとりあえず、以下のコマンドで実施。
>w32tm /stripchart /computer:ntp.nict.jp /period:120
>w32tm /monitor /computers:ntp.nict.jp要求としては5.0sec以内であるが、観察期間が短いので3.0secずれたらアウトということにする。
[追記]
上記の設定だけだと、Windows7ではデフォルトの1週間同期になってしまうようだ。参考サイト等を踏まえて考えると、
・ntp.nict.jpはデフォルトサーバ設定0x9(0x1+0x8)なのでSpecialPollIntervalの等間隔同期に従う
・デフォルトのSpecialPollIntervalは604800(604800秒=1週間)
結局やりたくなかったけど、レジストリ弄るのが簡単。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient
のSpecialPollIntervalを43200(43200秒=半日)にする。これでとりあえず様子見。
ローカルポリシーでも設定できるようなので、直接レジストリ弄るのとどちらがまともなのかは今後検討することにする。
[参考]
Windowsネットワーク時刻同期の基礎とノウハウ:第1回 Windows OSにおける時刻同期サービスとNTP (3/4) - @IT