全4832件 (4832件中 101-150件目)
-
筆算方式で uint32_t の平方根を求める処理 - MO メディアから発掘したコード
MO メディアをサルベージしていたら、懐かしいコードが見つかる。筆算方式で uint32_t (32 bit で表した正の整数) の平方根を求めるコードだ。8086 Assembler のコードで記述してある。アルゴリズムの概要をコメントに書いてあるので他の言語やアセンブラでも容易に書き直せると思う。idealmodel small,ccodeseg;in A;; X=0; w=0; Count=16; @@l1:; w<<=1; X<<2bit<<A; save X; X-=(w+1); if cond CY; {recover X; }; else; {w|=2;; }; LOOP @@l1;; w>>1 -> ans;in dx:ax;proc NOLANGUAGE sqrrootxor si,si ;bl:si Xxor di,di ;bh:di wmov cx,10hmov bh,0c0hjmp @@l0ineven@@l0:dec cxjz @@exitshl ax,1rcl dx,1shl ax,1rcl dx,1@@l0in:test dh,bhjz @@l0xor bx,bxeven@@l1:shl di,1rcl bh,1shl ax,1rcl dx,1rcl si,1rcl bl,1shl ax,1rcl dx,1rcl si,1rcl bl,1push sipush bxstcsbb si,disbb bl,bhjnb @@j1pop bxpop siloop @@l1shr bh,1rcr di,1mov ax,diret@@j1:add sp,4inc diinc diloop @@l1shr bh,1rcr di,1mov ax,di@@exit:retendpevenpublic ulsqrrootproc ulsqrrootarg @@a:dworduses si,dimov dx,[word high @@a]mov ax,[word low @@a]call sqrrootretendpevenendコメントのアルゴリズムに対し、実装は上位桁に 0 が続く場合、計算を少し速くする工夫がある。それ以上の変わった処理やアセンブラ独特の高速化は導入していない素朴な処理だ。今時は浮動小数点計算がお手軽に使えるし、8 ～ 16 bit の組み込みマイクロプロセッサもメーカーが実装例を示しているので、開平処理を態々書くことも無いか。これをテストするコードは C 言語で書いてあった。分かりやすく書き直してテストしてみる。ビルドできて、実行すると期待通りの動作をした。Borland C++ 3.1 (TASM, BCC, MAKE, TLINK) でビルドできるソースコード一式を作る。ビット化け、重複、欠落を起こさずに MO から読み出せていた。今でも懐かしく思えで、動かそうかなと思うコードってそんなに多くないのかな。
2020.08.20
コメント(0)
-
SHARP UX-D56CL FAX 電話機紙詰まり - 排紙口に有ったゴム片を取り除く
業者さんとのやりとりで FAX を使う事になった。ひさしぶりに文面を FAX で受け取る。メモリに記録された文面を印刷すると紙詰まり。下の画像は紙詰まりの状況を見るために、コピー機能を使った時に詰まった紙。紙って不確実な物だな。この FAX 機は中途半端な紙詰まりで印刷すると、文面は殆ど読めないのに印刷完了したことになって、メモリが消えて内容を失う。UI に疑問を感じる機械だ。こんなことに手を煩わし、受信・送信ともメールに比べて、問題が無くても 10 分くらいは作業時間をロスする。FAX 通信は昭和な仕事だ。紙の右側にシワが多くよっている。カバーを開けて見える上部へ排紙する口の右側にゴム片が挟まっていた。ゴム片を取り除き、給紙 - 排紙が上手く行くようになった。横 20mm x 縦 10mm x 厚 1mm くらいの大きさだろうか？内部に有った何かの部品だと思われる。表面が粘るので粘着テープか接着剤で取り付けたと思われる。給紙部分の紙押さえ？ そう言えば 1 枚づつ給紙せず、複数枚紙を吸い込む。日本の家電メーカーが強かったのはこういった機構、電子回路、素朴なソフト(とは言ってもこの FAX は UI がグラフィックである)が組み合わさった製品だった。インターネットとソフトの時代になり機構では優位性を出せなくなり、電子回路は最先端の半導体は作らなくなったし、設計も海外へほぼ丸投げ。ソフトは海外に全く追従できない。こうやって故障するのを見ていると、日本の品質管理も怪しい。設計段階で作り込む品質が悪化している。受け取った FAX にメールアドレスが書いてあった。次の通信機会でメールを使おうかな。Word の FAX テンプレートから文面を作るのも時間が掛かる。
2020.08.20
コメント(0)
-
Google 先生これは何ですか？ - 調理温度計(クッキング温度計)は何に似ている
暫く日記をサボっているのでネタ発掘。いつ買ったのか調べたくて、食品温度計(あるいは調理用温度計、クッキング温度計)を検索してみる。始めに次の画像で検索してみた。タイルの壁をバックに何がトイレットペーパーホルダーや手すり、ちょっとした壁掛け小物入れが写った画像が類似画像として見つかった。もしかしたら、google 画像検索エンジンが賢くなって、結果が変わっているかもしれない。なるほど、背景に写る工作用紙の方眼がタイルに見えたのか。背景・食品温度計のどちらも画像の文脈だと捉えて、背景はタイル、食品温度計はタイルに接近して存在する器物に近い何かだと判断して検索したのか。両方の文脈を満たす画像の組み合わせがトイレットペーパーホルダーの画像だったのか。面積的に広い背景の方眼用紙が邪魔なのかな。殆どの人間は、背景の方眼用紙は画像の主要部分では無いと判断するはずだ。わかった。無地で撮ってみよう。次の画像で検索してみる。なにやら水道配管やシャワーヘッドのような画像が良く一致する。こんどは白壁背景を選んできた様だ。水道配管にシャワーヘッドねえ... 似た形なのかな。google 先生画像の各部分を文脈(もうちょっと言うとベクトルや相互の配置接続関係を要素として纏めた情報)に分解することまではできている様だ。複数の文脈をそれぞれをある程度満たす画像を見つけてくるのかな。分解した文脈のうち、一つだけ非常に良く一致する画像を見つけるような仕掛けではなさそうだ。余白あるいは背景の大きさも検索結果に影響するようだ。次の画像で検索するとやはり水道配管の画像が多く見つかる。画像の殆どは部品の状態になっている。もう少し余白を広くすると鍵が見つかる。google 先生に色々なことを聞くとたまに「captcha 認証をして」と言われる。あれはどうやって作っているのだろう？
2020.08.19
コメント(0)
-
住宅用火災警報器を取り替える - Panasonic の新型・旧型は互いにネジ穴位置が同じ
住宅用火災警報器を取り替えることにした。製造から 12 年が経過している。電池寿命が過ぎているのと、本体も機能維持期間が 10 年なので交換が必要だ。交換前後で同一メーカー品とした。交換してみて、天井のネジ穴位置に互換性が有ったことが分かった。天井にネジ穴を増やさずに済む。交換前交換後けむり当番panasonic SH4400けむり当番panasonic SHK6030Pねつ当番panasonic SH4600ねつ当番panasonic SHK6040P交換作業前後の様子を書いていく。買う前から、外観が変わっていることが分かっていた。また天井にネジ穴増やすのかなぁ... 旧型(交換前) Panasonic SH4400 けむり当番交換前の住宅用火災警報器は分かりやすく、センサー部分が出っ張っている。いかにも感知してくれそうな形だ。このままでも良いんだけどな...旧型(交換前) Panasonic SH4600 ねつ当番新しい住宅用火災警報器はスリムだ。新型(交換後) Panasonic SHK6030P けむり当番何となく小さくなったような... なんだな。旧型・新型どちらもインテリアに与える影響は変わらないよう思う。引き紐が下がっているのだし。新型(交換後) Panasonic SHK6040P ねつ当番けむり当番から交換作業を始めた。天井に取り付ける台座部分の引っかかりに互換性が有ることを期待して、台座をそのままに、旧型を外して、新型を取り付けようとした。嵌まらない。天井から台座部分を外して、外観を見てみる。左が旧型 SH4400、右が新型 SHK6030P だ。台座と本体両方の爪形状が変わっていた。本体の直径も一回り小さくなっている。電池も小さくなっている。10 年ギリギリもつ様に小さくしたのか。回路と Firmware の改良で消費電力を減らしたか。うーん、ネジ穴位置も変わる？ 良く見てみる。調整可能なネジ間の距離からすると、天井のネジ位置はそのままで良さそうなことが分かる。旧型を取り付けるときに付けた石膏ボードアンカーはそのままで、取り付けることができた。ねつ当番も同様だった。左が旧型 SH4600、右が新型 SHK6040P だ。2 つの石膏ボードアンカーから木ネジを 1 本は外し、もう 1 本は緩めて、旧型台座を取り外し、新型台座を取り付けた。台座の爪に互換性を持たせなかったのは何でだろう。爪が劣化して折れる可能性を考えたのだろうか。劣化の可能性があるならば交換を仕向けるように形状変更した？天井の穴が増えずに済んだ。テストしてみると新型の方が音量が大きいように感じる。電池が新しいためなのか、音量アップしたのか。
2020.08.14
コメント(0)
-
鳥さんたち、虹の袂には行けたかな？ - 刻々と変化する虹を暫く見る
午後 16 時を少し過ぎた頃、雷鳴が盛んに聞こえるようになった。遠くを見通すと、落雷の閃光が見える。帰らないと... 自宅まで自転車で急いで 30 分くらい離れた場所にいた。自転車の鍵を開けて、帰宅を始める。既にポツポツと肌に雨粒が当たる。後 10 分ほどで着く道程でタオルを落としたことに気づく。戻らず進む。戻ると雨に降られる。雨はますます強くなっていた。カゴに入れた買い物バックが雨に濡れてしっとりとテカりだしていた。帰宅して、うがい、手洗い、目洗い、顔洗い、シャワー、洗濯を一通り済ませて外を見る。夕日が差し込んできていた。虹見えるかなぁ。あれ？鳥さん達は虹の袂へ行ってみたのかな。うーん、たどり着けた？気ままなカラスのはずなのに、なかなか塔から離れない。虹を見ているのか、たどり着けない虹の橋に困惑している？日が日没限界まで傾き、空がオレンジ色に燃え出す。薄かった虹か大きくアーチを描きよく見えるようになった。夕飯の支度しないと。
2020.08.13
コメント(0)
-
サルベージした MO の文字化け - 単純なビット誤りではなさそう
MO ドライブを HARD OFF で見つけて、手持ちの MO メディアをサルベージしてみた。ディレクトリが不思議な文字化けをする。次は化け方の例だ。DOS で扱いが難しいのでファイル名に入った空白は '_' で置き換え、コントロール・コード、使えない文字は置き換えている。size mon day year file-name 7714 3 14 1993 G3FIL.ASM 7735 3 14 1993 G3FIL.BAK 7263 3 14 1993 G3FIL.JNK 1247 3 14 1993 G3FIL.OBJ 8688 3 15 1993 G3FIL2.ASM 8688 3 15 1993 G3FIL2.BAK 4749 3 15 1993 G3FIL2.OBJ 1701 2 19 1993 GTII___O.OBJ duplicated extension 4323 3 15 1993 GTII2__O.OBJ Under line = space 131 11 14 1992 GTII2__T.TFA 0 3 14 1993 GTR22.AAK bit error? B turns into A 0 4 8 1993 GTR22.RRJ 5140 11 10 1992 GTRFFIL.AAK 2804 11 15 1992 GTRI.BAK 2817 2 19 1993 GTRI.C 223 1 27 1993 GTRI.EEE bit error? 4918 1 27 1993 GTRI.EXE 28 8 26 1992 GTRI__.EEE 3682 4 7 1993 GTRI3.BAK 3899 4 7 1993 GTRI3.C 194 3 15 1993 NONAME.OBJ 3084 12 13 1995 ROO.NNK missing T, J turns into N? 919 12 12 2010 ROOT.ASM 27 11 26 1992 ROOT0.PZJ R turns into Z 9954 11 18 1992 ROOTT.EXE 519 11 18 1992 ROOTT.OBJ 1932 12 13 1995 ROOTT.TXT 332 11 18 1992 'ROOTT__(dq).C' (dq) = '"' 8 6 10 1992 TAMM___C.CFG 2013 2 11 1993 TRIGON.BAK 2017 2 11 1993 TRIGON.DOC 13204 2 11 1993 TRIGON.LZH 36 1 1 1970 TTRI.PR 1427 3 15 2101 TTRI2.PF 5272 3 12 1981 TTRIFLL.AS 702 11 29 1992 WAYING.BAK 702 11 29 1992 WAYING.C 21112 2 19 1993 WAYING.EXE 1452 2 19 1993 WAYING.OBJ 28 11 29 1992 WAYING.PRJ 4623 12 13 1995 ZOOTT.BAK化け方かディレクトリ構造を壊した場合は除いてある。. .. が化けてディレクトリの親子関係が壊れたファイルサイズ部分が壊れて異様に大きくなったファイル(主に 10Mibyte 以上)は除いてあるディレクトリエントリーのクラスタ番号部分が壊れて子ディレクトリにたどり着けなくなった気づいた化け方の傾向は次の様になった。1 ～ 3 bit 程化けているファイル名の文字が重複する訂正しきれず、数ビットの 0/1 が反転するのは理解できる。重複(厳密に言えば隣接するバイトで上書きされてしまう)が起きるのはなぜなんだろう。誤り訂正符号の理論をよく勉強すればもう少し背景が分かってくるのかも。それとも Linux の FAT file system driver が壊れたディレクトリに弱く、意図しない memcpy, memmove などをしてしまうのだろうか？ディレクトリ化けで永久にソースは失われた？ 化ける前のファイル名を推測して、現役のハードディスクを探してみる。別の系譜で子孫が生き残っていた。
2020.08.13
コメント(0)
-
今日は強い南風、航空管制上手くいっているかな - おお、交わした
強い南風が吹いていた。羽田空港離発着コース変更後、暫くは頭上から離れたコースを飛行機が飛ぶようになっていた。最近航空管制がショートカットを指示するのか、また良く飛ぶようになった。おっ？飛行機同士が接近している。高度も近そうだなぁ。もっと、近づいているな。車で言うと、なぜか吸い込まれるように近づくコースだな。おお、交わした。高度差が有ったのかな？
2020.08.11
コメント(0)
-
お盆休みはホームセンターへ？ - 意外と混んでいるなぁ
休日になった月曜日、夕方になってホームセンターへ行く。買いたい物と、とりあえず見ておきたい物が有った。あれ？自転車置き場が満車だなぁ。少なくとも 2, 3 ヶ月に 1 回は行くホームセンターだ。自転車の置き場を探すほどに混んでいた経験は無かった。駐車場も混んでいた。熱いのに大工仕事なの？ ホームセンターに来たからと言って、必ず大工仕事でも無いか。ちょっとしたインテリア・収納・清掃・調理道具とか、「買いたかったな」とか「整理せずに放置していたのをなんとかしよう」という切っ掛けで、来ているのかもしれない。7, 8 分くらいレジ待ちしただろうか、ちょっと長かった。みんな何もせずに寝ているだけのお盆じゃダメなのかな？あっ、そうか テレワークで使うカメラで写る範囲をミニ・スタジオにしないと... グリーン・バックもとても綺麗なお家に見える(意識高い系)リアル壁紙もホームセンターにまだ無いなぁ...
2020.08.11
コメント(0)
-
あれ？自分の体温 35.3 ～ 35.5 ℃くらいだっけ？ - 店舗入り口に赤外線撮像式の検温器
店舗入り口に赤外線撮像式の検温器があった。検温した体の場所と温度が入口に立てられた大画面テレビに表示された。おでこの辺りで 35.3 ～ 35.5 ℃くらいだった。平熱は脇の下の検温で 36.5 ℃くらい。低めかな。自転車で 40 分走行、冷房がない部屋で 1 時間、15 分また自転車で走行、汗が背中に流れるくらい暑さを感じていた。体温は 37 ℃くらいのつもりだった。低めに表示された原因は何だろう。マスクをして、髪の毛が目に掛かるのを防ぐためにタオルを頭に巻いていた。検温範囲が狭くなった？ 体温を下げるため、水を含ませたタオルで体と顔をこまめに拭いていた。表面体温が下がっていた？もともとそんなに正確には測れない？
2020.08.09
コメント(0)
-
スズメ窪(スズメの砂場) - 窪みは何を切っ掛けにでき始める？
スズメの砂場(窪み)を見つける。ここの窪みで砂浴びをしている所を見たことが有る。警戒心が強いので、近づくと人の気配を感じて逃げていく。元々はただ地面がむき出しになっていた場所だ。丁度良い窪みは無かったと思う。何を切っ掛けに砂場に使われ始めて、窪みができていくのだろうか？複数の窪みが有るのは、集団で使っているため。2 羽がやって来て使っているのを見ている。
2020.08.08
コメント(0)
-
ガス給湯器のエラーコードはだいたい共通？ - HTTP response code の様なお約束があるみたい
風呂釜が故障したので、地域ガス供給会社のサービスショップに電話をした。症状を話しているうちに、「エラーコードを教えてくれませんか？」と聞かれた。あれ？電話で話す中で機種名を言っていないはず。定期的にガス供給会社が行っているガス機器点検で機種を記録している。自分は姓を名乗っただけのはず。電話番号で照合して、データベースを検索したのかな...少し戸惑って、メーカー、機種名、エラーコードを伝えた。メーカー、機種を伝えずにエラーコードだけで故障内容が分かるのだろうか？ネットでシェアがありそうな給湯器のエラーコードをいくつか調べてみる。おおよそコードと故障状況の対応が一致している。発生したエラーコード 252 で言えば次の表のようになっていた。給湯器エラーコード 252 が示す状況メーカー状況リンナイふろ水流スイッチの故障ノーリツふろ循環系統の故障または異常パーパスふろ水流スイッチ異常パロマふろの追い焚き配管の凍結の可能性排水栓をし忘れる百の位の数値は大分類的な扱いのようだ。メーカー毎の機構の違いで微妙な意味の違いがあっても、致命的な勘違いは起こさないようにコード体系を作っているようだ。HTTP response code の様な仕組みだったのか。
2020.08.04
コメント(0)
-
近所で梨狩り始まる - カラスさんは既に来ている
近所で梨狩りが始まった。画像は 8/2 日曜日に撮った。最近カラスが騒がしいのは梨が実り始めたからか。持ち帰りの梨も出始めた。梨狩りは 3 密だろうか？ 常に屋外だ。息はすぐに風で遠くへ流れる。太陽光下なので紫外線で殺菌される。あまり接触はしない。あー、子供を肩車するとかはあるかな。適当に離れて行動できる。もぎ取った梨や出荷規格外の梨を食べるテーブルサービスも有ったっけ。テーブルを拭くとか、皮むきの包丁を洗うとかかな。普通に今までもしている。大抵の梨園のテーブルは屋外か、屋内でも吹きっさらしだ。換気は十分。梨園は天候に左右されやすく、どちらかと言えば地味な観光だった。今年はお客さん来るのかな。
2020.08.03
コメント(0)
-
風呂釜が壊れた ノーリツ GTS-163A - エラー 252 「ふろ循環系統の故障または異常」
いつもの様に風呂を沸かし始める。そろそろ沸くかなと思った頃に、いつもと違うアラーム音が鳴りだした。普通に動いているときは 3 回くらいピー、ピー、ピー、となってお風呂が沸く。長く鳴り続けていた。ん？何かあった？操作パネルをみたら、時計表示部分と運転 LED が点滅を繰り返していた。時計部分の時刻がずれている？と不思議に思った。エラーコード？ 風呂釜の形式ノーリツ GTS-163A で取得したマニュアルを読んでみると、エラーコード 252 「ふろ循環系統の故障または異常」だった。自動湯張りが停止した。湯船の温度は少しぬるめ、運転ボタンを押し直す。エラー解除された。追い炊きを押す。5 分くらいして同様にエラーとなった。湯張り量はいつもと変わらず。放置すれば湯温は下がる。すぐに少しぬるめの湯船につかる。湯面が上がれば解消？ 再度追い炊きを試す。再度エラーになった。循環ポンプが動き、追い炊き吐き出し口から出る水流がある。温度は上がっていない。ガスバーナーが点火していない。外からガスの臭いはしないので、追い炊きバーナーに繋がるガス弁が開いていないのだろう。失火や着火失敗ではないと思われる。そうであれば、シャワーを使ったときに風呂釜が「ボン」と音を立てて、小さな爆発を起こすだろう。GTS-163A 動作状況機能状況風呂給湯動くシャワー動く追い炊きエラー 252自動 湯張り湯張りまで動作保温はエラー 252 で停止少し温度高めで湯張りすれば、湯船に浸かれそうかな... 昔は当たり前だった湯張り一回勝負だ。なんだな、部屋を買ったとき、風呂釜は「動かない機器」(あるいは動作保証がない設備)として取引すると不動産屋から説明があった。2003 年製なので 17 年稼働、既に性能維持のための保守部品は無いはずだ。部屋を買って 2 年半くらいで壊れたか... あと 3 年くらいは動くつもりだった。浴室リフォーム展示会に行ったのは 1 年半前、見積は取らずだったので、壊れるフラグを立てた積もりはなかったのに。
2020.08.03
コメント(0)
-
M2A-VM HDMI 膨張コンデンサ交換 - 条件が違う 6 個
PCI スロットに SCSI ボードを差し込む積もりで、M2A-VM HDMI マザーボードの PC を開ける。コンデンサが膨れているのが見えた。1 箇所だけかな... 混んだ場所で作業していたので、全体が見えず。懐中電灯を当てて見て 2, 3 箇所を確認した。SCSI ボード差し込むのは無理か、マザーボードをケースから外すことにした。同じ 6.3V 820uF のコンデンサが 6 個膨らんでいる。上の画像の様に、電圧系統を調べたのは後のことだ。調べる前は「え？同じ電圧系統が全滅？」と思い電源ユニット Enhance ATX-0250GA (500W PFC) を開けて確認する。ヒートシンク下に 2 次側コンデンサが並び、角度を変えながら見回す。膨らみがあるコンデンサは見当たらない。日本ケミコン KZG 6.3V 820uF ばかりなぜ膨らむのだろう。膨らんでいないのもある。電圧系統を調べてみる。5V, 5VSB, 5VSB を上流とするアナログレギュレータ下流, Vterm (DRAM bus 終端電圧), 5V はなぜか USB ポート周りが膨らむ。5VSB も殆ど使った実績がない USB ポート周りだ。6 個のコンデンサの使用条件が違うことが分かった。修理後発熱状況を触診で診てみると、隣接しているレギュレータで炙られているコンデンサと、リプルが大きいと思われるコンデンサが有りそうだ。シルク印刷と極性の関係に要注意だ。白く塗られている方が正極、塗られていない方が負極だ。メーカー毎にシルク印刷とコンデンサ極の対応は違う。周りのコンデンサも含めて、対応を確認する。コンデンサを 6.3V 1000uF OS-CON に変えることした。系統が違うのと、5V, 5VSB は負荷される容量が変わることがあり得ること、Vterm を含むアナログ電源系は、隣接するレギュレータが熱く、負荷電流が多そうだ。容量が増えても、まぁ、大丈夫かな... と見込む。コンデンサは小型なので PCI スロットよりも頭が低い。拡張カードも当たらない。マザーボードを外す時点で、「新しいマザーボードに入れ替えるか...」と何となく思っていた。出費が痛いのは分かりつつも、2, 3 ヶ月前からネットで新しいマザーボードと CPU を物色し始めていた。うん、新しい物を探すと壊れる法則が発動した。修理を終えて、M2A-VM HDMI が元いた PC ケースには別のマザーボードが入っていた。段ボール箱の上に座らせ、8Gibyte の主記憶にネットワーク・ブートした Linux を乗せて動作確認、20 分ほど動かして、交換したコンデンサに異常なし。段ボール箱に入れて仕舞う。Phenom II X4 945, 8Gibyte、命令セットが足らず Android Emulator は動かなくなり、ビルドも少し難儀する。
2020.08.02
コメント(0)
-
Ainex RS-007 USB2.0 リアスロット Type-C 2 ポート 道理で廃番になるわけだ - Rp 56kΩ が付いていない
Ainex RS-007 USB2.0 リアスロット Type-C 2 ポートを買う。USB Type-C ポートを増設するのが目的だ。調べてみると USB Type-C ポートとして機能しない回路になっていた。CC1, CC2 に Rp 56kΩが付いていない。「出荷終了品」になった理由だろう。千石電商から通販で届いたときに、パッケージがくたびれていて汚れていた。妙な感じがした。誰も手を付けないのはなぜ？ぱっと見の仕様からして変だ。PC マザーボードの USB 2.0 端子は 2 ポート出ている。これを 1 ポートにしてしまう。製品全体で 4 ポートを Type-C 2 ポートにしてしまう。もったいないな... と思っていた。詳細を調べる前にポートが減る理由を考えてみる。Type-C コネクタは DP, DM 信号が A, B 両列にある。スタブにならない様に Port 1 - A 列, Port 2 - B 列になる様にしたのかな... 最もらしい理由が本当なのか基板を良く見てみよう... 注: この考えは間違いPlug 内で DP, DM の A, B 列がまた接続されている。 3.3.1 Cable Construction (informative) USB Type-C Cable and Connector Specification Release 2.0。基板を良く見てみる。あれ？ Rp 抵抗器が無い様な。Rp 抵抗器は VBUS に電力を供給する側だと示す VBUS - {CC1, CC2} 信号端子間に入る Pull UP 抵抗器だ。単純に抵抗器で構成した場合、ポートは Host Role 固定になる(4.11.1 Termination Parameters など)。秋葉原の千石電商で店ざらしになっていたのは、「良く訓練された人」が手に取って Rp 抵抗が無いことを見て、買わなかったのだろう。半分剥がれかけのシールが汚れているのは、開けて念入りに確認したのか。通販は難度高いな。どうなっているのだ？ CC1, CC2 信号を VBUS へショートするのは乱暴すぎる。接続相手が壊れるかも。オープンでは VBUS 供給能力無し (Device Role に認識されるか、そもそも接続不成立) になってしまうし。VBUS - CCx 間 Rp 抵抗値 と VBUS 電流供給能力 (VBUS=5V)Rp 抵抗値 [Ω]VBUS 供給電流 [mA]56k50022k150010k3000回路を調べてみる。CC1, CC2 とも open だった。なるほど、販売終了になるわけだ。RS-007 PDF 回路図 1 channel 分次の様に CC1, CC2 を 56kΩ で pull up すれば良いはず。図に描くのは簡単だ。RS-007 (修正案) PDF 回路図 1 channel 分Type-C Receptacle の端子に半田付けか... 細かすぎる。鉛筆で塗る？この blog で出ていた RS-007 回路図一式 bsch v3 形式と PDF
2020.07.31
コメント(0)
-
地震来るのかなぁ - 緊急地震速報で一斉停止したみたい
さて、色々と取りかかるかな。と言った頃合い 9:39 に緊急地震速報が防災無線放送から流れてきた。曇った空の元、不気味に響き渡る。放送長いな。隣接市の放送も聞こえ始めた。え！これから部屋の中がかき乱されたように物が倒れて散乱するの？身構えて 3 分くらいしても揺れは感じず。どうしたんだろう... 何処か別の場所で？ 玄関の扉を開けて、テレビを点ける程度の時間的余裕が有った。商用電源監視記録を見てみると、機械類が一斉に停止したと思われる周波数上昇が 9:39 に見られた。やはり 3 分くらいして、皆テレビを点けたのだろうか？ 9:42 に周波数低下のピークが出た。緩く周波数が上がっていくのは、「本当に来ないの？」と身構え続けたか、福島県郡山市の爆発事故が気になったのか、長くテレビを点けていた？19 時少し過ぎ、北の空を部屋から見る。冷たい北風が部屋に入ってきて、体が冷やされる。ん？北の空が橙色の目を細めてこちらを見ている。お天道様、まだ何かするの？
2020.07.30
コメント(0)
-
中国企業のアプリなど「利用制限の法整備を」- たまには政治ネタ、ソフトウエアの現実を分かって検討しているのかな
ニュースサイトを見ていたら、何処かの党が『中国企業のアプリなど「利用制限の法整備を」』と何やら法整備を検討していた。なんだろうなぁ。議員さん達、日本のソフトウエア開発の現状を理解していないな。今時、アプリどころか OS の kernel 部分まで殆ど中国が絡んでいるのに。安い中国製スマホなら、普通の人でも直ぐに思いつくだろう。現実はかなり多くの日本製(正確に言えば日本メーカーブランド)の家電製品に中国製のソフトウエアが絡んでいる。テレビ、録画・再生機器、WiFi/BT 使用機器、PC 周辺機器 HDD/SSD、少し見回して思いつく製品だ。これらの製品に使われているデバイスはチップセットの形で中国が設計して、それらを動かすソフトウエアも組みで提供されている。メーカーはリファレンスデザインを意匠デザイナーが設計した外形に合わせて、プリント基板に起こす。部品はそのまま載せ替えだ。ビジネス用語で言えば「ターンキービジネス」だ。信号線 1 本、つまり GPIO のポート番号、IRQ 割り込み番号、そんな細かいところまで同一だ。もし、1 本でも使用信号を変えたならば、中国で作られたソフトウエアに手を入れる必要がある。「簡単でしょ？」と思っている人が居るかも。現実は GPIO のポート番号、IRQ 割り込み番号を変えられる日本のエンジニアはそんなに居ない。仕事をしていた先で、人が足りないのだけど... 出来る人知っている？と聞かれたり、いわゆる人材派遣・客先常駐の開発事業者に声を掛けたのだけど、人が居なくて 2, 3 ヶ月間作業未着手と言ったことを何回も見てきた。チップセット外のデバイスを使ったならば、ほぼ絶望的に対応できる日本のエンジニアは居ない。中国のエンジニアに聞くしか無い。あー、洪水で開発拠点大丈夫かなぁ。退職・(会社役員を)退任した高齢者を何人か見てきて思うのは、彼らはネジ・グギと言った目で見て数えられる物は非常に鋭い洞察をするのに、ソフトウエアの様に目に見えないものは全く理解できていないことだった。目的を達成するまでの処理の組み立て、処理の難度・規模、お互いの関連性と言った事柄を見た・聞いた通りに、言い直すことも、書き直すことも難度が高かった。彼らは同じ物を繰り返し作る、誰かの真似で仕事が出来る。といった昭和の教育と日本の社会設計で生きてきた人たちなのだ。まだ政治は昭和のまま、技術まで昭和に彼らは戻したいの？
2020.07.29
コメント(0)
-
今時の秋月電子通販の注文から着荷までの時間 - 自分の注文の場合 2 日だった
最近殆ど秋月電子の店に行っていない。雨続きなのと新型コロナウイルスが流行していて、行っても色々と制限があって楽しむのは難しそうだと思っている。通販を使う。お知らせには「新型コロナウイルスの影響で通販の注文が集中し、通常より2 ～ 3日程度発送作業に遅延が発生しています。」とある。待つのかなぁ。2020/7/26(日) 午前 1:45 頃に注文を実行する。日曜稼働だったとして 7/26(日) 午前に作業開始、通販センターのページをみると月曜稼働かもしれない。出荷通知 7/27(月) 19:35 → ヤマト運輸(北東京法人) 7/27(月) 19:53 → ヤマト運輸(流山ベース) 7/28(火) 3:23 → ヤマト運輸(地域拠点) 7/28(火) 6:40 頃配達開始 → 自宅 7/28(火) 10:30 頃着荷 となった。大型家電量販店の注文から着荷までの時間と比べてほぼ同じか早い。新型コロナウイルスの影響が無い商品で、途中の配送ルートにも影響が無く、大雨の影響が無かったのが幸いだったのかも。店にお客が戻った？注文殺到が一段落？経済活動低下？
2020.07.28
コメント(0)
-
手持ちの MO ドライブ 2 台とも不調・故障 - もうちょっと慎重に電源を入れれば良かったか
ジャンクで買った MO ドライブで読めないメディアが有った。そもそも、手持ちの MO ドライブで読める積もりだった。MELCO MOS-640S を動かしてみる。ジャンクで買った MO ドライブより状態が良くない。エラー多発、最初からメディアを認識しない。何が悪いのだろう。ダメ元でレンズクリーニングをしても変わらず。悪化したかな。128Mbyte の MO メディアなら、一番最初に買った MO ドライブが使えるはず。TEAC OD-121S を動かす。SCSI, AC ケーブルを接続して電源ボタンを押す。ON! 「あっ」部屋の電灯が一瞬暗くなったのが分かった。POWER LED は点灯しない。もう一回押しても、POWER LED は点灯しない。2 回目の Power On は SCSI ケーブルを外すべきだった。「部屋の電灯が一瞬暗くなった」と言うことは AC ライン電圧低下が起きたのだ。大電流が流れたな。ドライブ内部のヒューズが切れただけで済んでいれば... 部品が焼けるような異臭は無い。カバーを開けて、何が起きたのか見てみる。見た目で激しく焼損した部品は見当たらない。ん？電源基板の抵抗器の足下が黒いな。読み取り出来る IC の DATE code のうち新しそうなのは 1992 年 14 週か。28 年前に動いていたドライブなのか。こんなに古いといきなり電源 ON は危険なのかも。具体的に用心して「電源 ON」はどうしたら良いのだろうか？ なにも繋がず独立した状態、なるべく燃える物が無いところ、ブレーカー付きタップなどで保護された内側から電源を取り、少ない電流でトリップして幹線・分岐線をトリップさせないようにする。電源基板を外すため、ネジを外す。錆びていた。電解コンデンサの液漏れだろう。基板の銅箔とランドがカビたように緑黒く錆びている。電解液と残ったフラックスが融合したの？部品に電解液が染みついている。広範囲だ。こうなると 2 次側は殆どショートなのだろうか？あるいは、コンデンサに充電できないので、目一杯 1 次側の電流を増やして、過電流なのだろうか？弄っていると手がベタつく。ふいても手に付いてくる。基板に染みこんでいるなぁ。ヒューズ管が黒く曇っている。内側に丸く粒状になった金属が線状に並んで付着している。ああ、大電流で消し飛んだのか。ヒューズの電流定格は 3A、恐らく Fast Blow タイプ。3A 定格のヒューズが 1 秒未満で切れたのだから、一瞬 10A 以上は流れたのかも。3A を僅かに上回る程度で切れたならば、ヒューズの細線は形が残り、真ん中だけ切れるか、うで始めたスパゲティの様にしなった状態で切れる。外から 5V, 12V を供給すれば動くのかな。それとも、手持ちのメディアを読み終え(読むのを諦め)、使う目的が無くなるのか。
2020.07.28
コメント(0)
-
ハードオフでジャンク 640MByte MO drive を買う - 家の中では一番良く動くドライブかな
ハードオフでジャンク 640MByte MO drive OLYMPUS MO643U5 を買う、110 円でジャンク box に入っていた。そう言えば、手持ちの MO メディアは読めるのだろうか？一応、SCSI 接続のドライブは持っている。「予備になるかもしれない」機材が 110 円なら良いかな。足が取れているなぁ。後で代わりの足を貼り付けるか。ん？もしかして一度開けた？足が貼ってあった部分がシールになっている。綺麗に貼り戻したのかな？あっ、そうだ。MO メディアを見たことが無い人がいるかもなぁ。手持ちの 640Mbyte メディアを出しておこう。虹色に輝いている円盤を格納した四角いケースが MO メディアだ。この大きさで 640Mbyte を格納する。比較のため右上に 32Gbyte の Micro SD card を置いておいた。簡単に諸元を比較してみる。いずれも実測値、Micro SD の容量はメーカー品種によって違う。大きさは見ての通り、重さは比較していない。項目640M MO32G Micro SDSD / MO容量(bytes)635,600,89631,914,983,424約 50.21sequential read転送速度(Mbytes/sec)2.0192.1約 45.8テクノロジーの進化は驚異的だな。640Mbyte MO メディア 1 枚で 2,000 ～ 3,000 円くらいだったか。ドライブが 20,000 ～ 40,000 円くらいした。MO が普及していた頃に USB は無く、さらに SCSI Interface, cable, terminator も必要だった。SCSI 部分で 10,000 ～ 20,000 円くらいかな。今時 Micro SD card reader はメーカー製パソコンなら普通に付いているし、スマホに標準装備されている。無くても 100 円ショップで探せば 100 円で売っている。外観的な不具合は EJECT ボタンが引っ込んでいること、カラカラ音がすること(ネジが取れていた)、汚れがついていること。あー、AC アダプタで給電が必要か。調べてみると EIAJ 極性統一プラグ(RC5320A) 区分 2 で 5V 1.6A だ。適当な変換ケーブルを付けて供給しよう。ネジは 2 個の後ろ足の下にあるシールを剥がすと出てくる(自分が手にしたドライブは 1 個足が無い)。シール下からカラカラと音がしていた。ネジが外れた状態になったのは何でだろう。ポストが割れていた。これでネジが締まらなかったのか。反対側はポストの形が残っていた。良く見るとヒビが入っていて、手で軽く強度を確かめたら、崩れてしまった。丁寧にポスト再建？いずれパテとか使うのも慣れないとなぁ。ダサく養生テープで「仮止め」という恒久処置をして使うか。そのうちベタつくかカラカラに乾いて剥がれるかもしれない。ドライブに皮脂が付いているなぁ。やっぱり開けたのか。ハードオフ・ジャンクなのだ。普通にあること。ドライブは OLYMPUS MOS3393E で 2002 年 8 月製だと読める。製造から 17 年 11 ヶ月経過している。皮脂をパーツクリーナーで拭き取る。レーザー・ダイオードが劣化していることも考えられる。今後、書き込みで使う事は無いからレーザー強度は弱くなっていても平気かな。透明スモークパーツのポストの一部が割れて動く様になっていた。ボタンの支えも折れていた。スモーク・パーツとボタンの支えは接着剤で補強することにした。瞬間接着剤を使って見たけれど、ダメなんだよなぁ。盛れる接着剤の方が上手くいく。内部を補修して、養生テープでケースを留める。緑のアクセントがダサダサ・デザインだな。ダイソーで買った汎用の足も取り付けた。結局付けた足も余り役に立たない状況だったのが後で判る。手持ちにあった EIAJ 極性統一 DC プラグ区分 2 で電源供給ケーブルを作る。EIAJ 極性統一 DC プラグって RC5320A と言う規格名が付いているのか...電源 ON、Windows10 PC に接続する。アクセスランプが点いてディレクトリを読み込んだ。おお、Windows10 はまだ MO に対応しているのか。あれ？なんか変だな。MO メディアによって読める・読めないがある。読んだ内容も部分的に壊れている。なんか変な壊れ方だなぁ。MO メディアによってはドライブの挿入側を下にして読めるようになった。ハードオフ・ジャンク、この程度は中難度だ。データの壊れ方が... ECC による訂正限界を超えたのか。手持ちのドライブも動かしてみる。さらに問題が悪化した。機会が有れば別の日記に書くか。ディスク表面はホコリで汚れているし、拭き取ると砂埃でキズが付いてしまった。俗な環境と使い方だと 25 年持たないのか。
2020.07.26
コメント(0)
-
つかの間、スズメが池で水浴びするほどに雨が止む - 昼過ぎからまた雨
つかの間、スズメが池で水浴びするほどに雨が止む。空も明るくなり始めていた。洗濯物は外で干せるかな。既に部屋干しを始めていた。ほぼ外気温と同じ程度の 28 ℃で冷房して湿度を下げつつ、扇風機で風を当てて乾かす。スズメさん、散々雨が当たっていて水浴び状態だと思っていたのに。少し濁った水溜まりで水浴びするのが好みなのか。外で干せるかな... と思いつつ洗濯物は移し替えず、サボっていた。昼過ぎくらいに雨が強く降り出す。外で干せないなぁ。
2020.07.25
コメント(0)
-
キリギリス(ササキリの仲間)を見つける - 8 月くらい見られる虫？
近くでキリギリス(ササキリの仲間)を見つける。尻尾のさやが長いのでよく目立っていた。体長は触角を除き鞘を入れて 5 ～ 6cm ほど、触角も 5cm は伸びている。この大きさでキリギリスなんだ。大きいので調べる前はバッタかと思っていた。頭の部分が尖っていなく、どちらかというと丸まっているというか、絶壁スタイルなのでキリギリスの仲間だそうだ。ん？群生相には変化していないよな。緑色だし普通かなぁ。
2020.07.21
コメント(0)
-
OMRON D2FC-3M に CR を付けてみてチャタリングを押さえ込む実験 - 簡単ではなさそう
ELECOM Mouse M-XGL10DB の OMRON D2FC-3M に抵抗とコンデンサを付けてチャタリングを押さえ込めないか試してみることにした。D2FC-3M を検索すると通販が見つかる。なぜだろう、手を出しづらい。手持ちの部品でなんとかしてみよう。スイッチに並列してスパークキラー回路を付加する。抵抗とコンデンサを直列して構成した単純な回路だ。下の回路図で Mods と付けた囲みの中に入っている Rsk, Csk 部分に当たる。抵抗は 100Ω, コンデンサは 0.1uF なので、GPIO の Rup (Pull Up) 抵抗と合わせて約 15kΩ と考えると、時定数は 15kΩ x 0.1uF = 1.5ms だ。スイッチを押した瞬間の電流は Vdd ≈ 3.0V なので 3.0V / 100Ω = 30mA になり、スイッチの定格内に収まる。なんだな、色々と計算したところで、手持ち部品がいっぱいある 100Ω, 0.1uF を選ぶのは既定路線だった。付加回路無しで先に測っていた次の波形の様なチャタリングを十分に押さえ込めると考えていた。スイッチを押して離してみる。ん？付加回路無しだったときはパルス的な Off だったはず。1.38ms 程スイッチがチャタリングで Off になることが何回も発生している。かなり様子が違う。付加回路無しだとチャタリングで Off する時間は短い。接点に掛かる電圧が 3.0V 程でも接点間が放電して電流が流れるのか。付加回路のコンデンサでほぼ 0V に端子間電圧を維持すると、直ぐに消弧して接点間電流が途絶えるのだろうか？離し操作の部分も同じような変化だ。約 (3.0V * 0.6) = 1.8V に上昇するまでの時間は約 1.45ms なので、時定数はだいたい合っている。何回か 押し - 離し を試してみると、チャタリングで Off になる時間は 3.6ms になる場合も見られた。うーん、かえってクリックの反応を悪くするかも。2020.07.22 追記ELECOM M-XGL10DB 分解クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている D2FC-3M のチャタリングの様子を見てみる
2020.07.20
コメント(0)
-
クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている D2FC-3M のチャタリングの様子を見てみる - チャタリング除去アルゴリズムの限界を超えている？
クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている OMRON D2FC-3M がチャタリングを起こしているのか、波形を見ることにした。接点は機械なので、チャタリングは新品でもある。クリックをしたという状況判定に影響が出る程度のチャタリングかどうかだ。マウスの操作にダブルクリックがある。恐らく、2 回のクリックとして分離するかどうか、判断できない On/Off の繰り返し継続があると、反応が悪くなると考えられる。左ボタン周辺の回路を追ってみる。次の様な回路になっていると思われる。nRF24LE1E データシートと読み合わせて、不自然なところは無い。右ボタンも同様だと思われる。PDF の回路図、bschv3 ソースnRF24LE1E GPIO 端子に D2FC-3M の Normally Off 側を接続した回路だ。nRF24LE1E の pull-up 抵抗を On にして、マウスボタンを押していないときは High Level、マウスボタンを押したときは Low Level になる回路だ。pull-up 抵抗の線形性は良い。MOS FET のチャネル On 抵抗に良く見られる定電流特性は見られなかった。14.97kΩ の抵抗で pull-up されていると見なせる。スイッチの NO - Common 間 (GPIO 端子 - GND 間) の波形をスイッチのレバーを押して、離す操作をして観測する。操作毎に波形が違ってくる。何回か波形を撮ってみて、典型的な変化を取り上げる。左ボタン側の波形と右ボタン側の波形の全体を見てみる。左ボタン側右ボタン側左ボタン側の方にチャタリングが多く見られる。特徴的なのはスイッチを押した直後のチャタリングに加えて、約 5.4m ～ 15.3ms の範囲に後続するチャタリング、離したときに 12.3ms ほどチャタリングが継続した後、一端小さなチャタリングを含みつつ、押した状態(On 状態)で落ち着き、32.8ms 後に完全に離した状態(Off 状態)に遷移する。Off 状態に遷移する直前にもチャタリングが見られる。全体的に「押し」はダブルクリックと判別しにくく、「離し」は逆ダブルクリックあるいは、反応遅れになっている。クリック感覚が良くないと感じた状況をある程度説明できている。「押し」の状況はマウスの Firm ware に実装されたアルゴリズムが解れば理解できるのかも。チャタリングを起こしている状態は複雑だ。接点なので On と Off しか無いはずと思っていた。拡大してみると電気的には何かのインピーダンス素子で繋いだ様な状態になってる。ほぼ抵抗的だとは思う。パルス的に Off になる。波形の変化から、放電が一瞬止まる現象なのか？スイッチ周辺の回路で波形の様子は大きく変わる。別の日記でこのチャタリングを付加回路で押さえようとしたときの波形も触れようと思う。スイッチの変化を Both Edge (Interrupt On Change) で受ける場合、注意深いアルゴズム実装が必要そうだ。教科書的なアルゴリズムは N を定めて N 回同じ入力なら、安定したと見なすという素朴なアルゴリズムだ。それで上手くいく？ マウスの場合、ダブルクリック入力も考慮する必要がある。良好な状態の右ボタンの「離し」部分も、チャタリングが含まれていた。機械的な「離し」からどれだけ遅れての変化なのかは見えていない。スイッチ(接点)は奥深い部品だと思う。2020.07.22 追記ELECOM M-XGL10DB 分解OMRON D2FC-3M に CR を付けてみてチャタリングを押さえ込む実験
2020.07.19
コメント(0)
-
ELECOM M-XGL10DB 分解 - マウスクリック反応が悪くなる
使っていた ELECOM M-XGL10DB マウスの左ボタンのクリック反応が悪くなってしまった。次の様な症状かある。クリックしても反応しない離したタイミングが遅れるチャタリングかなぁ。購入記録は 2019/3/30 だった。いわゆるエルゴノミクスマウスだ。うーん、もう少しだけ大きめが良かったかな(買ったのは L サイズ)。親指に力が入ってしまう。手のひらがマウスの丘からずり落ちそうになり、小指が机上についてしまう、ついつい親指の付け根に力が入ってしまう。買って 1.25 年で不調になった。早いのか？遅いのか？ 分解してみて使われているスイッチが OMRON D2FC-3M だと分かる。D2FC-3M のデータシートは見つからず。近そうな D2FC-F-7Nのデータシートを読んでみると電気的・機械的に不具合が出ること無く 5,000,000 回の開閉ができると書いてある。使用状況を計算してみる。5 秒に 1 回クリック、1 日 16 時間使用、年中無休、使用期間 1.25 年(3600 * 16 / 5) * 365 * 1.25 = 5,256,000なるほど、不具合が出てもおかしくない使用状況なのか。ネジは足のシールに全て隠されている。Y ネジあるいは、ベンツネジ、個人的にはヤッターネジ(ヤッターマンってもうオジサンしか分からないよね)が使われている。カバーを開ける。ゴミが入っていた。使用状況そのままを記録しておく。基板と電池ホルダー、上部ボタン基板の間はコネクタを介して接続されている。組み立て、分解はしやすい。メイン基板は小さく作られている。モーションセンサーに遮光をするためと思われる不織布テープが貼られていた。ケースが青く光るのを避けたか、あるいは何か干渉する不具合があったのか？ マウス前方に点灯したことが無い LED がついているのと関係あるのかな？左右ボタンのスイッチに OMRON D2FC-3M が使われていた。D2FC シリーズの派生品だと思われる。マウスメーカー向け専用品らしく、データーシートは納品仕様書のコピーらしいものが見つかる。ワイヤレストランシーバーは 24AT01、丁度一致する型番は見つからなかった。機能、パッケージ、モーションセンサ PAW3212DB の応用回路例からNORDIC nRF24LE1Eかその互換品だと推測する。トランシーバーの基準クロックは 16MHz 水晶を使っていた。モーションセンサーを隠しているテープを剥がして、センサーの型番を見てみる。PAW3212DB だった。光った所を見たことが無い LED が 2 つ前方についている。何かのゲーミングマウスと共通基板になっているのだろうか？ここからの光漏れを防ぐためにセンサーに遮光テープが貼られている？基板の型名は EL017MR VG かな。M-XG や EX-G といった型名やシリーズ名と一致しない。基板裏面、かなり分かりやすく信号名がシルク印刷されている。スイッチの配線にテストランドが設けられている。接触痕は見当たらない。製造時テストはしていないか、開発時のテスト用だと思われる。うーん、洗浄は省略なのかなぁ。側面親指スイッチの基板を見ると、スイッチが 3 個乗る設計だ。天井に 1 個？一時期ホイールの手前側にスイッチを付けるマウスが流行っていたような... 中ボタンだったっけ？スイッチは HUANO 製、押したことが殆ど無いので耐久性、感覚は分からず。側面親指スイッチ基板裏をみると、天井用スイッチの配線もされている。修理？値段を調べてみると 1,351 円だった。買い直しかな。2020.07.22 追記クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている D2FC-3M のチャタリングの様子を見てみるOMRON D2FC-3M に CR を付けてみてチャタリングを押さえ込む実験
2020.07.19
コメント(0)
-
SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う
SMR HDD WD60EZAZ を買った直後に近い状態にするには、trim (Linux の command line で blkdiscard) を使う。あるいは mount option に discard を付ける。具体的には blkdiscard command を次の様にして使うと、HDD の全領域が trim される。# blkdiscard -v -p 16MiB /dev/sdXblkdiscard は ubuntu 16.04 以降で使える。util-linux package に入っているので、標準的なインストール構成なら使える状態になっているはず。-v は進捗表示をする指定、-p オプションで指定している値は trim (SCSI なら unmap) command 1 回につき、何 byte 分を実施するかと言う値だ。16MiB は 16Mibyte 刻みで trim を発行する指定になる。理想は SMR HDD の allocation unit の整数倍にするのが良いと考えられる。外部からは分からないので、1Mibyte ～ 32Mibyte 程度の間で良いと思う。小さくしても、許容できる実行時間で済むと思われる。blkdiscard 実行例: 対象 /dev/sdc WD60EZAZ, -p 16MiB, 実行時間約 214 秒(経過出力 1 行で 1 秒)/dev/sdX は trim しようとする HDD のノードだ。よく調べて指定して欲しい。WD60EZAZ の場合、trim すると block から読み出したデータは 0x00 の連続となる。実質的に消去になる。firm ware に直接 command を送って(送る手段があったとして) trim を取り消すなどの操作をしないと、データは復活しない。普段使いならば、mount option に次の様に discard を指定するのが良いだろう。/etc/fstab にも同様に記述できる。# mount -o discard /dev/sdXI /mount/pointlinux kernel 5.4.47 で file system が discard に対応しているか簡単に検索してみると btrfs, ext4, f2fs, fat(exfat), gfs2, jfs, nilfs2, xfs が対応している。主要な file system は入っている。種類が少ないので惜しいと思う人もいるかも。SMR HDD WD60EZAZ の trim command (discard あるいは unmap) の挙動は興味深い。色々と試した結果を書いていく。HDD の状態は前の日記でテストをした後の状態だ。ramdom read/write - sequential read x 1 - sequential {write and read} x 2 をした後だ。各操作の途中ディスク容量に対して 2 ～ 3% 程度のお試し read/write をしている。この状態で trim (blkdiscard) を全領域に対して、分割無しに実行してみた。blkdiscard command に device の node を指定するだけだ。# blkdiscard -v /dev/sdc/dev/sdc: Discarded 6001175126016 bytes from the offset 05 秒も経たないうちに blkdicard は終了する。ちゃんと trim しているの？多分 HDD の firm ware が back ground で処理しているのだろう。ほぼ 3 時間待って、sequential read の転送速度を測ってみた。グラフの縦軸は転送速度、横軸は進捗 0%: LBA=0, 100%: LBA=Last LBA だ。あれ？外周部分、分割構造境界だけ trim されている。trim された場所は平均で 400Mbytes/sec 出ている。3 時間放置ている。frim ware が動作時間の 100% を使って trim 処理を実行していたら、平均転送速度 150Mbytes/sec として、 150Mbytes/sec x (3600 x 3sec) = 1,620,000 Mbytes の範囲、割合に換算して 27% は trim された状態になっていると期待していた。綺麗に 0x00 で wipe するまでもなく、allocation unit に trim された範囲を追記するなら、もっと早いはず。当面の書き込み需要に応じるなら、trim する範囲は 10% 未満で十分というのも分かる。何だかなぁ。転送速度プロットの様にモヤモヤする。(2回目) 同じ blkdiscard command を実行して、6 時間ほど放置する。sequential read の転送速度を測る。16 ～ 17% くらいが trim された様だ。重ねて blkdiscard を実行すると、前の trim が取り消しになるのか、それとも 3 時間で 8% が back ground で trim されるのか。(3 回目) 同じ blkdiscard command を実行して、12.5 時間ほど放置する。sequential read の転送速度を測る。24 ～ 25% くらいが trim された様だ。一括の trim (blkdiscard) では直ぐに trim されないことは確かだ。転送速度が 400Mbytes/sec 出ていないところを狙って dd で読んでみると書き込んだデータが読める。そこを狙って trim するとデータは 0x00 になり dd の転送速度は上がった。blkdiscard 範囲を分割する指定 -p を付けて実行してみる。次に示す command line の太字部分のような指定だ。指定する値をいくつか試してみた。実行終了までに時間が掛かる。手応えがある。次の例のように 512Kibytes 分割だと見込みで約 4500 秒かかる。途中 ctrl-c で停止した。# blkdiscard -v -o $(( 0 )) \ -l $(( 6001175126016 )) -p $(( 512 * 1024 )) /dev/sdc-p に 512Mibyte を指定すると、23 秒で終了する。HDD の中で何か変化していると期待できる。全領域で sequential read の転送速度は 400Mbytes/sec 前後出る様になった。転送速度のブレが大きく、買ったばかりと違っている。trim command の動作は allocation unit に trim 範囲を追記するだけのようだ。read/write command に対して allocation unit を通しで読んでみて trim された記録が見つかったら、範囲を記憶し、trim 済みか判断する。次の read/write command に対して、trim された領域なのか、いくつか記憶した trim 範囲と照合してみて最適な動作を決める様だ。trim された後の sequential write の転送速度を測ってみる。CMR HDD に近い転送速度の傾向を示した。最外周で 200Mbytes/sec、最内周で 80Mbytes/sec 出ている。分割構造の特徴は見えにくくなっている。相変わらず中央の分割の後半で転送速度 130Mbytes/sec で底打ちする。謎なままだ。WD60EZAZ は都度細かく trim する使い方で性能が出る見込みがある。OS の file system に trim 指定を(Linux ならば discard 指定を)するか、自動で trim を積極的に使う環境ならば、CMR HDD に少し劣る程度の性能で使えるかもしれない。(注: ここで行った random read/write のテストは trim を使っていない)より具体的には大規模ソースの build 作業で生成される object file の様に create - write - read - remove の繰り返しならば、障害を引き起こしそうなアクセス速度の低下や応答時間の長期化は経験せずに済むと思われる。それでも CMR HDD とほぼ同等は無理そう。trim をせずに defrag したり、record file / data base の様にファイルの一部を read/write する使い方を続けたり、trim に対応しない RAID 構成で使うと、障害になるほどのアクセス速度の低下や応答時間の長期化が発生する可能性も分かった。SMR HDD WD60EZAZ の性質が分かってきた。この HDD を買った目的は何だっけ？ えーっと、バックアップ作業用に買ったはず。うん、バックアップを数分で消す blkdiscard の魔法を覚えた！SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果SMR HDD random read/write アクセス後の sequential read/write 速度
2020.07.18
コメント(0)
-
SMR HDD random read/write アクセス後の sequential read/write 速度 - 遅くなるなぁ
まず買ったばかりの SMR HDD WD60EZAZ の sequential read 速度を見てみる。縦軸は転送速度 bytes/sec, 横軸は 進捗で 0% が LBA=0, 100% が LBA=Last LBA だ。380Mbytes/sec 出ている。データシート上の最大転送速度は 180Mbytes/sec だ。実用上この速度は出ない。Trim された領域を read して出ている速度だ。File System を構成するならば、書き込んだことが無い領域を読むことは無い。読んだとしてクラスタ単位で操作する都合上で行われるはずだ。380Mbytes/sec は記憶媒体に律速されない AHCI SATA I/F - WD60EZAZ 間の最大転送速度を示していると考えられる。Trim されているので何回 sequential read を繰り返してもほぼ同じ結果になると考えていた。繰り返してみると、転送速度に僅かな変動が見られたり、瞬間的に(全容量に対して 2 ～ 3% 程度の範囲で)突如として転送速度が低下する現象がみられた。なぜ起きるのか良く分かっていない。買ったばかりなのに媒体上に不安定な領域でもあるのだろうか？あるいは、HDD の firm ware に使われているアルゴリズムが動作履歴に左右されやすい時間オーダーになっているのだろうか？先に行った random read/writeに続けて、sequential read/write をする。1 回目の sequential read は転送速度が進捗に対して 3 段階で変化した。各段階で最大転送速度と最小転送速度の差が大きい。比較的早い外周領域(0% ～ 33.3%)の範囲でも 90Mbytes/sec 差が有り、ほぼ 2 倍の振れ幅がある。振れ幅も密度に差が有り、allocation unit に沿うように転送速度が低下している様に見える。段階の位置を見るとほぼ進捗の 33.3%, 66.6% の所で段ができている。いかにも意図的な位置だ。大規模な分割構造がある様に見える。LBA で綺麗に 3 分割されているということは、媒体上では外周では細い環、内周では太い環に分割されているのだろうか？ さらに細かく分割して最適化を追求するよりは動作検証をしやすくした様に見える。1 回目のsequential write の転送速度(リンク先は続く sequential read を含む)を見てみる。「これは HDD なのか？」転送速度が波打つ様に変化した。分割構造の境界付近では最高転送速度は 200Mbytes/sec を越える。それ以外では IDE I/F 時代の HDD 程度の速度になった。外周部分で 30M ～ 70M bytes/sec だ。ULTRA ATA 33 ～ 100 が全盛で容量 20Gbyte ～ 100Gbyte の HDD がよく使われた時代に戻った感じだ。転送速度の変化も分割構造の前後で非対称だ。ヘッドを静定する時間がシーク方向に依存しているか、HDD 媒体上の allocation unit に未使用追記領域が無かった場合の空き検索アルゴリズムに方向性があるのか？特定条件を満たしたときにデーターシートスペック 180Mbyte/sec を出しているようにも見える。何が何でもスペックを出すような構造を設計した？分割構造の境界付近を「SMR 追記を早く行うための余剰領域」かつ「不良ブロックが発生した場合に代替利用する領域」にしているのだろうか？転送速度が速くなる進捗の幅が 3%, 5%, 5%, 3% となるので、何か意図的な割り振りを感じる。おおよそ HDD に書き込んだデータのうち、15 ～ 20% 位が書き換えられると想定して、追記未使用領域を用意しているのだろうか？あるいは運用中に不良ブロックが発生したとして、最大 20% 程の代替領域があれば、運用継続可能と想定している？そうだとすると SMR 方式は物理的な記録密度向上に対して、性能と耐不良ブロックのために払う代償も大きい。コスト競争が激しい製品で、差し引き 3 割り増しにもなれば大きいのも確かだ。全領域を Sequential write すればスッキリするのだろうか？ sequential read 転送速度が向上し、CMR 方式 HDD と同等と見なせる程度に転送速度のブレは減るのだろうか？2 回目の sequential read をしてみる。転送速度は全般的に向上した。分割構造の外周部で、205Mbytes/sec が出る様になった。転送速度のブレは依然として大きい。最外周の分割部分で転送速度の振れ幅は 70Mbytes/sec 程度、速度低下の機会はある程度減ったように見える。中央、内周分割部分でも転送速度は 10M ～ 20Mbytes/sec 向上している。気持ち速度低下頻度が下がったように見える。HDD 内の allocation unit をほぼカバーするような sequential write を行った積もりだった。write() システムコールに対して転送長 256Mibyte、Linux Kernel の BIO から AHCI driver 間の最大転送長は 30720kiByte (30Mibyte) にしている。HDD 上の allocation unit を綺麗に上書きで書き直せると期待していた。sequential read 転送速度の結果を見ると、依然として allocation unit に対して追記、溢れた場合は隣接 allocation unit に対する追記に振り替えている様に見える。2 回目の sequential write をしてみる。転送速度が波打つ様なことは無くなった。最外周の分割構造で、upper 205M ～ 200Mbytes/sec, lower 160M ～ 155Mbytes/sec の転送速度が出ている。ある程度 block 配置状態が整理された様に見える。依然として、転送速度に振れ幅がある。 奇妙なことに真ん中の分割構造で、転送速度の下限が 130Mbytes/sec 程に安定して底打ちする現象が見られた。原因は分からず。勘ぐった見方をすると転送速度調整をしている様に見える。外周側の分割構造でも、転送速度の変化が進捗に対して 5Mbytes/sec になっている。HDD に乗ったチップ内の DMA controller 速度を媒体記録密度とは別の調整パターンで設定している？マーケティング / ブランディングと言った大人の事情？3 回目の sequential read をしてみる。2 回目と比べて大きな変化は無い。分割構造の境界付近で転送速度が妙に遅くなったり、早くなるようなパターンは依然として残る。媒体上の場所毎に使い方が違うことを示唆している。WD60EZAZ は Trim command を受け付ける。何か変化があるから command として受け付けるのだろう。試してみるか。2020.7.15 22:50 追記: 手順の流れを明確化した。2020.7.18 追記: SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う
2020.07.15
コメント(0)
-
ヒグラシが鳴く - 19 時には静かになっていた
18 時過ぎヒグラシが鳴いているのが聞こえてきた。雨が降り、久しぶりに冷たく感じる風がふく夕方だった。雲が厚く、景色は早めに暗くなる。夕食の準備をしていたので、ゆっくりと耳を傾けなかった。食べ終わって 19 時、まだ鳴いているかな？と思い窓辺へ、もう鳴いていなかった。暑い夏は間もなくなのだろうか？
2020.07.13
コメント(0)
-
go to キャンペーンではなく do too (一緒に対策しよう)キャンペーン？ - できることも考えないと
ネットの書き込みを見たら、go to キャンペーンを誤記しているのを見つける。そうか、do too (一緒に対策しよう)か。それにしては機運が盛り上がらない。もっとスマートな衛生対策、生活様式、社会活動のあり方があるはず。大抵のことは世の中の片隅で細々と行われていたりする。探すと見つかるものだ。おかしいな、たしか 10 兆円くらいのよく分からない予備費を補正予算で成立させた様な... もう使っちゃったとか。
2020.07.12
コメント(0)
-
再び籠城体勢に - まだ店が静かなうちに行動しておく
新型コロナウイルスの感染が拡大している。数で見れば今まで以上に状況は悪化している。買い込み物資を点検して不足分を買い足すことにした。店の棚の状況を見るに、多くの人に慌てた様子は無さそうだ。先行して行動できる間はあと 3 日 ～ 1 週間くらいか。
2020.07.10
コメント(0)
-
少しの晴れ間に買い物へ - 夕焼け空を見て帰る
夕方くらいに雨模様の空が少し晴れそうだった。午後 17 時に家を出る。買い物で店を回っていたら、19 時を過ぎてしまった。久しぶりに見る夕焼けか。サーモンピンクに染まっている。隣に見える矢切線からはジリジリとコロナ放電の音が聞こえてくる。水分が多い雲と空なのだろう。秋雨の晴れ間とも感じる空だ。夏至を過ぎている。夕方に行動できる時間も段々と短くなるのか。
2020.07.08
コメント(0)
-
アブラゼミが鳴き始める - 今年は早いのかな
16 時頃、雨は一時的に止み、南風の強風が吹き続ける。どこからかアブラゼミの鳴き声が聞こえてきた。風に吹き飛ばされて、揺れるように聞こえる。梅雨の真っ最中、まだ出てくるには早かったか。17 時、また小雨が降り出した。蝉の声聞こえなくなっちゃったな。
2020.07.07
コメント(0)
-
マイナポイント混乱するかもなぁ - 残念、みどすけ君は 9 月から
親に「マイナポイントを登録したいのだけと」と相談された。親のところには IC カードリーダーが無い。マイナポイントのサイトを見てみると、コンビニとかスーパーにあるキヨスク端末でできそうだけどなぁ...カードリーダーを持って行って、作業を手伝おう... 練習がてら自分の所で試してみる。あれ？ SMBC デビットカードを登録できない。マイナポイントサイトには出ているしなぁ。決済サービス選択で見つけることができない。キーワード無指定で決済サービス区分を全選択しても、サービス一覧に出てこない。もう一つページを潜ってみて、SMBC デビットカードの説明をよく読んでみる。あっ、「申込開始日 2020年9月1日から」と書いてあった。3/4 ほどスクロールするとやっと出てくる表に書いてある。まだ登録できないのね。隠すことでも無しと思う。んー、でもなんだな。URL を良く見ると... "MP0000166" これって、登録に使うコードでは？「登録サービス番号」にも MP0000166 と書いてあるしなぁ。登録キャッシュレス決済サービスページにある表には 三井住友カード株式会社 三井住友カード / ＳＭＢＣデビット の行に "決済事業者番号 M0038" と書いてあって、紛らわしい。残念、ページを印刷してマイキーIDを控えておくか... あれ？紙に印刷されない。PDF に出力しても印刷されない。スクリーンショットか、手で書き写すしかないのかなぁ。再ログインで マイキー ID を入力する場面はなかった。マイキーID は何に使う？IC カードリーダーを持って、親のところに行ってみる。majica を登録したいらしい。やっぱり登録できない。マジか...コンビニかスーパーに行かせてたら... たぶん端末の前で 1 時間くらいは立ち往生だった...
2020.07.04
コメント(0)
-
大きなクワガタムシを見つける - 一回り小さいカブトムシくらいの大きさ
久しぶりに買い物に出る。怪我をしてから、外出はゴミ捨てなどごく近隣に限っていた。大きなクワガタムシを見つける。多分クワガタムシ、かなり大きい。一回り小さい雌のカブトムシ？と思うくらいな大きさだ。口の形からクワガタかな？温暖化の影響で昆虫も大型化して、夏の早いうちから飛び回るようになるのだろうか？
2020.07.03
コメント(0)
-
x86/x86-64 arch で cache flush 関数を試しに実装してみる - kernel の実装を持ってくる
Linux の Userland で cache flush をしたくなったので、x86/x86-64 アーキテクチャ上で cache flush 関数を実装してみる。Linux kernel 内に有った実装をほぼそのまま持ってくる。#include <stdint.h>static void clflush(volatile void *p){ asm volatile("clflush %0" : "+m"(*(volatile uint8_t *)p));}clflush ソースkernel から持ってきた理由は、検索をしていたらcacheflush() system call が見つかったからだ。kernel source を調べてみると x86/x86-64 アーキテクチャではこの system call は無い様に見える。特権を持っていなくても、CLFLUSH 命令は使えるからだろう。試しに使ってみるコードを実装する。#include <stdint.h>#include <stdio.h>#include <string.h>static void clflush(volatile void *p){ asm volatile("clflush %0" : "+m"(*(volatile uint8_t *)p));}const char hello[] = "Hello world.\n";void MainB(char *buf){ memcpy(buf, hello, sizeof(hello)); clflush(buf); fputs(buf, stdout);}int main(int argc, char **argv, char **env){ char buf[128]; MainB(buf); return 0;}clflush テストコード全体逆アセンブルしてみる。まぁ、まぁ、綺麗に inline でオブジェクトコードが生成されていた。0000000000400620 <MainB>: 400620: 48 b8 48 65 6c 6c 6f movabs $0x6f77206f6c6c6548,%rax 400627: 20 77 6f 40062a: c7 47 08 72 6c 64 2e movl $0x2e646c72,0x8(%rdi) 400631: 48 89 07 mov %rax,(%rdi) 400634: b8 0a 00 00 00 mov $0xa,%eax 400639: 66 89 47 0c mov %ax,0xc(%rdi) 40063d: 0f ae 3f clflush (%rdi) 400640: 48 8b 35 09 0a 20 00 mov 0x200a09(%rip),%rsi # 601050 <stdout@@GLIBC_2.2.5> 400647: e9 74 fe ff ff jmpq 4004c0 <fputs@plt> 40064c: 0f 1f 40 00 nopl 0x0(%rax)より良い使い方は、前後にmemory barrierを使う。cache line size も /proc/cpuinfo から拾わないと。clflush size : 64cache_alignment : 64
2020.07.02
コメント(0)
-
SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果 - Android, Linux Kernel, yocto ソースコードを格納して build するのは向かないかも
SMR 記録の HDD WD60EZAZ を Linux で使うには BIO (Block IO request) のタイムアウト設定 /sys/block/block_device_name/queue/io_timeout に 240000 (240秒) を設定すれば sync() でハングせずに使えそうなことが分かってきた。設定値は kernel が管理する cache 量、稼働中に想定される単位時間当たりの書き込み量、頻度に依存すると思われる。主記憶サイズ 24Gibyte での値だ。ランダムアクセステストの結果に気になる傾向があったので、記録に残しておく。ランダムアクセスの分布は LBA: [0..MaxLBA] = a*random(), Length: [4096..512Mibytes] = exp(l * random()) bytes となる様に a, l を定めている。read, write はほぼ半々になる様に混在させている。ランダムアクセステストをする前に行った HDD アクセス履歴の概要を書く。最後の全 block 連続書き込みから、次の表の様にランダムアクセスをした状態だ。6Tbyte に対して、221266 回 write のランダムアクセスをしている。テスト前のランダムアクセス数Read / Write回数Read220113Write221266テスト後のランダムアクセス数Read / Write回数Read269244Write270439均等に分散しているアクセスだと仮定すると 6Tbyte / 221266 ≒ 27,121,994 (27Mbyte) 程度の範囲に 1 箇所はランダムアクセスをして乱れがあるはずだ。厳密にはアクセス長分布は 512Mibyte まで有るので、27Mbyte 丸々上書きされている場合もある。意外と疎な感もある。OS の Cache を使わずに Read/Write Random Access をした結果から、Read のアクセス時間と転送長の関係をプロットしたグラフを見てみる。最小 Read Turn Around Time は約 8ms だった。Seek time + Rotation 待ち時間として考えられる。気になるのは、アクセス時間の分布がいくつかの帯に分かれることだ。構造を示すような資料は見つからなかったので推測で書く。HDD の記録面は4Mbyte 程の CMR Allocation Unit10M ～ 30M byte 程度の単位で管理された Small SMR Allocation Unit200M ～ 300Mbyte 程度の単位で管理された Large SMR Allocation Unit (Small SMR Allocation Unit をまとめたか、あるいはさらに高密度記録を行っている)といった階層的な構造になっている様に見える。シーケンシャルアクセステストの結果から、ドライブ全体を 3 分割する構造も見えている。SMR HDD らしい所は転送長が 1Mbyte 未満の所で、Access Time が 8ms ～ 300ms 程度の幅があることだ。最小アクセス時間と最大アクセス時間の比は 37.5 倍になる。細かいアクセスが多発する場合、総アクセス時間の予測をしにくい。Small SMR Allocation Unit も Large SMR Allocation Unit も追記を行っていく構造になっていると思われる。2020.06.29 加筆 書き込みをした場合、LBA, (新しい書き込みだと印を付ける)SerialNumber, block data を組みで追記し、プラッタ上の LBA の並びは追記順になっている様に見える。SMR 記録された track を読んでいって、読みたい LBA の最新が見つかるまで、シーケンシャルにアクセスしていると推測する。Write のアクセス時間と転送長の関係をプロットしたグラフを見てみる。条件は先ほどの Read 同様 OS の Cache は使わない。最小 Write Turn Around Time は 140us 程になっている。10Mbyte 程の書き込みまで多くの場合 転送速度は 400Mbyte/sec だ。SATA-III I/F の転送速度 6Gbps の上限に近い。プラッタに書き込まず、HDD 基板上の半導体メモリに格納したら、転送完了している様に見える。もし、電源断になったらどうするのだろう？プラッタとスピンドルモーターでフライホイールを構成して、Flash Memory か特別な磁気媒体領域に書き込み終わるまで、電源供給無しに動作し続けるのだろうか？実効的な HDD の cache size は 10Mbyte 程に見える。WD Blue Data Sheetには 256Mbyte と表記されているので 10Mbyte x n tansaction の様に使っているか、Small/Large SMR Allocation Unit の再構築に使っている可能性がある。転送長に対して顕著にアクセス時間が長い場合が見られる。アクセス時間からして Small/Large SMR Allocation Unit を再構築しているのでは？と考えられる。追記ができなくなった場合、近隣の Allocation Unit に追記するか、それも出来なくなった場合は、再構築をするのだろう。このグラフからは読み取りにくい。HDD を休ませることなく連続してランダムアクセステストを実施していると、次の様なグラフに変化する。分布がより鮮明に現れ、転送長が 512Mibyte の場合のアクセス時間は 7 ～ 10 秒だったのが、45 秒程に変化する。連続してランダムアクセステストを実施していると、read もアクセス時間が変化する。転送長が 1Mbyte 以下で 8ms でアクセス完了する場合が減る。Small SMR allocation Unit から読んでいると思われる 300ms 程のアクセス時間になる。転送長が 1Mbyte 以上の場合も、Large SMR Allocation Unit を 2 つ跨ぐ様なアクセス時間に変化している。対数グラフで一マス上なので体感的に速度は 1/5 ～ 1/10 程度に下がってしまった様に感じるかも。OS の cache を使った場合のアクセス時間と転送長の関係を見ていく、Read の方は、Queue に溜まった transaction が完了するまで待つ場合が出てくる。待つ場合は 100Mbyte/sec 出ている転送速度が 3Mbyte/sec 程度まで低下した様に見える。最大で 30 ～ 40 秒待つ場合が出てきている。アプリケーションによってはフリーズしたような体感になる。連続アクセスを続けていると、待ち時間はさらに長くなる。200 秒ほどの待ちになる。先行する write transaction が完了するまでの待ちだと考えられる。これが、冒頭で触れた「タイムアウト設定 /sys/block/block_device_name/queue/io_timeout を 240000」にしようと考えた背景だ。OS の cache を使った場合の write は、順調に OS の cache に格納して完了している。転送速度が 2Gbytes/sec と 3Gbytes/sec に別れる原因は探っていない。OS の cache 管理構造が原因なのか、主記憶が 24Gibyte なので Memory Bus の channel 構成が非対称なのが原因なのか。ランダムアクセスですっかり遅くなってしまった SMR HDD WD60EZAZ のアクセス速度を回復する方法は有るのだろうか？2020.7.16 追記: SMR HDD random read/write アクセス後の sequential read/write 速度2020.7.18 追記: SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う2020.7.18 追記: Android, Linux Kernel の様な大規模ソースを格納して build 作業に使う場合、mount option discard (trim) を付ければ hang up に近いような応答時間にならずに済むかもしれないことが分かった。それでも、ランダムアクセスは性能的に不利だ。積極的には build 作業に使わない方が良さそう。
2020.06.28
コメント(2)
-
SMR の HDD を Linux で使うと sync() で hang するかも - Waiting in uninterruptible disk sleep
SMR 記録方式の HDD WD WD60EZAZ を linux (Lubuntu 20.04)でベンチマークテストしている。ベンチマークプログラムが kill -9 (SIGKILL) も効かない状態でハングする。ランダムアクセステストで kernel の cache は有効な状態、ベンチマークプログラムは root 権限で動作している。raw block device をアクセスするためだ。ps uaxwwでハングアップしている状態を見てみる。STAT が DL+ となった。"Waiting in uninterruptible disk sleep" (割り込み不可の状態でディスク I/O 完了待ち)だ。$ ps uaxww | grep ssdstress &34176 0.0 6.4 1576728 1574484 pts/1 DL+ 613 1:30 ./ssdstress -f 6001175126016 -pn -xb -rn -my -b 4096 -i 1 -a 131072 -i exp -n 24576 -u 65536 -dn -dY -s 20200614 /dev/sdcroot 権限でプログラムを動かしたとしても、uninterruptible 状態が長時間続く様な動作を kernel がすることはまずあり得ない。Linux Kernel で uninterruptible あるいはその逆の interruptible というのは誤解を招きやすい表現の一つだ。この場面において、純粋に「割り込み (interrupt) を受け付けない」という意味ではなく、Userland process が呼び出した「system call 処理中に signal を受け付けない」状態ということだ。どんな signal も受け付けない。signal 9 (SIGKILL) も含まれる。/proc/pid directory 内にあるいくつかの process status を見てみる。stat と status も D stateで止まっていることを示していた。/proc/34176 # cat stat34176 (ssdstress) D 34175 31200 31057 34817 31200 4194560 393297 0 1 0 6180 2875 0 0 20 0 1 0 23546681 1614569472 393621 18446744073709551615 94412556185600 94412556207685 140733693111200 0 0 0 0 0 0 1 0 0 17 3 0 0 3976146 0 0 94412556225760 94412556226828 94412566093824 140733693114159 140733693114281 140733693114281 140733693116396 0/proc/34176 # cat statusName:ssdstressUmask:0022State:D (disk sleep)Tgid:34176Ngid:0Pid:34176PPid:34175TracerPid:0Uid:0000Gid:0000FDSize:64Groups:0 -- snip --ps コマンドで得た情報は確かだ。ベンチマークプログラムはどこまで進んでいたのだろうか。ログ出力が途切れていたので、活動状況を類推できる fd/* file descriptor 使用状態(open している状態)を見てみる。/proc/34176/fd # ls -latotal 0dr-x------ 2 root root 0 6 13 15:46 .dr-xr-xr-x 9 root root 0 6 13 15:46 ..lrwx------ 1 root root 64 6 13 15:46 0 -> /dev/pts/1l-wx------ 1 root root 64 6 13 15:46 1 -> 'pipe:[233565]'l-wx------ 1 root root 64 6 13 15:46 2 -> 'pipe:[233565]'stdin, stdout, stderr だけだった。ほぼプログラムは終了している状態と考えられる。ん？ stack ってなんだ。system call を発行してから kenel 内でどこまで進んでいるか見ることができる call stackだった。/proc/34176 # cat stactk[<0>] submit_bio_wait+0x60/0x90[<0>] blkdev_issue_flush+0x94/0xd0[<0>] ext4_sync_fs+0x15d/0x200[<0>] sync_fs_one_sb+0x23/0x30[<0>] iterate_supers+0xa3/0x100[<0>] ksys_sync+0x62/0xb0[<0>] __ia32_sys_sync+0xe/0x20[<0>] do_syscall_64+0x57/0x190[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9各 kernel 関数のリンク先は Lubuntu 20.04 で使っている 5.4.0-37 に近い5.4.47 のソースにリンクしている。sync() を起点として submit_bio_wait で止まっている。「まぁ、そうだろう」と思う状況だ。真に止まっている場所は submit_bio_wait 内から呼び出した wait_for_completion_io か少し進んだ先のはず。ここで、TASK_UNINTERRUPTIBLE 状態で止まるように wait_for_common_io を呼び出している。signal を受け付けない訳だ。厄介だ。call stack の流れは、ext4_sync_fs を経由している。ハングアップの真の原因を作ったと推測している raw block device access と違う。raw block device access と ext4 file system を格納しているドライブに対する access が何処かで queue なり fifo を共用している？ 同じ SATA controller に繋がっているのだ。システム全体が停止してしまう可能性を示唆している。この現象が出た後、reboot できない。途中で途切れてしまったベンチマークテストの結果を見てみると、kenel cache を経由したアクセスで、完了まで 100 秒以上経過している場合がある。63 回だ。出始めの SSD に良く見られたプチフリーズとよく似ている。より悪い挙動かもしれない。Linux kernel 5.x から/sys/block/block_device_name/queue/io_timeout と言う ms (ミリ秒) 単位でタイムアウトを設定できるノード(リンク先は kernel 内の store 実装)が増えたようだ。各 Controller 毎にバラバラに実装されていた timeout を統一的に扱うノードなのだろうか？ SSD や SMR HDD といった癖があるデバイスが増え、実装する機運が高まったのかも。一方で各 Controller 毎にあった複雑な事情を吸収しきれず、complete しないゾンビののような BIO request (Block IO request) が生じやすい？io_timeout ノードの設定を変えて SMR HDD を使えるようにできるだろうか？ なんだな、筋が悪い予感がする。以前プチフリ SSD を Linux で使うのを断念している。よく似た状況だ。
2020.06.23
コメント(0)
-
喉が渇く、体がじんわりと痛い、作業が続かない - 怪我の症状かな
怪我の症状だろうか？喉が渇く、外傷・内出血がないところもじんわりと痛むところがある。作業が続かない。大人しくしているか、体を横にしていた。一番大きな傷は横 3 cm, 縦 2cm 程の楕円形の形だ。リンパ液が浸出して、固まらない状態になった。長くなりそうだ。
2020.06.21
コメント(0)
-
感染したのかな - 自電車で転び怪我
自転車走行中に転ぶ。怪我をしてしまった。画像が苦手な方がいたら申し訳ない。傷口から感染したのかな。
2020.06.20
コメント(0)
-
しばらく日記をサボっていたわけ - プログラミングスキルチェックサイトに没頭していた
ここしばらく、日記がサボりがちになっている。プログラミングスキルチェックサイト(Paiza)に没頭していた。100 点は目指さない。「好きにプログラムを作ってみよう」。という姿勢だ。もう少し「好き」を具体的に書くと、問題文ある入力範囲の制限はできるだけ取り除くあまり面倒でなければ Secure coding をしてみる入力エラー、内部ロジックエラー、メモリ不足など不意な状況もなるべく検出する時には over kill のアルゴリズムを投入してみる。そして、逆もあり素朴でのんびりと動くアルゴリズムで臨むこともするちゃんと動くことを目標にする。時間が掛かってもよいから、テスト入力は 100% 期待値と一致させる「たまには bash で...」と思ったら、まだちゃんと動いていないみたいいくつかの問題で統計された正解率が極端に低い問題が有った。なんでだろう。試しに解いてみることにした。おおよそ次の傾向があることが分かってきた。そもそも問題文に誤りがある入力に可変要素がある(特にテキスト入力の列方向)ステートマシンの様に内部記憶をもち、それを順次変化させる必要があるマシンイプシロンなど環境に依存性があり、作ったコードが題意を満たすかどうか証明するのに時間がかかる(マシンイプシロンは DBL_EPSILON などで取得可能だ。厳密にいえば環境依存なので、調査する必要があるし、値をなるべく真値に近く扱える実装が必要だ)全部言及すると長くなる。何かネタが無い時の機会に回そう。「そもそも問題文に誤り」は出題側は気付かないのだろうか？正解率は低く回答時間が長い。他の問題の傾向と比べて突出してる。しばらくして、「何かおかしい」と気付くはずだ。表に出す前(本番環境稼働させる前)に、レビュー、テストを十分にするのが教科書に書かれていることだ。誤りもそれほど難しい論理証明をせずとも発見できるものだった。どうやって問題作ったのかな。何も考えずにどこかのサイトのコピペ？ コピペ技術者で十分というのはちょっと悲しいな。
2020.06.20
コメント(0)
-
dmesg (kernel long) に予兆が出ていたのか - スイッチングハブが壊れた
スイッチングハブが壊れた時に「あれ？ネットワーク」とふと思っていた。他に仮定できるいくつかの原因が有ったはず。故障した HUB に接続しているlinux PC の dmesgを見直してみたら、故障の兆候が記録されていた。[511464.633473] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx[511465.026759] r8169 0000:05:00.0 enp5s0: Link is Down[511467.505506] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx[511467.891947] r8169 0000:05:00.0 enp5s0: Link is Down[511484.046647] r8169 0000:05:00.0 enp5s0: Link is Up - 100Mbps/Full - flow control rx/tx[511484.614987] r8169 0000:05:00.0 enp5s0: Link is Down[511744.850145] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx故障する前に見ていた。「高頻度で接続・切断の繰り返し、Ethernet link の調子が悪いけどなんだろう？」程度にしか思っていなかった。「繋がっているしな...」とログに記録された兆候を見逃していた。Ethernet HUB を「動いている」時に積極的に外すことはしない。経験として、ネットワークから HUB を(あるいは HUB から PC を) 10 秒程度切り離しても、つなぎ直せば平然と TCP/IP のコネクションは維持されつづけるし、UDP だって何事もなかったように続行する。上流 HUB から常用/予備のケーブルが伸びていれば、HUB の予防交換をしたかもしれない。予備 HUB を予備ケーブルでネットワーク基幹に繋ぎ、故障 HUB に繋がった機器類を 予備 HUB へ移していけば、何事も発生しない 10 秒の空白時間で保守ができる。ケーブルを抜いて挿す時間だ。引っ越す前は常用/予備のケーブルを張ってあったんだよなぁ。兆候の表れ方も解ったし、こんど似たような現象に遭遇したら、保守計画を考えることにしよう。あっ、考えると壊れる謎ジンクスがあったな。考えないことが一番の予防？
2020.06.19
コメント(0)
-
スイッチングハブが壊れた - 予備に置き換えた後に修理してみる
あれ？ 第 2 サーバーにアクセスできない。第 2 サーバーは主に http proxy と各種のバックアップを担っている。ping, ssh を含めて、ネットワークアクセスができない。サーバー本体を見てみると、いつも通りな発光パターンで HDD アクセスランプが点滅している。なんというか、不定期なんだけど、ログを吐いたり、Page In するようなリズムがある。リセットボタンに伸ばした手を引っ込める。少し視界を広くし、HUB を見てみる。あれ？電源ランプ以外は消えている。イーサーネットケーブルを抜き差ししても、ポートランプは点かない。電源を入れ直してみる。投入直後の LED 全点灯動作が起きない。HUB 壊れたのか。予備の HUB に置き換えてネットワークアクセスは復旧した。壊れたと思われる HUB を試験しやすい場所に持って行く。下の画像で左側の HUB だ。Port 1 にケーブルを接続しても、port ランプは点かない。なんだな。仕事先に持ち込んで、引き上げた HUB が休眠している。運用に支障はない。動作比較用に並べた右側の HUB は接続したポートのランプが期待したネゴシエーション状態で光る。ポート 1 ～ 8 を動作試験、全て接続しない。交換前に確かめた状態は再現する。購入記録を確認してみる。2008/5 に購入していた。購入後直ぐに使い始め、停電・引っ越しなどの特別な状況以外は通電し続けている。12 年間使えば壊れても仕方無しだな。7,280 円か、今時買うと、3,000 円でおつりがくる。買った当初は機能的に 3 世代くらい進んでいた。第 2 世代で Jumbo Frame 対応、第 3 世代で省電力化がテーマだった様に記憶している。ほぼ全ポート何かの機器に繋がることになるのに、省電力化に惹かれたんだっけ。分解しよう。底にネジが無い。前面パネルシートの裏にネジが隠れていた。No.1 + ドライバーに嵌まるネジを使っていた。ケースは最大で 11 port あるいは、10 port + インジケーター 2 個までの製品と共通だった。塗装剥げが汚く見えるなぁ。どうしようも無かったら、ラベルテープでダサく作り直すか。電源ユニットのコンデンサ劣化だ。左下に見える黒スリーブのコンデンサ 2 個が膨張していた。起動時 LED 全点灯せず、全ポート接続できない状況と整合する。出力が 1 系統しか無いのにコンデンサ 2 個が膨らむ？膨らみ方も違う。基板パターンを追うと、この 2 つのコンデンサは並列接続されていた。隣接する整流ダイオードの発熱影響の差かな？封止ゴムが弾けそうになるまで膨らむのか。仕様は 10V 1000uF 低直列抵抗型。部品箱に転がっていた東信工業 UTWRZ 10V 1000uF に交換する。そう言えばこれを買った千石電商はご無沙汰している。コロナウイルス流行でどうなっているのだろう。基板にはコンデンサの - 側に白いマーキングが付いていた。少し熱で焼けている様に見える。電解液による汚損は気にならない程度か。2 次側の回路定数を読んでみる。高精度抵抗は 16.0kΩ(1602) と 5.76kΩ(5761) か。TL431 型のシャントレギュレータを使っているとして、出力電圧 Vout = ( 2.495V / 16.0kΩ ) * (16.0kΩ + 5.76kΩ) = 3.39V 位なはず。再び組み立てる。うーん、プラスチックネジ締めにくいなぁ。動作確認してみる。電源投入時に LED 全点灯動作し、ポートに接続してポートランプも期待するネゴシエーション状態で点灯する。交換した電解コンデンサも破裂せず。ん？そう言えば電源の出力電圧確かめたっけ？またバラして確認してみる。3.395V は回路から読み取った値に近い。画像をクリックすると、動画をダウンロードして再生します。あれ？ 3.412V に上昇する？AM ラジオを近づけて、動作音を聞きながら電源電圧を測定する。ああ、なにもケーブルを接続しなくても、何かの動作/休止を繰り返しているのか。画像をクリックすると、動画をダウンロードして再生します。HUB から出るノイズと同期して電源電圧が変動する。2 次側出力に 2000uF (= 1000uF x 2) も負荷していれば、負帰還の Loop Gain は高くできないよなぁ。想定できる変動なのだろうな。修理記録のラベルを付けて、おもちゃ箱へ入れる。
2020.06.18
コメント(4)
-
ひなたぼっこカメ - 川の中から出てきたの？
自転車で川岸を走っていたら、カメが道で止まっていた。ちょっとひかれそうかな？多分カメだよね。カメには迷惑かもしれないけれど、舗装されていない道端へ移動する。あれ、水が出てきた。川の中に居たのかなぁ。手を洗わないと。
2020.06.15
コメント(0)
-
ボヤ騒ぎ？ - 元社員寮を改修した老人ホーム
消防車がサイレンを鳴らして近くを通るのを見る。朝から何事だろうか？サイレンの音は遠くへ消える前に止まっているように聞こえてきた。消防車が集まっていた場所は元社員寮を転用した老人ホームだった。社員寮転用型の老人ホームはよく見かける。若いころは社員寮に住まったこともある。老人にとって快適か？というと、何かと不便な気もする。衣服と食器の洗い物がやりずらかったっけ？ベランダも狭かったり、手すりが低かったりで危なかったような。写っている建物はアパートくらいな設備になっている。医療・衛生施設や、共用部清掃、各部屋・人の世話人の部屋も確保しずらい構造だった。そういえば自分が社員寮に住まっていた時も、ボヤ騒ぎが有って廊下に置いてあった消火器を手に取り駆けつけたことが有ったっけ？ 消火器を持って駆けつけたの、自分くらいだったような。うーん、寮に住んでいた時勤めていたのは、工場がある会社だったんだよなぁ。訓練では... (1) 消火用機材を持って駆けつける (2) ベルが鳴ったらすぐ逃げる (3) 館内放送・指示があるまで仕事を続ける どれだったっけ？
2020.06.15
コメント(0)
-
暫く衣類・布類のリサイクル中止 - 新型コロナウイルスの影響
市内の掲示板に「衣類・布類のリサイクル中止」のお知らせが貼られていた。新型コロナウイルスの影響でリサイクル先の業務が停止が停止していると説明されている。リサイクルに出す前に洗濯しているのかなぁ。とか、色々と気になることはある。「しばらくは自宅で保管しておこう」。うん、かなり長く保管しているな。たまにウエスとか緩衝材に使って減っていく。
2020.06.10
コメント(0)
-
もう 1 枚壊れたメモリが増えた - CFD Elixir D2U800CQ-1GLZJ
保管していたマザーボードを出してきて動作試験をしていた。可能で有れば稼働しているマシンの性能が少しでも上がればと思い、入れ替え予定だった。Ubuntu 20.04 amd64 を起動すると、なぜか kernel log に stack dump が出る。しばしば GUI ログインまで辿り着かずにハングアップする。memtest86+ でメモリをテストしたら、エラーが見つかった。1 ビットのエラーで症状が複数出る？ memtest86+ でテストを暫く続けていたら、さらにエラーが出てきた。64byte 毎で、bit30 か。行線切れ？立て続けに不良メモリが見つかる。また CFD Elixier だ。基板の色は紺色、ロットが違っても品質はイマイチなのか。CFD のページを見ると、Elixir ブランドの扱いは DDR3 で終了していた。何か有ったのかなぁ。過電圧も、高クロックも掛けずに普通に使っていたのにな。
2020.06.09
コメント(0)
-
謎の ASRock SATA3 Card をいまさら使う - LED 点かないなぁ... では改造
6Gbps の SATA3 I/F を使う必要が出てきたので、SATA3 の PCIe 2.0 I/F カードを探す。出てきたのは ASRock SATA3 Card だった。Bridge chip に Marvell 88SE9123 を使っている。LED 端子が付いているので LED を付けてみる。LED が点かない。Linux で lspci を使い 88SE9123 が存在する PCI bus の場所の当たりを付ける。# lspci-- snip --02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 10)02:00.1 IDE interface: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 10)-- snip --AHCI の CAP.SAL ("HBA Capabilities"."Supports Activity LED" bit 25) を ahci_host_caps ノードから読み出してみる。root@paperbox:/sys/devices/pci0000:00/0000:00:02.0/0000:02:00.0/ata9/host8/scsi_host/host8# cat ahci_host_capse237ff21LED が点く仕様だ。どうしてなんだろう？基板のシルクも少し謎だった。"HDLED-_CHA", "HDLED+_CHA", "LED-_MB", "LED+_MB" と LED ピンヘッダ周りに打たれている。「変だなー」と思いつつ、ネットを検索する。ユーザーレビューなどを読んでみると、マザーボードから出ている HDD LED と並列にするらしいことが判った。思い出してきた。買った時に両端が receptacle のケーブルが添付されていたような。購入した時に撮った画像を探してみる。有った。撮影日 2010/4/5、「こんな古い物を」、買ってから 10 年以上が経過している。同時に撮影して置いたパッケージには、"ASRock SATA3.0 card for ASRock P55 series" と書かれたシールが貼られていた。特定 mother board 向けだったから、バルク品販売(ジャンク)になってしまったのか。「変だなー」と悩んでいたときに回路を追っていた。次の様になっていた。回路の原図(bsch v3)。あっ、ピン名が基板のシルクに打たれた名前と違うな... "CASE_LED_N"="HDLED-_CHA", "CASE_LED_P"="HDLED+_CHA", "MB_LED_N"="LED-_MB", "MB_LED_P"="LED+_MB" と読み替えて欲しい。SATA card 単体で LED を光らせるつもりだったので、基板に手を加えることにした。LED 未実装 LED4 の Anode 側 (LED4_P) が常に 3.3V だったので、ここから電源を 330Ω を通して引き、LED を点灯することにした。LED1, LED3, LED4 空きランドから、2.54mm ピッチピンヘッダに配線を延ばす。LED4 から延ばすだけで十分だと判ったのは後からだった。配線は裏側で止めて置いた(下の画像は止める前)。干渉する様な大型グラフィックカードは持っていないので、これで良しとする。HDD を接続して LED を点けてみる。おおー、点いた。330 Ωだと少し暗めかな。無理はしないでおこう。アクセスしていないときは消える。今時 SATA3 I/F なんて Mother board に標準で付いているし... そうなんだよね。新しいマザーボードに、CPU に、メモリに... 「買いたいスイッチ」は今のところ off のまま。
2020.06.08
コメント(0)
-
いわゆるアベノマスクが届く - お役所にしては珍しく名前らしい題が付いていない
俗称でアベノマスクと言われる布マスクが届いた。肉眼で見る限り汚れなどの変状はない。配達物に自宅住所などの表記はなく、地域指定配布だと思われる。上の画像は郵便物的には裏面のはず。料金後納の印はマスクが入っていない方に入っている。郵便様式的に「マスク」は通信欄(通信面)に入るべき物なのだろうか。中に入っている冊子を取り出してみた。お役所物にしてはなんか変だ。漢字で長々と綴られ舌をかみそうな題名が付いていない。題名が無いと役所内での何かの審議、予算申請、通達、諸々に困ってしまうはず。政治家がよく使う「あれ」という題名で話が回ったのだろうか？強いて題を探すなら「布マスクの全戸配布」かな。青背景に白抜きで書かれた文書は、何となく政治家臭がしてくる。「省庁」の文章では無い様な。町内会の若い人が文書案を考えて、会長に回したら変な添削がされて、全戸配布のチラシに書かれたような。うーん、もみ洗いか。意外と大変だ。陰干しするのね、お日様に当てた方が消毒できると思う、日に当てると痛んじゃうのかな。あの大臣も自分でもみ洗い頑張っているのかなぁ。奥さん洗っているのかなぁ。お天道様に当たって、縮んじゃている？
2020.06.05
コメント(0)
-
DDR2 PC6400 1Gbyte メモリ 4 枚のうちどれが故障している？ - memtest86+ では見つからない memory fault
SMR HDD のベンチマークを 自分で作った SSD/HDD テストツールで行っていた。比較のため CMR HDD のベンチマークを行っていたら、読み出したデータのチェックサムが合わないエラーに遭遇した。CheckStrictlyFileImage: Error: Checksum not match. blocknumber=563962486, a=-2048(0xfffffffffffff800).単純に 8byte 毎を 64bit 値で加算していくだけの素朴なアルゴリズムだ。2048 足りないので何処かの bit 11 が 1 から 0 に変わっていると考えるのが最もらしい状況だ。変えられそうな所を変えてみて様子を見る。項目変化ケーブル変更エラーは出るポート変更エラーは出るSATA I/F 変更エラーは出るPC 変更(OS も変わる)エラーは出なくなるメモリ入れ替えエラーは出なくなる発生 LBA不定ベンチマークを行っていた PC で使っているメモリにエラー(Fault)があると考えるのが最も可能性が高い。DDR2 PC6400 1Gbyte x 4 を総取っ替えして、エラーは解消している。どの DIMM が問題なのか memtest86+ でテストしてみた。エラーが出ない。下の画像で横に並んだメモリ 4 枚のうち、エラーがある DIMM だけ取り替える積もりだった。こうなると「4 枚ともエラーが有るかも」と言う扱いになる。一気に 4 枚全損か。ベンチマークソフトのアルゴリズムから推測できることは、12 ～ 24 時間 程度メモリに記憶させていると化ける可能性がある。なんだろう、リフレッシュが掛かるまでに揮発するのか、隣接ビットに対する write/read で乱れるのか。memtest86+ は記憶させたデータが生きているべき時間は精々 2 ～ 3 時間の短期間だ。エラーは再現できないかも。CFD ELIXIR は時間が経つと、エラーが出てくる印象だ。上の画像で縦に置いたメモリは、明らかにエラーが出たメモリだ。使用開始 1 年程経過してエラーが発生した。DDR2 memory なんだよなぁ。手持ちで使えるマザーボードもこれから故障などで目減りするだろう。ハードオフで漁るのも難度が高いし。
2020.06.05
コメント(0)
-
Blu-ray ドライブ BDR-207M BD-R/RE DL 読み書き難 - 殆ど BD-R DL / BD-RE DL を使っていないのに
メイン PC で使っていた Blu-ray ドライブ BDR-207M が不調なので、状況を調査することにした。調査した結果 BD-R DL, BD-RE DL の読み書き(焼き)でエラーが発生し、難があることが分かった。BDR-207M は買った当初から難があった。トレイ開ボタンを押してもトレイが出てこない。ケースの化粧蓋を押し開ける構造だったので、それに引っかかっているのかと思っていた。ネットで調べると、普通に使っていてもトレイ開に難が有ったようだ。使っていて BD-R DL が上手く書き込めないことが気になっていた。いつの頃からだっけ？ 1Tbyte 規模のバックアップをする必要が出てきたので、BD-R DL を焼いてみる。3 枚ほど途中で書き込みが中断してしまった。おおよそ、2 層目書き込みに入って 2, 3 割程度の所だろうか。何かおかしい。 BD-R DL が本当に上手く書き込めるのか調べてみることにした。Linux(ubuntu 18.04) で動く GUI burning tool k3b と k3b が呼び出している command line tool の動作状況を観測してみる。結果は上の画像のように Dual Layer (DL) 系のメディアが辛うじて読める程度で、消去、書き込み(焼き)は全滅だった。1 層 R メディアは読めていて、焼けている実績がある。実質的に BD-ROM 機能付きの CD/DVD R/W ドライブになっていた。1 層の BD メディアは 100 枚も焼いていないはず。BD に焼くくらいなら、ハードディスクに保存した方が安上がりになってしまった。この成果は BD-207M を対象にテープラベル作り・張り練習の練習かな。なかなか真っ直ぐ貼れない。
2020.06.02
コメント(0)
全4832件 (4832件中 101-150件目)
-
-
- 【楽天市場】☆☆楽天おかいどくお買い…
- 【ふるさと納税】シャインマスカット…
- (2024-06-21 17:18:48)
-
-
-
- ジャンクパーツ
- 秋葉原他でのお買い物240114気になっ…
- (2024-06-19 18:55:41)
-
-
-
- 楽天市場のおすすめ商品
- 行列必至！飯田商店のプレミアムしょ…
- (2024-06-21 15:06:22)
-
