2020年07月の記事
全21件 (21件中 1-21件目)
1
-
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)
全21件 (21件中 1-21件目)
1
-
-
- 楽天ブログいろいろ
- 8/21の夜に253万アクセスになったよ…
- (2026-08-22 12:34:05)
-
-
-
- モバイルよもやま
- ［楽天マガジン］ 多くの雑誌が 「読…
- (2026-08-31 23:05:26)
-
-
-
- パソコンサポーターがすすめるパソコ…
- 【東芝】［Windows XP Office 2003…
- (2026-05-18 20:23:17)
-
