全892件 (892件中 251-300件目)
< 1 2 3 4 5 6 7 8 9 10 11 ... 18 >
暫くメインマシンの週 1 バックアップが動いていなかった。1ヵ月間バックアップが無い。Norton Ghost (中身は VPro recovery) を使用している。手動でバックアップ処理を起動すると、「ファイルの分割数が多い(999)ためエラー」になった。初めのうちは対処方法が分からなかった。web ヘルプを開くと「再インストール」のページに飛ばされる。サポート終了なのか?酷い対応だ。自力解決する。リカバリポイントを削除、バックアップファイル一つの大きさを約 4.5Gbyte にして解決。1ヵ月放置したせいでバックアップ終了まで 99 時間(点滅しているのでもっと長い?)掛ると表示される。バックアップ中はパフォーマンスが著しく低下する。日本語入力も 1 秒に 1 文字以上入力して変換すると、変換しているのだか、入力しているのだか、反応が分からなくなる。一応バックアップの優先度は下げられる。気休めだ。エラーを出力する前に、(半)自動的に解決が可能な状況だと思う。これも正しい仕様、使えない機能か。
2014.06.08
コメント(0)
outlook 2007 でメールが未読のまま変わらず、削除しようとしても削除できず、移動もできない。他のプログラムで pst ファイルを操作しているから、再起動をする様にと促される。例の「お役に立ちましたか?」が「再起動」を促すダイアログに出てくる。何度も再起動をした。改善しない。PST ファイルが壊れたのだろう。scanpst を使うことにした。3 時間程修復に時間を要した。修復後は普通に使える様になった。「お役に立ちましたか?」は「別の正解が有る」というヒントだ。
2014.06.05
コメント(0)
PC の電力消費量削減を進めた。家全体で去年の 4 月は 436kWh 消費したのに対し、今年 4 月は 287kWh の消費だった。サーバー運用 PC を消費電力が小さいものへ置き換えた。サブ PC 群の運用見直しを実施した。殆どサブ PC に電気を入れなくても困らない様に機能をサーバー運用 PC の仮想マシンに寄せた。メイン PC も積極的に休止状態に入れる様にした。USB VBUS を全て +5VSB から供給して休止に入った直後に再び再開してしまう問題を解消した。加えて積極的に休止状態に入るスクリプトを常時動作させるようにした。(詳細な説明は申し訳ないけれど省略する)cygwin 上で スクリプトを走らせ Windows の休止・スリープ機能に比べより積極的に休止状態に入る様にした。このスクリプトはプロセスの状態をCommand Line Process Viewer/Killer/Suspenderにて取得する。休止しては困るプロセスが実行されていないか監視するためだ。スクリプトでマウス移動も調べる。現在のマウス座標を調べるコンソールアプリ(Delphi Source と EXE)を作って、マウス移動が有る場合は休止しない様にした。sleepping.d 以下に有る複数の副スクリプトで特定のディレクトリ以下の更新状態を監視する。magicTV の録画・番組表更新監視、VPro Recovery (Norton Ghost) の増分バックアップ活動監視をする。活動中は休止状態に入らない様にする。監視した結果「何もしていない」と判断したら hibernate.bat で休止状態に入る様にした。スクリプトを展開して他で使えそうなのは hibernate.bat と standby.bat だろう。それぞれ休止状態、スタンバイ(スリープ)状態に入るバッチファイルだ。おおよそ 3,000 円程電気代を削減できている。
2014.04.30
コメント(0)
新人のコードを背中から覗き込む。随分とすっきりとしていた。良く見てみると中かっこ { } の近辺に見慣れないマーカーが表示されている。「随分とすっきりとしているなぁ」と声を掛けたら、マーカーをクリックして「いゃ」と答えた。コードが折り畳まれていた。20 行ほどに畳まれていたコードは 100 行ほどだった。「エディタで見てスッキリと言うのはいいのかなぁ。」と、悩んでしまう。まぁ、良くないよな。実現したい事を分割して、組み上げる力は多分つかない。かと言って全体を記憶し、一気に実装できるような見通しが立てられるほどの実力は無さそうだし。え?ググればコードが見つかるから、書き方は拘る所じゃないって?
2014.04.17
コメント(0)
隣の人はスマホゲームを良くしている。どう見ても 2 次元(アニメかイラスト)を強く意識してデザインされた平面的なキャラクターが 3D, HD, 60fps で動くゲームなったそうなのだ。スマホゲームはお手軽開発が売りじゃなかったのか?あっ、自分が身を置いているハードメーカーが煽っているのか、3D アクセラレータ、full HD 越えの解像度ディスプレイ、4 core 当たり前、高容量電池。
2014.04.16
コメント(0)
商用電源監視サーバーを 22:05 頃に再起動した。原因は分かっていない。きっかけは分かっている。21:31 頃に USB hub と FT-232 を使用した USB serial converter を接続した事だ。Configured state に遷移すると光るはずの USB hub の LED が点灯しないことで気付いた。監視記録は SSD の USB storage に保存している。dmesg を見ると接続したあたりで USB storage が切断された後に続けて EXT4 file system の Journal 書き出し失敗まで即時に進展している。Apr 14 21:31:29 blackflat kernel: [8073125.112864] usb 2-2: USB disconnect, address 3Apr 14 21:31:29 blackflat kernel: [8073125.113641] JBD2: Detected IO errors while flushing file data on sdc1-8Apr 14 21:31:29 blackflat kernel: [8073125.113704] Aborting journal on device sdc1-8.Apr 14 21:31:29 blackflat kernel: [8073125.113724] EXT4-fs error (device sdc1) in ext4_reserve_inode_write: Journal has abortedApr 14 21:31:29 blackflat kernel: [8073125.113736] EXT4-fs (sdc1): previous I/O error to superblock detectedApr 14 21:31:29 blackflat kernel: [8073125.113763] JBD2: I/O error detected when updating journal superblock for sdc1-8.Apr 14 21:31:29 blackflat kernel: [8073125.113800] EXT4-fs error (device sdc1) in ext4_dirty_inode: Journal has aborted複数ポートで共有している自己復帰ヒューズが切れてしまったか。SSD USB storage + HUB + Serial converter だとしてもそれ程重い負荷では無いはず。ところで Serial converter に繋がっている先の物?
2014.04.14
コメント(0)
PC が休止状態に入れない問題は VBUS を +5VSB に接続して解決した。一部のポートだけ VBUS を +5VSB に接続していたのを失念していた。USB の接続を変えた時に問題を起こすデバイスを VBUS が +5V に接続されている系統に繋いでいた。全ての VBUS を +5VSB から供給すると電力不足になる可能性が有る。+5VSB は補助電源から電力注入している。電力注入の回路はまだ改良の余地ある。ようやく自動的に休止状態に入る処理を実装できる様になった。
2014.04.07
コメント(0)
4 月から消費税増税となる。電気料金も上がる。5 月徴収分からだ。メイン PC の消費電力は常時 110W 有り大きい。この PC の省電力化対策が済んでいない。Windows Vista PC なので電源の管理でコンピュータをスリープ状態にする設定をしている。45 分後に設定している。今までこの設定が有効に働いた事は無い。家に帰ればいつも PC は ON 状態だ。どうして設定が働かないのか色々と調べても原因不明だ。デバイス、タスク・マネージャー、BIOS 設定、組み合わせも膨大だ。How To Put the System into hibernation or Standby from Run menu Shortcuts to Restart, Hibernate, Standby or Shutdown Your Computer 等を見てコマンドラインを入力すると一応それらしい動作を始める。最後の最後になって on 状態に復帰してしまう。(2014.4.8 追記 解決の方策が見つかる VBUS を +5VSB に接続上手く行けば電気代は今の 6 ~ 7 割程度になるはず。
2014.03.31
コメント(0)
秋葉原でも Windows XP サポート切れを予告する看板が目立つようになった。Windows 7/8 マシンに買い換えるかアップグレードするため周辺機器の対応状況を聞く人も多い。聞いていると「古いプリンタは対応しているのだろうか?」という何とも返事に困る質問だ。正確に診断するためには Windows 7 Upgrade Advisor , Windows 8 アップグレード アシスタント を使う。おおよその見積もりは Windows 7 対応なら 2009/9 以降発売の製品かどうか、Windows 8 対応なら 2012/8 以降発売のの製品かどうかだ。メーカーは 半年前程度から preview 版を使ってテストを開始しているので、恐らくはもう少し古くても対応している。突然使えなくなる訳でもないので、秋葉原界隈の切迫感は今一つな感は有る。既に移行した人も多いはず。具体的な問題はサポート切れの後でしか分からない。最悪の場合は全世界に未確認だった脆弱性をつくウイルスやボットプログラムが Windows Xp PC に広がり、あらゆる情報が流れだしてしまうことだ。多くのユーザーが少し用心深ければ 1, 2 年は何事も無いだろう。怪しいサイト、メール、文書、画像を開かない。複数のサイトでパスワード共有しない。あるいは、重要度に応じて使い分けをする。Windows Xp を使いつづけるために 100 以上の厳守事項を挙げれば切迫感が増すのかもしれない。Start ボタンの上にスクロールしながら常に表示し続ければきっと...
2014.03.16
コメント(0)
新人が書いたコードを少し読んでみる。追いずらい。おおよその原因は共通部分式とループ内不変式をコピー・ペーストで何行も繰り返して書いていることだ。そんなのはコンパイラが最適化してくれるのでは?という意見や指向は有るだろう。自分は手で括りだして最適化して欲しい。ちりばめられた共通部分式とループ内不変式の一つ一つが正しいか確認するのは勘弁だ。括りだした式が正しいか 1 度確認すれば以降正しいと確認でき、より多くの部分にコードの正しさを確認する思考を巡らせることができる。新人に手で最適化しないのは何故かと聞いてみる。特に方針や意思も無くコピペをしたとの返事。うーん、何も考えていないし理解していないのかなぁ。教科書に載る様な良く考えられたアルゴリズムの多くは、注意深く規則性を見い出して作られたものが多い。繰り返して現れる構造や、処理過程で不変で有ったり、条件を維持し続けていることを巧みに利用している。式の括りだしは高度なアルゴリズムの理解や開発にで必要な基礎力だと思う。新人、もう勉強に専念する時間も、ソースの探求にふける時間も無くなったのだよ。
2014.02.26
コメント(0)
新人よりコードの実装方法についての質問が有った。やりたい事を一通り聞いてみる。彼の直近の記憶や作業で似た様な経験は無いだろうかと思いを巡らせる。前日にコードレビューした所が近い事を実現していた。「昨日レビューした所にヒントになる実装が有るよ」と返事をする。キョトンとしていた。断片的な差分レビューだったので全体を把握していなかったのか。色々と思う。レビューしても殆どの参加者はプロジェクターに示される僅か 100 行程度で差分の前後のコードしか見ないし、理解しようとしない。背景にある複雑な事情や基本的な構造に注意や興味はむけない。そうすると、レビューの意味合いは gcc -Wall + α程度だ。最近の新人は学校の勉強の延長で仕事をしているのだろうか?黒板に示されたことだけを把握していれば良く、それがその後で試されること(学校で言う所の試験)だと認識しているのだろうか?自分の職場はそれでは仕事にならない。示されたコード量の 10~20 倍程度のコードを読み、仕様を把握しないとそのうちについて行けなくなる。大変な所に来てしまった様だな。
2014.02.06
コメント(0)
I-O DATA の MagicTV GT はたまに録画失敗してしまう。録画失敗をしそうな条件を C:\Users\furuta\AppData\Roaming\I-O DATA\mAgicTV\TVManager ログから判定できないか状況収集している。次の図の様に録画環境は複雑だ。USB redirector を使用して GV-MVP/XZ3 を Ethernet 越しに使っている。録画保存先は Linux File server だ。GV-MVP/XZ3 は HUB を介して接続、途中 command line で制御可能で物理的に USB bus を接続・切断する USB switcher が入っている。接続・切断は USB redirector の機能でも行っている。恐らく Bus reset control request だろう。cygwin, Command Line Process Viewer/Killer/Suspender, USB redirector の command line tool を使って監視用のスクリプト(bash script, windows bat file)をタスクスケジューラより起動して運用している。録画失敗をしそうな条件は mtvCheckHang.sh スクリプトで判定している。まだ全ては捉えきれていない。次の様な事象が有った。録画終了しない'mAgicマネージャ GT の起動処理が完了しない録画モードを開始出来ないEPG 更新でタイムアウトB-CAS カードが OFF のままLive モード移行に失敗B-CAS カードが認識できなくなった場合はログに残らない様だ。これは B-CAS カード OFF とは違う事象だ。プロセスに ping の様なものを打てれば良いのだけど、適当に WM_xx なのかなぁ。
2014.01.25
コメント(0)
退役した Maxror 6L300R0 を再使用して不調になったので別のドライブを探すことにした。もう 1 台 6L300R0 が有ったので使うことにする。同じ事をしているのだから、同じ現象が発生する事が考えられる。使用開始からもうすぐ 2 日目、変わった兆候はない。壊れた 6L300R0 は調査を開始した。不良ブロックスキャンはまだ途中だ。スキャンは低速だ。Linux Kernel の ATA(IDE) ドライバはエラーが有ると転送モードを PIO にする。低速になり CPU 負荷も高くなる。1 文字の入力に 10 秒以上かかる高負荷だ。不良ブロックはいくつかの部分的な範囲に分布している。引っ掻きに見える。他に何か有りそうな感もある。うーん、今は Windows Vista のテスト環境で評価する作業のはず、壊れたハードディスクを増やす作業じゃないよな。
2014.01.17
コメント(0)
Windows Vista テスト環境を構築するため、長らく休眠していた Maxtor 6L300R0 を使うことにした。PATA 接続の HDD なのでわざわざ SATA 接続に変換して使用した。2 日間は順調に動作していた。3 日目から不調になった。不良ブロックができているらしい。退役させた時は故障していない。不良ブロックパターンは取れていない。何かの拍子に傷をつけたのか、斑に不良個所が広がっているのか、デブリが発生して広範囲に傷ができたのか。製造日は 2006/5/29 なので 7 年経っている。7 年間動き続けている個体も有る様に思う。MTTF はデータシートより 1,000,000、 稼働時間は 24*365*8=70,080 なので MTTF より一桁小さい。保証期間は 5 年、保証期間切れだ。ハードディスクは揮発性メモリなのか?
2014.01.14
コメント(0)
実家のモニタを EV2436W-Z(GY) に交換した。元は Windows XP パソコン付属の 1024x768 のモニタだ。パソコンも置き換える予定だ。Windows XP で使用するのは後 2 週間ほど。その間だけ大型モニタの利点を生かすため、文字を大きくする設定をして使うことにする。父母とも高齢だ。小さい字は見にくい。頭の中では Windows Vista/7 の様に文字はスケーラブルでアンチエリアシングされたメニュー、タイトルバー、ウインドウ領域の表示になるつもりだった。いざ設定してみると、ビットマップフォントで読みにくい。Windows XP なのだ。PC を置き換える選択をして正解だった。PC が出せる最高解像度は 1600x1200 なので EV2436W の 1920x1200 は生かせない。広い方が使いやすい。PC 来るまでに自分の体調が良くなればなぁ。
2014.01.12
コメント(0)
実家に Windows XP PC がある。サポート切れになって、即使用不能というわけではない。ぼちぼち更新後をどうするか検討を始める。色々と訳あって、小さなデスクトップにしようと思っている。適当なメーカーのサイトに行ってカスタムメードで構成を始める。いつの間にか 15 万円を超えている。どうしたものか。強気値段で設定している感は有る。Windows 8.1 も自分の所で評価を始めている。2 日弄って、Windows 7 を選択する方針にする。更新しようとする周囲の PC が Windows 7 なのと、8.1 の UI に問題を感じるところが多い。Widows 8.1 UI に感じる問題は、・何処が空間的・時間的反応領域なのか分からない。・単色デザインかつ、単純化され過ぎた記号情報の解釈に時間が掛かりすぎる(あるいは意味を汲み取れない)。・上記に対比してアプリケーションのリボン UI は操作を詰め込み過ぎていて、煩雑・雑多・操作位置粒度が細かい。・設定画面などいくつかの画面は戻り方が良く分からなくなる(タッチだと分かるという話も聞く。マウス操作で使うことを考えている)。・スタート画面の右端に見えない Application icon ができる(画面はより多くの情報が表示できるのに、隙間を生かさず表示を切ってしまう)。悩んだ挙句、そのまま upgrade という結論になるのかなぁ。
2014.01.07
コメント(0)
故障した WD10PTVTを再使用してみた。不良ブロックを避けパーティションを切り直した。問題なくアクセスできるはずのつもりだった。結果は更に悪化、大量かつ高頻度のエラーが発生した。不良ブロックマップ(PDF)を再作成した。前回の不良ブロック調査時有った不良ブロックは消えていた。代りに広域に不良ブロックが広がっている。前回は調査ミスだったのか、それとも交代処理が行われて消えたのか。分布からすると、不良ブロックを避けて使用するのは絶望的だと思われる。円周状の引っかき傷、内縁-外縁方向の引っかき傷、細かなゴミが散乱し、さらなる不良ブロックを作っていそうな状況の様に見える。本当にパーティクルが原因なの?内周が綺麗なのは?ヘッドの空力に問題?
2014.01.05
コメント(0)
そろそろ systemd を始めとする新しい仕掛けから逃げることが出来そうもないので Fedora 20 で試しにファイル共有が出来る程度に samba server を仕立ててみることにした。色々と試行しているので、余計な手順があるかもしれない。インストールはいつもの通り。# yum install sambaFirewall に穴開け。# firewall-cmd --permanent --add-service=samba --add-service=samba-client/etc/samba/smb.conf を編集、workgroup と hosts allow を編集するくらいで取り敢えず繋がるはず。自分の local network では workgroup は HOME、サブネットアドレスは 192.168.0.0/24 なので次の通り。workgroup = HOMEhosts allow = 127. 192.168.0.systemd に自動起動登録して今から使える様に起動する。# systemctl enable smb# systemctl enable nmb# systemctl start smb# systemctl start nmbsamba ログインアカウント user_name を追加する。# smbpasswd -a user_nameここまですると、Fedora 20 のマシン名が Windows エクスプローラから見えるはず。ただし、/home/user_name ディレクトリにアクセスしようとすると、「アクセスが拒否されました」と表示される。どうも SElinux が関係しているらしい。次の様にしてアクセスを許可する。アクセス制御状態を確認する。# ls -ldZ /home/user_namesamba がアクセスできる様にする。# chcon -R -t samba_share_t /home/user_nameここまでくるとアクセスできるようになる。シンボリックリンクがアクセスできない問題は、ネットを検索すると出てくるので割愛。winbind を使って NetBIOS 名を解決できるようしておく。インストール。# yum install samba-winbind/etc/nsswitch.conf を編集、hosts に対して wins を追加、(妥当性は要検討かもしれない [NOTFOUND=return] は無くても良い気がしている)。hosts: files mdns4_minimal [NOTFOUND=return] wins dnssystemd に winbind を自動起動する様に登録、今から使えるようにする。ただし、systemctl start をしてもダメだった。原因は特に追わず、リブートして NetBIOS 名を解決できる様になった。# systemctl enable winbind.service# systemctl start winbind.servicefirewall-cmd の長い形式のオプションも bash の補完機能で補完できるのはうれしい。しかし、補完の応答が緩慢だ欲求不満が溜る。全体的に仮想マシンで動かしているせいなのか、色々な操作で一呼吸分遅い。他の仮想マシンで同様に感じることは無い。ここまでセットアップして、従来からコマンド入力が楽になったのは firewall-cmd くらいか。進歩性をイマイチ感じない。何だろう、Fedora 20 を使ってみて、開発者が心の底から喜んで作っていると感じない。誰かが仕様を作って、それに従って手分けして設計・実装をして、完成すればそれでおしまい。使いにくさとか、イマイチな所は仕様として表現されていないので直す動機が無い様に感じてしまう。そんなに大きい仕様が必要なんだろうか。
2013.12.29
コメント(0)
HDD ケース OWL-ESL35S/U3 をメンテナンスかファイルサーバー追加用に買う。今は緊急の案件はないものの、年末は何かと不調回復やファイル移動の作業に追われることも多い。中身はケース、ケーブル、アダプタ、ネジのセットだ。ケーブルは USB 3.0 規格に従った A-B タイプのもの、アダプタは 12V 2A 出力なので余裕がある。基板を眺めてみる。電源スイッチは仰々しく 3A 250V の物だ。直流開閉でも 3A 30V くらいは行けそうな感じだ。でも、回路を目で追うと、Pch MOS FET のゲート制御しかしていない様に見える。電源ラインにはコンデンサ 220uF 16V x 2 が入っているので AC アダプタのプラグと DCIN ジャックのガリによる不調は起きにくくなっている。HDD コネクタは手付けの様だ。半田の盛り上がりがマチマチになっている。仕上がりはまぁまぁ。フラックスと半田ボールの残りが見える。ショート防止のため、これらを除去して使う予定。備えはしたけれど結局年末は何も起きないよね、きっと。
2013.12.22
コメント(0)
電源監視サーバーを受け持っている PC の入れ替え作業をここ 1~2 週間実施していた。記録かとぎれとぎれになっている。もし、見ている人がいたら申し訳ない。入れ替え作業後、周波数側の記録が欠落する問題が発生する。測定値採取は "P-10 テスタ" -- "FT232R を使用した USB-Serial 変換" -- "PC" という経路になっている。この USB-Serial 変換の USB 側を抜き差しすると復旧する。異常が発生する原因、異常を自動的に復旧する見通しが立たない。dmesg の内容から USB-Serial 変換の認識に問題は無い。USB パケット通信に異常が起きた記録も無い。ドライバの異常記録も無い。電圧側の構成は全く同一で異常は起きていない。倒れても、そのうちに立ち直れる様に作ったはずなんだけどなぁ...
2013.12.20
コメント(0)
家に帰ってみると Windows Vista Business 32bit PC がリブートを繰り返していた。ログオン画面が出た直後に画面が崩れ再起動している。電源を切ってハードウエアの不調を疑い、拡張カード全て、メモリ全てを挿し直し、バックアップ電池交換、復旧せず。ソフトウエアの問題を疑うことにする。セーフモードで起動できる。「ヘルプとサポート」→「セキュリティとメンテナンス」→「ファイルのバックアップを作成する」→「システムの復元とは」→「クリックして、[システムの復元]を開きます」にてシステムの復元を試す。ディスクをスキャンする必要があるとの事。エラーチェックを再起動時にする様にスケジュールして再起動。いくつかの破損ファイルが有った。同じ様にして「システムの復元」を実施、2013/12/15 の時点に復帰する様に指定した。以下の update が無かったことになったはず。どれが問題なのかは調べていない。MS13-097 KB28987854.5.1、.NET Framework KB2858725MS13-101 KB2887069MS13-099 KB2892075MS13-098 KB2893294MS13-101 KB2893984MS13-096 KB2901674KB890830MS13-096 KB2817641MS13-106 KB2850022KB2850085再起動後、USB redirector client がおかしいことに気付く、USB redirector の server に接続し、server が共有している USB デバイスに接続するとリブートしてしまう。システムの復元で完全に戻っていない可能性が高い。お蔵入りになっていた USB device server IODATA ETG-DS/US-HS で代替復旧する。問題波及範囲が広すぎる。昨日まで使えていたのに。
2013.12.16
コメント(0)
録画サーバーの試験運転で「考えるカラス」という NHK E テレ番組を録画した。試験運転結果を確認するため録画した番組を見る。番組の中で「観察する」、「仮説をたてる」、「実験してみる」、「考察をする」と科学の考え方を教えている。最近の若い社員を見ているとこの考え方が足りない。4 つの工程が 3 つになっているのではい。4 つの工程では足りないのだ。「仮説をたてる」という所が「仮説を立てるだけで終わってしまう」のが問題の様に感じる。仮説であるならば、実験をする前に計算する。あるいはシミュレーションする。仮説は計算に耐える必要があるし、計算の結果が実験結果の解釈に十分な(言いかえれば比較し差分を計算するのに十分な)情報を持っている必要がある。何か楽しそうにインターネットで検索して、どんな結果になるかも考えずにコード実装して、「違うなー」と言っている。結果を考えなければ何時まで経っても目的は達成できない。結果を考える地味な作業は嫌いなのだろうか?「仮説をたてる」という楽しい作業を続けたいだけ?それでは仕事は進まない。
2013.11.26
コメント(0)
ECS KBN-I/5200 で構築した Linux マシンを本番運用に投入した。仮想マシンも配架し、Linux 3, Windows7 x 1 を抱えている。レスポンスはこの状態でも良い。旧マシン Athlon X2 4850e 2.5GHz 2 core から A6-5200 2.0GHz 4 core に乗り換えた結果は満足がいくものだった。消費電力は 1/3、Windows7 仮想マシンを 1 台増加、不満があったレスポンスは向上した。退役した旧マシン設定を変更し、サーバー設定と機能を停止させた。清掃して再び電源を入れてみる。ギーギーとファンから音がした。故障寸前だった。旧マシンに掛ける言葉は「これからもよろしく」ではなく、「お疲れ様」だった。
2013.11.17
コメント(0)
2013.11.9 追記 Fedora 14 をインストールした記録(オンボードネットワークが繋がらない対策、グラフィック画面が出ない対策)ECS KBN-I/5200 を Fedora 14 x86_64 で試運転している。構成は Memory 8Gbyte, 1Tbyte HDD x 2, Keyboard, Mouse, 1000BaseT, ディスプレイドライバを AMD 製に差し替えている (dmesg 等の詳細)。ファンは下の画像の様に Kaze-jyu Slim 2000rpm 10cm 角 SY1012SL12M に換えてある。この状態でスクリーンセーバーが働き、画面が消えるアイドル時の消費電力は 10W ~ 13W だった。ファンの周りは風通しが悪そうなほどゴチャゴチャしている。この状態でファンは時々停止している。十分に冷えていると思われる。ヒートシンクに触っても熱くない。HDD にアクセスしない時は積極的にスピンダウンするinit スクリプトを使っている。スピンが止まると 1W 程違う。え?新サーバーばかり構っていると現役サーバーが調子悪くなるって?
2013.11.07
コメント(0)
KBN-I/5200 を購入してから 2 ヵ月、ハードウエアのトラブルはなく動き続けている。安定運用の目処がたったので ECS KBN-I/5200 に Fedora 14 x86_64 をインストールする手順をまとめていた。KBN-I/5200 は少し古い Linux だと、オンボードネットワークコントローラ RTL8111E を認識しないか、認識しても接続確立しない。グラフィック出力が出ない。といった問題が有る。こういった問題を解消する手順をまとめた。Fedora 14 はサポートが終わってしまったため、今後の面倒は自力で何とかする必要がある。その点を差し置いても System V init, Gnome 2 であることの魅力は大きい。systemctl に移行しようと Fedora 19 を試しに使ってみた。結果、自分の結論は「まだ使えない」だった。Fedora 15 から時間は経っているはずなのに中途な所が多い。理想を追ったのは解る。時間を掛けても完成を見ないのは何処か無理があるのか、時間の経過とともに設計に歪みが出てきたか。KBN-I/5200 は家内サーバー運用投入作業へ移る。
2013.11.03
コメント(0)
pcDuino を安定化させる作業をまとめたページを作成した。ページ内容よりも公開リポジトリ作成、もう一つの方法としての差分作成に時間を費やす。linux kernel, u-boot に修正を加えた。全体的にクロック周波数を低くし、Ethernet, Micro SD のデータ転送を PIO 化した。一部は過剰な修正かもしれない。様子をみて高速化を図る余地はある。修正後は pcDuino は順調に動き続けている。1 週間ほどの間、帰宅後マウスを動かすと ブランクスクリーンより復帰し GUI の desktop が表示され入力を受け付ける。git repository を clone してもエラーは発生しない。USB メモリも普通に使えている。pcDuino の本領である Arduino 互換機能は使えなくなった。互換機能を提供する kernel module のソースが見当たらない。再コンパイルできないからだ。.ko だけ元の root file system image からコピーして depmod -qa すれば機能を維持できるかもしれない。そこまで試していない。自分は kernel driver から書くか既存 driver を加えるだけのつもりなので、Arduino 互換機維持の動機が弱い。うん、使える様になった。で、何を繋げるつもりだったんだっけ?関連ページ秋月で pcDuino を買ってみる(購入記録)電源ボタン追加CPU 600MHz、SD card bus 24MHz にしてクロックを落としてみる(作業記録)Ether, SDIO を PIO 化、MALI を 240MHz にダウン(作業記録)pcDuino sdram_pll を 816MHz から 720MHz へ(作業記録)パッチ整理(作業記録)
2013.10.16
コメント(0)
2013.10.17 追記: pcDuino を安定化させる作業をまとめましたpcDuino 安定化作業を継続している。日曜のうちに終わらせようと思ったが難航している。git でリビジョン管理をしているにもかかわらず make の途中でソースにパッチを当てる処理が走っている。パッチを当てるというよりはファイルを丸々差し替えてしまう。普通の git の使い方であれば 特定ターゲットの branch を checkout するのが最適だと思う。クロック周波数を kernel で変更していた。これも sunxi-spl.bin(second program loader?) を生成するためのファイルと思われる sunxi-boards/sys_config/a10/pcduino.fex で制御できそうだ。興味深いエントリーは、つぎのもの。いずれも kernel で変更していたパラメータだ。boot_clock = 1008dram_clk = 408mali_clkdiv = 3簡単に変えられそう。scripts/sunxi-media-create.sh を見てみると sunxi-spl.bin と u-boot.bin の sdcard(mmc) 上のブロック位置が分かる。次のとおりらしい。sunxi-spl.bin の位置copyUbootSpl (){ dd if=$2 bs=1024 of=$1 seek=8}u-boot.bin の位置copyUboot (){ dd if=$2 bs=1024 of=$1 seek=32}一旦仕切り直しかな。2013.10.17: 関連ページを追記しました秋月で pcDuino を買ってみる(購入記録)電源ボタン追加CPU 600MHz、SD card bus 24MHz にしてクロックを落としてみる(作業記録)Ether, SDIO を PIO 化、MALI を 240MHz にダウン(作業記録)pcDuino sdram_pll を 816MHz から 720MHz へ(作業記録)pcDuino 安定化まとめ(作業記録ページ公開)
2013.10.06
コメント(0)
2013.10.17 追記: pcDuino を安定化させる作業をまとめましたpcDuino の sdram_pll (PLL5) クロック周波数を 816MHz から 720MHz に落とす。git fsck, git clone ssh://user@remote_host/repository/path/.../linux-2.6 を安定して動かせるようになった。一番効果がある修正の様だ。今まで殆ど使用不能だった USB memory も使える。定期的とも、不定期ともいえる様な間隔で発生していた USB HID mouse のエラー記録も dmesg から消えた。目処が立って来たのでソースコードの修正個所、リポジトリの有り様を整理し始める。2013.10.17: 関連ページを追記しました秋月で pcDuino を買ってみる(購入記録)電源ボタン追加CPU 600MHz、SD card bus 24MHz にしてクロックを落としてみる(作業記録)Ether, SDIO を PIO 化、MALI を 240MHz にダウン(作業記録)パッチ整理(作業記録)pcDuino 安定化まとめ(作業記録ページ公開)
2013.10.02
コメント(0)
2013.10.17 追記: pcDuino を安定化させる作業をまとめましたpcDuino の kernel ソースを弄っている。 Ether, SDIO を PIO 化する。DMA を使うコードに疑問がある。GPU の MALI は 240MHz にダウン。ハードも改修箇所が増えている。Ether phy の電源強化をした。SD カードスロットも怪しい個所があると考えている。ヒートガンで MLCC を温めてみたり...先は長そうだ。2013.10.17: 関連ページを追記しました秋月で pcDuino を買ってみる(購入記録)電源ボタン追加CPU 600MHz、SD card bus 24MHz にしてクロックを落としてみる(作業記録)pcDuino sdram_pll を 816MHz から 720MHz へ(作業記録)パッチ整理(作業記録)pcDuino 安定化まとめ(作業記録ページ公開)
2013.09.30
コメント(0)
2013.10.17 追記: pcDuino を安定化させる作業をまとめましたpcDuino の安定化作業をしている。CPU (上限)600MHz、SD card bus 24MHz にしてみる。いつの間にか暴走してしまう現象は減っている。依然として正常動作に至らない。git clone で linux kernel レポジトリを家内 server から複製できない。途中でオブジェクトの矛盾を検出して停止してしまう。小規模なプロジェクトなら成功する。PC では何の問題も無く出来る。pcDuino に問題が有ると考えられる。一部の回路のクロックを落としてみると状況は良くなる。完全解決では無い。ハード的な問題では無く、ソフト的な問題で考えた方が良いのだろうか。ドライバのレジスタアクセス手順に誤りが有るのか、DMA 転送前後の map/unmap に誤りが有るのか。あれ? BeagleBoneBlack と大して早さが変わらないじゃないかって?2013.10.17: 関連ページを追記しました秋月で pcDuino を買ってみる(購入記録)電源ボタン追加Ether, SDIO を PIO 化、MALI を 240MHz にダウン(作業記録)pcDuino sdram_pll を 816MHz から 720MHz へ(作業記録)パッチ整理(作業記録)pcDuino 安定化まとめ(作業記録ページ公開)
2013.09.25
コメント(0)
SAMSUNG SSD 840 250Gbyte 耐久試験を終了することにした。理由は試験ツールの実行が IO エラーのため Fail し始めていることだ。Round 89(549.3TiBytes 書き込み後) から Fail は始まり、暫く続けてみた。データの上書きで回復する可能性も期待した。しかし、その傾向は無い。故障しているドライブに対する試験は意義を見い出せない。試験を終了して解析する事にした。解析直前の smartctl の結果を見てみる。文字が小さいのでリンク先のテキストを見た方が良いだろう。ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 098 098 010 Pre-fail Always - 709 Power_On_Hours 0x0032 099 099 000 Old_age Always - 2347 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always - 2736179 Used_Rsvd_Blk_Cnt_Tot 0x0013 098 098 010 Pre-fail Always - 70181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0183 Runtime_Bad_Block 0x0013 098 098 010 Pre-fail Always - 70187 Reported_Uncorrect 0x0032 099 099 000 Old_age Always - 412190 Airflow_Temperature_Cel 0x0032 077 038 000 Old_age Always - 23195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 412199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0235 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 1355789298747Wear_Leveling_Count が Fail 寸前で止まっている。他の smart 値は閾値に比べほぼ「健康」な値だ。RAW_VALUE を注意して見ないと保守が必要な状況か分かり難い。不良ブロックの分布(リンク先は生データと gnuplot スクリプト)をみてみる。赤い 2 点が不良ブロック個所だ。1 点 16 ブロック含んでいる。もしかしたら、このうち数ブロックは読み取り可能かもしれない。不良ブロックは限られた場所に集中している。普通にファイルを格納している状況ならば、特定の 10 個ほどのファイルが破損するくらいで済むだろう。SAMSUNG SSD 840 250Gbyte 耐久試験の結果は次の様になった。不良ブロックが発生しても Read Only にはならず、気付かないとファイルを失うことになるSMART モニタ値の 100 分率は Fail 寸前で止まるか、異常な状況を示す程に変化しないおおよそ総容量の 2,200 ~ 2,500 倍の書き込みで不良ブロックが発生する不良ブロックが発生する前にシーケンシャル・リード性能が劣化し始める。詳細な解析が必要なのは予め断っておくことにする。見た目で Round 45(274.7TiBytes 書き込み後), Round 46(280.9TiBytes 書き込み後) 辺りから性能劣化が始まる。おおよそ総容量の 1100 ~ 1200 倍書き込んだ辺りだ。下のグラフは Round 45 より抜粋したシーケンシャル・リード性能だ。転送速度が分散しており、エラー訂正に時間がかかっている可能性をうかがわせる。SSD の開発競争はより大きく、より早く、より寿命が短く、より故障が予測困難な方向なのか?関連 blog ページリンク試験開始異常発生対応
2013.09.24
コメント(0)
Linux で運用している共有ファイルサーバーのドライブとして使用していた WDC WD10TPVT が故障してしまった。購入記録を辿ると 2011/10/8 辺りに画像が有った。別のドライブに複製を作成して、救出作業を行う。解析するとヘッドでディスクを内周-外周方向に引っ掻いた様な不良パターンだった。2 年経たずに故障してしまった。電源を入れると「カシャッ・ジージージー」と繰り返し音が出る。不良セクタ(ブロック)が出来た時の典型的な音だ。別の PC で使用するために買った WDC WD10JPVT を急遽転用し、救出先にする。総 LBA 数が 1953525168 で全く同じなのが決め手だ。sg3_utils の sg_dd に簡単なスクリプトを被せてディスク全体をコピーする。スクリプトは不良ブロックのレポートも作成する。不良ブロックデータを加工するツールを通して、gnuplot スクリプトに掛ける。不良ブロックのパターンは次の様になった。赤い点で不良ブロックを表している。この赤い点は 1 ブロックでは無い。1 点当たり数ブロックから 20数 ブロック程を含んでいる。ログをぱっと見なので 1 点のブロック数がもっと多いかもしれない。等間隔で飛び飛びになっている部分と、2 点飛び地になっている。等間隔で飛び飛びになった不良は典型的な内周-外周方向に引っ掻いた場合だ。2 点の飛び地が先に出来たのか、後にできたのかは分からない。Kernel log は詳細に解析していない。破片が飛んだ様に見える。不良ブロック分布からすると、お試し的な PC 構築に使うのも難有りか。パーティションを切るにしても、ほぼ真ん中辺り。避けると容量半分のパーティション x 2になる。破片拡散で不良拡大の傾向有り。複製が完了した WD10JPVT に対して fsck を実施、壊れたファイルシステム情報を修復して、ファイルサーバーの運用を復旧する。いくつかのファイルは失われた。とのファイルを失ったのかなぁ。分からない。
2013.09.23
コメント(0)
ハードディスクを移し替える作業が終了した。途中のトラブルはディスプレイに物をぶつけてしまったことだった。Antec Solo ケースを開けて部品を弄りだした時だ。ただ掛けてあるだけの扉の様なハードディスクの吸気口が外れた。幸い 2~3mm の差で枠に当たり表示面に傷は付かなかった。直ぐに対策する。不意に外れない様にワイヤーで吊る。鋭利な吸気口フレームのエッジをテープで覆う。移し替えの後、いくつかのフォルダーが Windows フォトギャラリーで管理でくなくなった。フォルダーが存在するのに見つからない旨のエラーが出る。「ギャラリーから削除」(ギャラリーからが重要だ、でないと本当に消えてしまう)をして再登録し直す。理由は不明、復旧したので深く追わないことにする。容量は 698Gibyte から 1.81Tbyte になった。3 倍弱の広さ、いつまで持つか。
2013.09.14
コメント(0)
データ用のハードディスクの空きが少なくなってきた。全容量 698Gibyte に対して 66Gibyte だ。残り 1 割を切ると色々と遅くなってくる。要らないファイルを削除したり、不要不急のファイルを移すのは既に諦めている。何回かやった経験から 5% も削減できないのに 1 週間以上の時間を使ってしまう。バックアップを取ってから、と思っていたら定期バックアップをしている Norton Ghost から「リカバリポイントを削除せよ」と警告が出てきた。面倒なことは重なるものだ。指示に従って削除したら、過去全てのリカバリポイントが消えた。「おいおい、全ては困る」。2 重バックアップ確保、定期作業予定調整、色々と悩ましい。あっ、ブログもサボりか。
2013.09.13
コメント(0)
SAMSUNG SSD 840 250Gbyte 耐久試験のプロットが停止していたので、異常の状況を点検して再開した。結果、耐久試験は続行していた。グラフをプロットするサーバーが再起動し、その後プロット処理を再開していなかったのが問題だった。耐久試験は続行していたものの、試験が Fail している。dmesg の結果を見ると、read error が散発的に発生している。dmesg の kernel 時刻を eth1 を down/up させて現在時刻と突き合わせてみる(何らかのモジュールを insmod, rmmod するか、コンソールの面前ならば USB メモリを抜き差しして dmesg に記録を付ける方法がスマートそうだ)。おおよそ 1 週間前に現象が出始めている。ログに記録された Fail と時期は一致する。smartctlの結果を見ると Reallocated_Sector_Ct が 22 に増えていた。何故か、試験継続をしている最中に 21 に減っている。障害が起きても、read only にはならず試験は続行している。Fail も継続して発生している。「たまたま」の障害ではなく継続使用に問題がある障害が発生しつづけ、深刻化している可能性が有る。依然として SMART report は fail していない。SMART report を良く見ると RAW_VALUE は増えている一方で百分率表示は Fail 閾値の手前でカウントストップしている。177 Wear_Leveling_Count は特にその傾向が有る。Round 47で百分率表示は 1 になる。その後の Round 48 から全く減らなくなる。SMART 表示があてにならない。前の blog壊れた SSD SAMSUNG 470 128GBytes 解析で故障した場合、広範囲に read 障害が分布していたことが分かった。この様に障害が取り返しがつかなくなるまで進んでしまうのは、SMART では故障傾向が掴めず、dmesg に障害記録が残っても継続使用できてしまい、事情を知らなければ障害回復に成功したと思いこんでしまう危険が有ったためだと改めて認識した。全容量の 2440 倍の書き込み(Round 89)で障害発生、寿命が短い様な。関連 blog ページリンク(2013.9.25 追記)試験開始試験終了
2013.09.11
コメント(0)
cygwin 64bit 版 setup-x86_64.exe を試す。ミラーサイトの日付を見ると、2013/03 の頃から有った模様だ。ダウロードとインストールをする。手順は今までの setup.exe と変わらず。途中 64bit 版であると意識することは無かった。早速ネイティブなバイナリはどの様になるか試す。sizeof(long)=8, sizeof(void*)=8, sizeof(int)=4 となった。Linux x86_64 と同様である。バイナリも x86_64 だった。以下はコンソールの記録。furuta@whitenine ~/work/testgcc$ cat lpi.c#include <stdio.h>int main(void){ printf("s(L)=%lu, s(p)=%lu, s(i)=%lu\n", sizeof(long), sizeof(void*), sizeof(int) ); return 0;}furuta@whitenine ~/work/testgcc$ gcc -O2 -Wall -o lpi.exe lpi.cfuruta@whitenine ~/work/testgcc$ ./lpi.exes(L)=8, s(p)=8, s(i)=4furuta@whitenine ~/work/testgcc$ file ./lpi.exe./lpi.exe: PE32+ executable (console) x86-64, for MS Windows$ objdump.exe -d lpi.exefuruta@whitenine ~/work/testgcc$ objdump.exe -d lpi.exe-- 省略 --00000001004016d0 <main>: 1004016d0: 48 83 ec 28 sub $0x28,%rsp 1004016d4: e8 57 fa ff ff callq 100401130 <__main> 1004016d9: 48 8d 0d 50 19 00 00 lea 0x1950(%rip),%rcx # 100403030 <.rdata> 1004016e0: 41 b9 04 00 00 00 mov $0x4,%r9d 1004016e6: 41 b8 08 00 00 00 mov $0x8,%r8d 1004016ec: ba 08 00 00 00 mov $0x8,%edx 1004016f1: e8 4a fa ff ff callq 100401140 <printf> 1004016f6: 31 c0 xor %eax,%eax 1004016f8: 48 83 c4 28 add $0x28,%rsp 1004016fc: c3 retq 1004016fd: 90 nop 1004016fe: 90 nop 1004016ff: 90 nop-- 省略 --WOW64 を挟まないので、ちょっとした奇妙な動きとかは解消されるかも。
2013.07.27
コメント(0)
cygwinのページを見ると、いつもの setup.exe ではなく、setup-x86.exe と setup-x86_64.exe がある。説明を見るとそれぞれ 32bit インストール版, 64bit インストール版とある。まだ 64bit 版を試していない。64bit ネイティブなコードになったのだろうか?
2013.07.24
コメント(0)
00:50 に帰宅、問題報告を調査して遅くなる。調べる程、協調が取れていない回路が原因だと分かる。片や保護回路が動作しているのに、もう一方では動作の確定信号が出ている。全ての信号が見えてれば何とか対処の方法も有る。しかし、制御をした途端に見えなくなる。規格に照らし合わせ、どう考えても動作しない条件なのに動作可能だと信号を出す回路も有る。そんな回路群のドライバを書いている。回路図を見ると寄せ集め回路だ。図面の殆どは四角い IC の箱と配線だ。挙句、何でドライバが変な動きをするのと聞かれる。説明に 1 時間、疲れていて感情の起伏は無く淡々と説明する。しかも、総ソース量は 250Kbyte を超えるものに対して説明資料をと迫られる。つい 2 週間前まで不具合対策の追加指示が有ったばかりだ。まともな設計は?と自分に聞かれる。1000 万円クラスのオシロがゴロゴロしている所で仕事をしているハードウエア設計の人からだ。問題は 3,000 円でホームセンターで売っているテスタ 1 個で十分に分かる。正直腹立たしいを超えて虚しい。上流設計とか、企画・コンセプト重視とか、アイディア重視とか、ビジネスモデル重視とか、カッコいいことばかり聞える勤め先だけれど、寄せ集めも出来なくなったのか。
2013.07.19
コメント(0)
2013.9.25 追記: 連続アクセステスト(耐久試験)を終了しましたSAMSUNG SSD 840 Series 250Gbyte の連続アクセステスト(テストマシン仕様)を開始した。PRO が付かない普及品だ。5 Round 回ったところで安定してきたので公開を始めようと思う。Round 4 と Round 5 の間に 1 Round 分データを失っている。操作誤りで消してしまった。ほぼ 3~6TiBytes の書き込み分の記録が抜けたことになる。興味深いプロットを拾ってみる。(1) Round 4, "TestFlow: Try #2 of Sequential write - Random read/write with O_DIRECT - Sequential read", "Sequential write" の記録を見てみる。書き込み速度は初速と突発的なピークを除いて 50M ~ 250M bytes/sec の範囲で変動している。(2) キャッシュサイズは 16Mibytes か? SAMSUNG のデータシートに具体的なキャッシュサイズの記述は無い。一部のサイトで分解結果を元に 512Mbytes (128M x 32bit) としている。しかし、手元の測定結果は 512Mbyte という説を説明できない。O_DIRECT を付けた random write 性能 ("TestFlow: Try #2 of Sequential write - Random read/write with O_DIRECT - Sequential read") を見ると、書き込み長 16Mibytes 辺りまで転送速度が 500Mbytes/sec に達し、より長い転送長で下がる。16Mibytes の書き込みキャッシュがあると考えれば容易に説明できる結果だ。キャッシュについては 東芝の SSD の様に明確なキャッシュ構造が性能に現れない機種が有ることも留意する必要がある。おそらく、キャッシュという概念は無い。対 host の read/write buffer から wear-leveling, scribing と言ったハウスキーピングまで統合管理し、ピーク性能は少し犠牲にしつつも、あらゆる負荷状況で性能を出す構造になっていると思われる。1 Round 分のデータを失った事故も、興味深い結果になっている。事故直後、Round 5 の最初のシーケンシャルライト性能がほぼ 260Mbytes/sec 付近で安定している。事故発生時、20~30分程アクセスが殆ど無かった時間が存在した。この時間の間に、scribing をやっていたのだろうか?色々と変化が有りそうな SSD だ。
2013.06.23
コメント(0)
Crucial m4 CT064M4SSD2 の耐久テストを再開した。接続しているポートを変更し Sequential Read は 463Mbytes/sec に上がった。いままで 6Gbps の SATA ポートに繋いでいなかっただけか。下のグラフの様に Sequential Write の速度は安定していない。(Round 21)66% 程書き込みが進捗(32.75GiByte 書き込み)した所で、突如書き込み速度が上がっている。初めてではなく、Round 21 以降発生している。テスト環境変更と相関がある。変更後のテスト環境は性能に余裕が増える構成なので理由は推測出来ていない。テスト開始直後速いのはキャッシュが効いているため、いつもの事た。続くなぁ。
2013.05.01
コメント(0)
OCZ OCZ-AGILITY3 120Gbyte SSD 耐久テストの裏でテストの様子を探るため、色々と条件を変えてCrucial m4 CT064M4SSD2 の耐久テストを実施していた。裏で行っていたテストは中古で買った Crucial m4 CT064M4SSD2 をテスト対象にして、Round 1 ~ 20 迄を ASUS M4A78 PRO, Athlon II X4 605e (2.3GHz), 6.5Gibytes (テストに必要な性能を最低限で満たす構成)、Round 21 以降を ASUS P8H67-M PRO, Core i3-2120T (2.6GHz), 16GiBytes で実施している。Round 70, 95, 96 にて IO エラーが発生した。Round 70 の後電源 OFF/ON し、テスト再開が可能だったので続行した。Round 95 の後、Round 96 を試行し失敗した。記録に興味深い変化が残っている。SMART 情報 "202 Data_Address_Mark_Errs" は Round 33 と Round 34 の間で 0 から 255 に戻り、Fail 状態から復帰してしまっている(直ったのではなくカウンタのオーバー・フローだろう)。Sequential Write 性能が安定しなくなる以外は、目立った性能劣化は見られない。正常動作の性能に気になるところはある。詳細に解析してみると何か変化が有るかもしれない。中古なのでどのくらい使ったのか正確な値は不明だ。"173 Unknown_Attribute" 辺りの増え方から推測してみる。173 属性は Round 1 ~ 96 にて 93 から 8628 に増えている。耐久テストにて 505.8TiByte 書き込んでいる。173 属性と書き込み量が比例関係に有るとして、以前の使用者は 5.5TiByte 書き込んでいると考えられる。容量 64Gbyte に対して書き込めた量は約 510TiByte なので、容量の 8300~8400 倍程は書き込めている。もしかしたら IO エラーは SATA ポートを変えたら解消するかもしれない。本当に壊れたかどうかは、故障解析も含めて結論を出す必要が有るだろう。ん?次にテストする SSD ?
2013.04.29
コメント(0)
作り掛けコードの実装を再開している。PIC のアセンブラで書かれたソースだ。有る程度書き足していった時点で、実行サイクル数が多過ぎて処理出来ないのでは?と悩み始める。「過去に回路図とソースを書いた時点で悩みは無かったのか?」過去の自分に問うてみる。思い出せない。電車の中で、ふとトイレに歩く間、買い物をしている間、悩み続ける。ああ、そうか同時に 2 信号のパルス幅計測をせず、時分割で計測する方法だっけ。理想は同時だけど、それ程短期に変化しないので時分割で十分と判断したことを思い出す。思い出した事を回路図に落書きする。
2013.04.26
コメント(0)
風邪をひいて寝込む前に趣味でいじっていたコードや図面を久しぶりに見直す。こんなコードは何かと中断の度に溜まっていく。何か実装がすっぽり抜けている。寝込んでいる間はもう少し進んでいたと思いこんでいた。何か追いずらい。気持ちはもう少し整理されていたはずなんだけど。一つでもいいから、やり遂げよう。
2013.04.21
コメント(0)
年初より始めた SSD OCZ Agility3 120GiByte の耐久試験 の様子が大きく変わってきた。連続書き込み速度は試験開始時 121Mbytes/sec 有った。現在では 8.35Mbytes/sec(直前で中断が無かった round:39 では 6.48Mbytes/sec) になっている。4/10~4/11 に結果保存・プロットサーバーの不調で試験を中断・再開している。試験環境の電源を入れ直しているので、リンク、コントローラ、Kernel に蓄積した何らかの性能劣化原因が有ったとしても全てクリアされていると考えられる。それでも、低い性能になると言うことは SSD が劣化したのが原因だと考えられる。キャッシュを使わないランダムアクセステストの書き込み性能の記録 round:39 を見ると、書き込みサイズに関係なく、アクセスタイムが 200ms 弱となった場合が多くあることが分かる。他の記録も合わせてみていくと、書き込みアクセスタイムは徐々に増加している。書き込みアクセスタイムの増加の仕方は特異だ。段階的に t 秒増えるわけはない。途中 round:13 ~ round:37 はおおよそ 2 倍づつ増えていく傾向を見せていた期間だった。round:38 以降になって突然 2 倍ペースから外れてさらに増加している。書き込みアクセスタイムが USB 並みになっている状態は故障してしまう寸前の状態、あるいは既に実用にならない状態であると考えられる。一方S.M.A.R.T. に全く異常が無い。OCZ Agility3 は S.M.A.R.T. を読みだしても予防交換の目安に使えない。SSD の交換時期は「何となく変」なのかなぁ。
2013.04.11
コメント(0)
家庭内の DHCP サーバーの 2 重化を実施する。設定の仕方は検索して出てくる通りなので割愛。日本語の man page 内容は古い。failover の設定記述が無い。export LANG=C で英語のマニュアルを参照する。設定が終わり、/etc/init.d/dhcpd configtest で文法エラーをテスト問題なし。dhcpd を primary, secondary とも再起動する。DHCP client になるマシンを起動する。次の様なエラーか primary 側 /var/log/messages ファイルに記録された。dhcpd: DHCPDISCOVER from 08:00:27:f0:c1:a6 via eth0: not responding (recovering)時刻が合っていないと発生する様だ。primary, secondary とも {ntdpd 停止 - ntpdate 再起動 - ntpd 起動} をした後、dhcpd を再起動して解決。それにしても、ntpd が起動しているのに時刻がずれるのはなぜ?時刻ずれで dhcpd が止まってしまう... 却って脆弱になった気がする。
2013.03.24
コメント(0)
家庭内 LAN の DHCP, NTP, DNS 他色々と 商用電源監視盤、SSD 耐久試験記録 を行っているサーバーが停止していた。原因は商用電源監視盤に使っている Micro SD Memory が壊れたのが原因だった。Flash Memory の耐久性が無いのは何度も壊しているので分かっていたことのはず。2012/5/12 に購入記録が有る SUPER TALENT の Micro SD 32Gbyte メモリが 2013/3/19 に壊れた。使用したのは多く見積もっても 8Gbyte だ。記録の複製が HDD に有り、そこで記録が占有している容量だ。監視記録を蓄積するメモリだ。おおざっぱに 1 年間使用したとして、1 日で 8GByte / 365 = 21.9Mbyte を書き込む。Flash Memory の寿命は書き替え回数だ。十分なウエアレベリングがされていれば、"総書き込み量" が "総容量" x "寿命に達する書き替え回数" に達するまで、書き込めるはず。"総容量"以下しか使用していない。計算が合わない。"寿命に達する書き替え回数"は 1000 回ほどは有るはず。追記をしているので、何度も同じブロックに書き込むと考えられる。何度も同じブロックに書いた回数を "追記回数" とする。これで寿命に達したとしたならば、"寿命に達する書き替え回数" x ( "全容量" / "使用容量" )
2013.03.20
コメント(0)
Micro USB B コネクタを使う機器を仕事で開発している。ふと、下の画像の様な状態になりそうだった。危険なので絶対に真似をしない。ほぼ確実に故障してしまう。疲れていると発作的に Micro USB B コネクタ・プラグを standard USB A コネクタ・ソケットに挿し込みそうになる。規格に厳密に対応している Hub や PC のポートなら危険は無いのだけど、世の中そんなものは少数だ。間違って差し込んだ場合、VBUS が短絡して火花が飛ぶか、発煙する。保護回路?多分 500mA 制限ではなく、800mA ~ 1.6A 程の制限だろう。火花を飛ばすには十分だ。
2013.02.20
コメント(0)
IO-DATA MacicTV を起動しても、「初期化に失敗しました」と出て起動しない。プログラムが停止して、「デバックしますか?」と聞いてくる。原因はディスプレイドライバの更新だと思われる。ディスプレイドライバと言っても、最近は HDMI(Display port) 出力なので、サウンドドライバが入っている。おそらく、ドライバ更新処理で HDMI のサウンドドライバが有効化されたため、使っていた USB オーディオデバイスと併せてサウンドデバイスが 2 個に増えた結果、「初期化に失敗しました」と出るようになった。HDMI のサウンドドライバを無効化して問題を解消した。MagicTV はサウンドドライバが 2 個以上あると障害を起こす。以下は、問題解決に至らなかった試行。サポートページを参照する。番組表初期化、更新、チャネルリストクリア、レジストリクリア、ディレクトリ(iodbad) 削除をした。復旧しない。一旦初期化した。録画も全部消去、復旧しない。再インストールした。復旧しない。プログラムを難読化してあるから、デバック出来ないのだろうか?デバックするのは諦めてもらってよいから、各アプリケーションを環境検査プログラムで包んで、問題についてもう少し分かりやすいメッセージで示しても良いと思う。「デバックしますか?」逆アセンブルリストが出ないのだが...
2013.02.10
コメント(0)
SSD 耐久試験環境の起動ハードディスクを交換して試験を再開した。再開後の書き込み速度が大きく低下している。差が大きい測定を取り上げてみる。起動ハードディスク交換前 120Mbytes/sec、同交換後 55.9Mbytes/sec原因は良く分かっていない。BIOS 設定を点検し変更をして、Kernel Panic の原因になりえるか調査している。原因では無かった。調査終了後に設定を戻している。A8-3820 の周波数は上限 2.5GHz まで上がる(Turbo Core 発動は今まで見たことが無い)。HPET も有効になっている。メモリの速度クラスも変更してない(Read 性能は殆ど変っていない)。swap の発生頻度も低い状態は変っていない。Linux kernel の block IO cache を使わない (with O_DIRECT) ランダム・ライト・アクセス性能のプロットから、1MiByte 以下の転送で Turn Around Time が 15mS 程になる場合が増えているのも大きな変化だ。耐久試験開始を始めた初期の頃から「1MiByte 以下の転送で Turn Around Time が 15mS 程になる場合」は random read/write とも稀に発生していた。消去か書き込みに時間が掛かる様になった?SSD を電源を入れずに暫く放置し、アクセス速度が変るとすれば(自分の例の様に下がるのではなく、アクセス速度が向上する場合もあるとして)、SSD に対する速度の評価や速度低下の解消に対し様々な議論や方法論が出てくるのかもしれない。条件や履歴を意識するのが難しい。Solid State とは言うものの、記録に使っている電子はとても揮発しやすく、Solid とは言えないものだよなぁ。
2013.01.31
コメント(0)
SSD 試験環境に使っていたハードディスク Maxtor 6V300F0 が不調だったので、不調の状態を調査した。原因は媒体の損傷と考えられる。損傷個所は 10 個所、1 個所辺り約 170,000 セクタが断続的に読めなくなっている様だ。損傷範囲開始 LBA, 損傷範囲終了 LBA, 範囲の LBA 数104691712, 104850015, 158304104850016, 105061087, 211072106037296, 106248367, 211072408714544, 408899231, 184688409294992, 409479679, 184688429320448, 429478751, 158304430270272, 430481343, 211072430481344, 430586879, 105536431009024, 431061791, 52768431061792, 431272863, 2110721 セクタ単位で読めないセクタを拾わず、有る程度の範囲で読める、読めないを判断した。同心円状に 10 個所損傷したのか?各箇所の損傷セクタ数に大きなばらつきが無い。範囲を大まかに見積もる単位が同じセクタ数というのも理由かもしれない。LBA と相関が有っても良いはずだけれど、強い相関が有る様に見えない。実際に破損したデータは git リポジトリだった。ローカルに clone したファイルなので全損でも影響は無い。稼働中に読み書きする機会は無い?のになぜという謎は残る。ヘッドに何か問題がある可能性もある。ヘッドに歪みか曲がりがあり、ディスクに傷を付けてしまうか、読み出しが困難になっているかもしれない。扱いが悪く、何か衝撃を与えたことが有ったっけ?忘れてしまっている。
2013.01.29
コメント(0)
全892件 (892件中 251-300件目)