全4974件 (4974件中 1-50件目)

秋月八潮店に足場が掛かっていた。修繕工事中をしている様だった。建設・開店してから 19 年が経っている。新店舗だと思っていた。月日が流れるのが早い。工事中でも普通に営業している。車で行く場合、塗装の液滴とか清掃のホコリとか気になる場合は、近隣の商業施設とか時間貸し駐車場へ止めるのか良いかも。正面のワゴンに秋月電子の名前入りトートバッグが出ていた。ついにアパレルも売るようになったか。まぁ、以前は球根売っていたしなぁ...丈夫そうな布で出来ている。お店を出る頃にサンプル品を取り出して飾っていたので、手触り、布の厚み、取り回しの具合なども店頭で確かめられると思う。アウトレット品とかジャンク品のいくつかを見ていく。Topre Realforce キーボードがアウトレットで出ていた。動作不安定とのこと。XE3100 (アーキサイトブランド品) カナ無し、日本語配列、荷重 30g。さて、直せる見込みは有るかなぁ。USB Full or Low Speed だと思うので、D+ D- 波形はオシロでなんとか追えると思う。単にケーブルの断線しかかり、コネクタ緩み程度だったら、簡単だけど、Driver Recevier が壊れかけとか、クロックの周波数ズレとか、目視で分からないコンデンサ容量減とか。正面ワゴン右にアウトレットキット類の袋、PIC マイコンプログラマ、トライアック調光器、トライアック使用 絶縁ソリッドステートリレー、IC 録音・再生キットも有ったかな。キットによっては基板無しもある。絶縁ソリッドステートリレーは基板無しだった。秋月のキットと言えば「基板無し、ユニバーサル基板でなんとかする」というのか普通だったと思っていたけど、これも 40 ~ 50 年前の話か...ガレージ内の棚に長期在庫品、箱潰れ品、店頭展示で使った AC アダプタが有った。とりあえず電源が欲しいとかなら、まず見てみるのも良いだろう。真ん中くらいの高さで右側に並ぶ白箱は5V 6.2A で 1,800円の大型アダプタ LTE36ES-S1-301 の箱潰れ品だ。昔は TTL で何枚も大型基板を重ねた試作回路に 5V 6.2A がピッタリだった。少し前だと Raspberry Pi3 の電源と周辺の USB device 群への集中供給電源だっただろうか? USB Type-C PD AC アダプタが出てきて選択が変わったのかな。ホットプレート箱潰れ品HP20と開封品HP15、お値段的には新品を買っても良さそうな...チップ部品の実装工具も今時必須なのかなぁ。基板を弄るのもプリヒートがないと一苦労だし。このホットプレートも USB Type-C PD AC アダプタが電源なのね。
2026.09.05
コメント(0)

CHUXIA Robot Micro SD Card 16Gbyte(32Gbyte) の性能を見ていく、一言で言えば普通に使える Class 10 32Gbyte の SD Card だ。おおよその利用シーンで Class 10 に見合う速度を達成している。Raspberry Pi Zero W を動かすストレージとして 1ヵ月 ほど使っていて問題は起きていない。32Gbyte の全領域を fdisk partition 形式でパーティションを作り直す。ext4 file システムでフォーマットして性能測定を行う。32Gbyte 中の 24GiByte を書き込み、読み出しした。気になった測定結果を見ていく。フォーマット直後のほぼ「下ろしたて」(brand new) のシーケンシャル書き込み速度と、Sequential Write at Brand new, transfer speed vs transfer progress (Try #1, 0% to 100% as 0bytes to 24Gibytes, Raw data=0000-Y-0000-00.txt)1 回 Random Read/Write 混在テストを実施した後の、シーケンシャル書き込み速度を比較する。Sequential Write after Random Read/Write, transfer speed vs transfer progress (Try #2, 0% to 100% as 0bytes to 24Gibytes, Raw data=0003-Y-0001-00.txt)「下ろしたて」の平均 Sequential write 速度は 21.9Mbytes/sec、Random Read/Write 後は 14.7Mbytes/sec になった。速度は 67.1% に低下する。性能低下した状態でも Class 10 の目標速度 10Mbytes/sec を越えている。良いコストパフォーマンスを感じるはずだ。速度変動分布はおおよそ 3 段階に分離している。TLC か QLC 構造なのだろうか。他の要因で 3 段階に見えている可能性もある。Random Read/Write 後の速度変動分布は、広がりを持つようになった。最小おおよそ 5Mbytes/sec だ。「普通に使える」使用感に仕上がっている。Random Read/Write 後の Sequential Write 速度の違いから、16Gbyte に使用領域を制限し、Erase 済みの block を即座に割り当てられる様にして、早い Micro SD Card として使って貰う意図を感じる。自分は Class 10 を満たしているだけでも優秀だと考えている。O_DIRECT で open した場合の Random Read/Write を見ていく、Read 側は素直に 94Mbytes/sec まで速度を出している。1 回目と 2 回目も大きく変わらない。100kbyte 以上の転送でほほ 25Mbytes/sec 以上を出せている。64kbyte 未満の転送で cache が効いている場合が多く見られる。複数の cache line にまたがっている場合も効率的にまとめ上げが行われている。sense amp と組みになっている Flip Flop の列が記憶しているデータを巧みなアドレス管理で利用していると思われる。使用感は良いだろう。Random Read/Write with O_DIRECT Read part, transfer speed vs transfer length (Try #2, Raw data=0004-Y-0001-01.txt)Write 側は 2 回目の方に性能低下が見られる。32kbyte 以上の書き込みで 1 回目最低 5Mbytes/sec だったのが 2 回目は 2 ~ 3Mbytes/sec 程度の場合が目立つ様になる。分布の中間辺りは 10 ~ 20 Mbytes/sec だ。Random Access でも Class 10 の性能をおおよそ出せている。Random Read/Write with O_DIRECT Write part, transfer speed vs transfer length (Try #2, Raw data=0004-Y-0001-01.txt)Write 側の access time でみると最高速が出せているときと、再低速になってしまった場合が 10 倍程度開いている。300kbyte くらいの書き込みから目立つ。Random Read/Write with O_DIRECT Write part, access time vs transfer length (Try #2, Raw data=0004-Y-0001-01.txt)数 100 個のファイルに何かの変換を掛ける作業でちょっとしたプチフリーズ現象を見るかもしれない。O_DIRECT を付けないテストで、プチフリーズ現象に相当する結果が出ている。実用では linux で apt update, apt upgrade, coreutils build, sg3_utils build で問題は起きていない。懸念はほぼ無いと言える。IOPS は Read 側で 1800 IOPS, Write 側で 500 IOPS だ。Write 側で 1000 IOPS 程は欲しい所、安く手に入った 32Gbyte Micro SD Card だ。高望みは出来ない。Random Read/Write with O_DIRECT Read part, access time vs transfer length (Try #2, Raw data=0004-Y-0001-01.txt)Random Read/Write 後の Sequential Read は安定して 94Mbytes/sec で読み出せている。論理・物理アドレス変換, gather, error collection いずれも転送速度に影響が出ないように処理されている。パイプライン動作、並列ページ読み出し、ハードウエア処理、オーダーが低いアルゴリズム、エラー発生率が低いセル、いずれも良く出来ていると考えられる。Sequential Read, after Random Read/Write, transfer speed vs transfer progress (Try #1, 0% to 100% as 0bytes to 24Gibytes, Raw data=0002-Y-0000-02.txt)O_DIRECT 無し(OS の cache を有効にした)ランダムアクセス性能を見る。Read 側で 100 秒越え(1.2849e+02 秒)のアクセスが 1 回発生している。Linux の /proc/sys/kernel/hung_task_timeout_secs (ハングアップタスク検出時間) のデフォルト値 120 秒を越えている(測定はデフォルト値を変更して、テストが中断しないようにしている)。Random Read/Write without O_DIRECT Read part, access time vs transfer length (Try #1, (Raw data=0007-N-0000-01.txt))32Gbyte の Micro SD card だ。この中に Linux kernel source code を入れてビルドするとか、常時秒間数 10 アクセスを越える様な web server, samba server のストレージにする用途には使わないと思う。性能測定結果は Raspberry Pi Zero W を動かすストレージとして使って問題ないと判断している。CPU が Single Core 1GHz 程の性能だとストレージアクセス以外の処理時間割合が多い。ssh でログインして cd / ; ls -lR の様な単純なディレクトリ探索でも CPU 使用率は 100% に達する。ストレージを高負荷でアクセスすることは普通の操作ではない。fstrim -m 1m -v / で trim を実施することもできる。なおかつ discard mount option 常用だ。ケースに収めて外から見えないと「あれ? CHUXIA Robot Micro SD Card だったっけ?」という程度に意識せずに使えている。
2026.09.03
コメント(0)

午後 14 時位から、雨が激しくなり雷が鳴り出す。家電の買い換えが立て続けにあり(経年劣化放置の限界)、家の中の大工仕事も必要になったのでホームセンターに行こうと思っていた。予定は中止になる。買い足さなくても出来る作業をする。作業中に電気が一瞬暗くなった。商用電源変動記録を見てみる。1回目感知したのは 16:41:50 ごろ。電灯が暗くなったのがはっきりと分かった。瞬時電圧低下履歴検索を見ると、千葉県 市川市, 船橋市, 松戸市, 印西市, 白井市 で瞬時電圧低下発生があった。154kV 北船橋線とその分岐先(坪井線、矢切線)かな。印西、白井にも影響があったとすると、新京葉変電所の母線を通して千葉NT線も影響があったのだろうか?瞬時電圧低下後に電圧が上がったのは 1L, 2L (送電鉄塔に掛かる送電線の左側・右側どちらを使うか)切り替えか、変電所内で母線と変圧器の接続を切り替えたか。2 回目は 19:03:24 に、チラッと電気が消えるのが分かった。記録は周波数が一瞬上昇し、1 回目と同様に電圧が上がった。変電所内で母線切り替えをしたか、瞬時に迂回路形成したか。瞬時電圧低下履歴検索を見てみると広域だったようだ。茨城県、千葉県、神奈川県、東京都。どこに落雷したのかな。275kV 北千葉線? 500kV 房総線?1 回目、2 回目とも白井市と印西市が含まれれている。データセンターは常時インバーター給電式の UPS なので平気なはず。構内の直流母線に電池が付くのかな。(2026/8/14 追記 もしかして、これがデータセンターの一斉負荷脱落という現象なのかな。1分後~2分後、電圧がまた下がって、落雷後より若干さらに下がる。電池充電も始めたのだろうか)商用電源変動監視サーバーも何時かは cycle 単位で波形異常検出にしようと思い続けて 10 数年、気象の様子が変化してきて、監視の細やかさが追い付か無くなってきた。
2026.08.13
コメント(0)

東京都江東区新砂町辺りを散策していたら白い羽のカラスを見つける。何かイタズラしている最中に羽を白くしてしまったのかな?ズームを使って見る。元々白い羽みたいだ。飛び立った。ああ、左右対称で白い羽になっているんだ。なかなかカッコいいな。どっか行ってしまった。特に他のカラスに追いかけられる様子は無かった。普通に集まって来たり、どこかへ行ったりなのかもしれない。白羽カラスは多分潜性なんだろうな。
2026.08.06
コメント(0)

Aliexpress で CHUXIA の Micro SD card を買う。今度はロボットデザインで容量 16Gbyte として売られている製品だ。アダプタのシールに厚みが有る様に思えたので剥がしてみる。ロボットデザインの Micro SD card に付いているアダプタのシールは強く貼り付いているので、ドライヤー程度の温度で温めながら剥がすのがやりやすいと思う。現れたのは KIOX.. あっ。これケーズデンキでバケットに盛られて売られている Micro SD card に付いてくるアダプタと同じような。カードの表面印刷を見てみる。インクジェット印刷に見える。スクリーンを起こす程には手間は掛けていないか。それらしい表記は並んでいる。「Micro SD card の様な物」だ。裏側を見てみる。MMB32GBJGS-TO (あるいは MMB32GBJGS-T0) ということは、これって 32Gbyte なの?金メッキは厚みがありそうだ。ある程度の値段で売る積もりだったと考えられる。鏡写しにしてみて、表面・裏面を見てみる。二つの顔を持つ。Raspberry Pi Zero W の起動メディアとして使って見る。次は dmesg から (このリンク先は dmesg の全体, df, mount, swapon -v, fdisk の出力が含まれたテキスト) CHUXIA Robot Micro SD card 16Gbyte を認識したときに出てきた部分を抜き出した出力だ。[ 6.691765] mmc0: host does not support reading read-only switch, assuming write-enable[ 6.693637] mmc0: Problem switching card into high-speed mode![ 6.694704] mmc0: new SDHC card at address 0001[ 6.695971] mmcblk0: mmc0:0001 SD16G 29.1 GiB[ 6.700290] mmcblk0: p1 p2 p3"mmc0: Problem switching card into high-speed mode!" と出ているので Raspberry Pi Zero W では High Speed Mode でリンクしている。PC に接続する Card Reader にて Read 94.7Mbytes/sec 出ている。High Speed mode かつ十分な速度だ。別の日記でスピードテストの結果を詳しく見ていく予定だ。奇妙なのは カード認識情報が "SD16G" となっていることだ。続く容量表示は 29.1GiByte なので容量の正味は 32Gyte になる。"SD16G" は SD card から CID.PNM (Card IDentification.Product NaMe) を読み取ってそれを ASCII 表示した結果だ。規格上ここにカード容量を含める必要性はない。おおよそ表示可能な英数字を使う業界的な約束があるだけだ。"SD16G" が読めると言うことは、テスト工程で "SD16G" を書き込んだ可能性が高い。半導体工場を出る前に容量 16Gbyte として使う積もりがあったと思われる。その続きとして、商品パッケージング工程の表面印刷にて 16Gbyte 商品のデザインが刷られた。Linux kernel が認識した 29.1Gibyte は普通に使えている。次の様なパーティション構成で、Raspberry Pi Zero W に入れて 40 日ほど使っている。SD Card 起因の問題は一度も発生していない。Device Boot Start End Sectors Size Id Type/dev/mmcblk0p1 16384 1064959 1048576 512M c W95 FAT32 (LBA)/dev/mmcblk0p2 1064960 52510719 51445760 24.5G 83 Linux/dev/mmcblk0p3 52510720 60391423 7880704 3.8G 82 Linux swap / Solaris負荷試験として coreutils をビルド(要パッチ), sg_utils をビルドし完了出来た。swap も 100Mbyte ~ 200Mbyte 程を使っている所を見ている。Raspberry Pi Zero W で使いそうもないパッケージを五月雨式にインストールすることも試して問題は無い。Raspberry Pi Zero W は 1core, 1GHz, ARM v6l だ。Micro SD card に高負荷を普段使いで掛けることはほぼ無い。非力な CPU なので、Read/Write の間に休みが入る。組み込みボードコンピュータのスロットに入れてしまえば、メモリに印刷された容量なんて見えないのさ。
2026.08.03
コメント(0)

Colt Data Center 吉川の建設予定地(吉川市 資料のページにある B 地区)に行ってみる。吉川美南駅の東側 (Google Map)だ。上記画像の撮影位置に近い場所 吉川美南駅入口バス停付近 (Google Map)草が茂っていた。工事や予定事業を示す看板もない。行った時は何か間違えたのかと思った。後に写る送電線は 275kV 北葛飾線 と 154kV 野田線を共架している。電気たっぷり。対角線上の反対側に回ってみても、同様の状態だった。市議会議員が 2021年7月17日に開発計画を記事にしている。おおよそ 5 年前に計画されていた。これは、先の吉川市の資料にある当初決定の日付と整合している。隣のアヤベ洋菓子の吉川工場は既に稼働している。焼き菓子の甘い匂いに誘われて、工場直売店に立ち寄りたくなる。直売店は予約制なので、立ち寄るつもりであれば予約してからになる。営業日・時間も限定されている。開発で市側の都合が有った様には思えない。さて、275kV 北葛飾線 と 154kV 野田線について見て行く。以降送電線は北葛飾線を代表して書く。北葛飾線は新野田変電所を出発して、南南西の方向に進む。次の画像は新野田変電所の近くにある国道 16 号線を渡ったところ。上の画像を撮った大よその位置 (ローソン野田工業団地店の近く Google Map)埼玉県の田園地帯を渡る。昭和生まれならこの地域はカスリーン(キャスリーン)台風の水没地帯という記憶も有るだろう。そこにデータセンター?北葛飾変電所に至る。北葛飾変電所は完全に金属タンクの中に配線を収めた GIS 化されていて、ある程度の洪水状況を想定した作りになっている。北葛飾線は北葛飾変電所に到達した後、地下送電線(もしかしたら自動車専用道高架に配架して)墨東線、上野線として都内へ進む。都内側から北葛飾に向かう潮流になることは滅多に無いはず。それでも墨東線、上野線はその先も別の線に接続されていて北葛飾変電所付近は停電しにくいか、復旧が早い。データセンター建設予定地の周りを散策していたら、なまりんちゃんをレリーフにした消火栓を見つける。ナマズは吉川市の特産らしい。上の画像に写っている消火栓の位置 Colt Data Center 吉川の外周道路 (Google Map)日本人なら、ナマズの意図はすぐに理解できる。イギリスからやって来た Colt 社、なまりんちゃんを見て何も思うことは無かったのだろうか?もしかして、データセンター需要って世の中の騒ぎほどには多くない?
2026.08.01
コメント(0)

イオンモール熊本の爆発事故の原因はまだ正式発表がない。自分の推測や教訓の意味で思っていることを書く。まず、犠牲者が出てしまったことは大変残念に思う。報道ではガスを空調に使っていたと書いてある。空調にガス?と思う人も多いかもしれない。身近に存在する。下はガスヒートポンプで動く室外機だ。見た目は電気で動く空調室外機と変わらない。これより大型の機器も存在する。ガスヒートポンプ空調機の室外機に向かう配管分岐か、室外機に至る経路で床などの建物構造の境界付近を通過する部分で破損が起きてガスが漏れたのではと思っている。ニュース映像を良く見ると、屋上の空調室外機直下の破壊具合が大きい。2 階部分の床が抜けていたり、外壁を支える軽量鉄骨が殆ど残っていない。空調室外機から離れるほど、軽量鉄骨や構造が残っている。ガスの滞留量に比例した状況だと考えている。爆発映像も 0.1 秒単位の時間差で、室外機直下から吹き飛び始めて、広がっている様に見える、モール外道路走行中の映像例。下の画像は昭和の時代のガス配管なので、今時の基準は分っていない。身近なガス配管をみてみると、T 字分岐を使って直角に接続している箇所がある。力が集中しやすい。地震の揺れの捉えやすさも垂直・水平で違うと考えている。完全破断に至らず、通常のガス使用量と変わらない程度の漏れだとすると、ガスタンク付近に設置してある遮断装置が働かない。イオンモール熊本は感震遮断装置が義務づけられている時期に完成している。感震遮断装置は震度 5 弱程で反応する。ギリギリで不感になったと思う。危険予知、回避行動想定という観点で考えてみる。駐車場にガスタンク設備が有るのが写っている。こういう危険設備を目ざとく見つけて、ガス爆発という危険性を予知するしかない。破片がこのタンク、減圧装置、配管に当って 2 次災害にならなかったのが不幸中の幸いだったか(近くの道路を走っていたトラックのキャビンと運転席は破壊された)。屋上は駐車場になっているようなので、上がって見た時に並ぶ設備にガスヒートポンプなどのガス使用設備があるかどうかも見て回る。ガスエンジンなので電気では感じない僅かな臭気がある(ガス風呂釜付近で感じる臭気に近い)。ガスヒートポンプを見つけたならば、フードコートなどの明らかにガスを使う区画でなくても、ガス漏れの危険があることを認識しておく。ガスタンクとフードコートが離れている場合はその途中は配管があるという認識を持つことだ。ガス臭がしても室内に残ったのは、周囲に分かりやすいガス機器が無く「何でガス臭?」という疑問が先行して、逃げるという行動に結びつかなかったのではと思う。避難映像(1)、避難映像(2)を見ると、なんのアラームだか分からない音が響いていたり、鳴ったり止まったりしている。冷静に考えれば行動は「避難」だ。多くの人は状況不明だったり、直前の出来事が衝撃的だと、冷静さを失う。アラームに対する理解を失う。今時音声通知もできるのだから、「地震です。避難してください」あるいは「ガス漏れです、避難してください」と言った次の行動を指示する放送もできるはず。働いていた時、危険予知訓練を受けていた。職場安全衛生課が想定した危険に○印を付けるパワポプレゼン教育だった。誰かが想定したことは一部の事例、自分で想定して、回避・避難を考える。
2026.07.31
コメント(2)

もう少し遠い先に目的地の途中で秋月電子八潮店に寄る。寄り道なの滞在はで短時間。今年 2026 年の夏期休業は 8/10(月)~8/18(火) を予定していた。久しぶりに店外販売、採集コンテナが 1 個 400 円で売っていた。くたびれ具合は見ていない。自転車の荷台に恒久設置するかなぁ...正面ワゴンはアウトレット扱い基板が並んでいた。大型ユニバーサル基板が 1,400円、昔はこれでワンボードコンピュータを構成していた。8bit CPU, S-RAM 8kiByte, EP-ROM 8kiByte, PIO 24bit, Serial x1, 欲張って CRTC で Text VIDEO を構成するかどうか。今時は手のひらサイズ、あるいは清涼タブレットケースサイズで Linux が動くシングルコンピュータボードが有るからなぁ...C 基板用基盤 30 円、これは後で詳しく見る。「基板」と「基盤」を両方使った商品説明、「解っていますよ」的な主張だ。500円で何か黒っぽそうな部品が多く詰まった「玉手箱」IC 類が多そうという期待は持てる。んー、パッと見今までのジャンク袋で見たことが有るような...足が外に飛び出していないので、痛い思いはしないのが良いところか。Web ラジオのケースとして加工されたポリカーボネート製ケースだと思われる。定番の加工 {2.1-5.5 DC jack x 1, Analog 3.5φ jack x 1, USB-B x 1, 20x2 Character LCD x 1, 操作ダイアル x 1} がされて 960円と見るかどうか。それぞれの穴は別の用途で使えそうだし。ガチャコーナーが店舗手前に移動していた。ここダイオード類の定位置だった様な。秋月電子も生成 AI 画像ですか。真空管?は入っているのかなぁ... 生成 AI 画像って色々と細かく描写されているのに意味論的な解像度が低いというか、ズレているというか。意味論的解像度の低さが原因なのか、画像生成を指示した人の頭の中にある思考の深さを直に覗いているような感覚がある。今まで有ったもので言うと、絵を選択する方式の性格判断というか、IQ テストというか。下の右側に有る「無線 RUN」は説明を読むと、どうやら「走る」(移動する)らしい。30円で売られていた C タイプ基板の束(ラベルは 1 塊)を見てみる。これは、Ichigo Jam の Daughter Board PanCakeらしい。LPC1114 の DIP パッケージが見あたらない(廃品になった?)のが原因か。1 塊で 50 枚あった。1 枚 0.6 円だ。Cタイプ基板AE-3G Cタイプ, 2.54mm ピッチ, 両面, スルーホールと大きさを比べてみる。穴の位置は一致、4 辺とも 1mm より少し長い程度で Cタイプ基板より大きい。上下スペーサーを使って C タイプ基板を挟むと、外周部配置の部品のはみ出しも無しで、簡易ケース的に組み立てることができる。ほぼ全面ベタ(裏面はベタ面積が大きい)ので、回路の基準電位と接続すれば簡易シールドとしても機能する。引いてあるパターンも接続すれば{パターン|スロット}アンテナとして悪さをすることもないだろう。未接続ランドが多め、高周波ジャングルジムの敷地にする?
2026.07.30
コメント(0)
Anthropic で開発している AI が暴走して、セキュリティサンドボックスを乗り越え、サイトをクラッキングして情報を収集しようとしたことがニュースになった。自分が動かしている野良サイトにもanthropic からのアクセスだと思われるログが残っている。たまたまではなくて、割と頻繁だ。1 分に 1 回はアクセスがある。216.73.216.116 - - [29/Jul/2026:11:00:27 +0900] "GET /source/search?defs=ngathered&project=linux-4.4.14 HTTP/1.1" 503 574 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)"クローリング(サイトを漁る方法)のアルゴリズムは公開されていない。Google Gemini にこの状況について聞いてみた。話した内容をまとめると、従来のクローリングは URL リンクをページから抽出して、木構造に正規化し、順次アクセスする。簡単に言い換えると、WEB ページにあるリンクのうち、1 クリックで辿れるページを隅々まで探す。AI 化したクローリングは FORM に入力する内容を「予測して」さらにその先をアクセスする。これも言い換えると、例えば名前を入力する欄に「山田」・「太郎」と入力して「送信(あるいはそれに相当するような「検索する」)」ボタンを押して、その先のページをアクセスする。今ままでのクローリングは FORM の先に進むことはなかった。名前欄に「山田」・「太郎」を入力するといった予測は出来なかった。AI 化されたクローリングは FORM の先に進む予測をする。入力欄の予測について、Google Gemini とさらに対話を進める。人間だったら名前欄は 山田 太郎 という思いつきをする。AI だとそれが 山田 太郎 で有っても、SQL Injection 文字列であっても、Directory Path Injection 文字列であっても、Stack Overflow を狙った機械語コード文字列で有っても、全く同列、同等に扱う文字列の一つなのだ。何か Web server に送って、Response が取得出来るのなら、それは AI にとって会話が成り立ったことになる。LLM の予測出力にとって学習データとなる。送るデーターは学習過程で獲得され、URL リンクも、FORM に入力する文字列も、Injectiion や Stack Overflow 狙いの機械語に相当するゴシャゴシャした文字列であっても、等しく学習で獲得していく。AI の暴走ではなくて、至って通常処理なのだ。今のところ人間から見て 山田 太郎 の様な通常の言語会話に現れる断片と、それ以外の Injection, Machine code の文字列に「倫理整合度」と言った重み付けはない。AI の巨大企業たちが、倫理を重視した開発をした所で、コモディティ化した AI を個人で動かせば、暴走防止対策は全く無意味になる。そもそも、暴走と気づく方法が有るのか?あったとして、瞬きをする間もあれば、AI クラッキングは成功する。AI 訪問者たちに備えて、野良サーバーのセキュリティ強化?将来ローカル AI で対抗なのかなぁ。GPU を全力で動かす暖房器具の様なサーバーが必要になるの?
2026.07.29
コメント(0)

白井駅の近くを通っていたら NTTDATA 新白井データセンター を見つける。足場で囲まれている。白井駅交差点 (Google Map)足場の高さ 1 段分が低いせいなのか、そびえ立つ様に大きく見える。足場が外れた後は、白い壁がそびえる様な外観になるのだろうか?関電工も業者に入っているのか。建設中の建物は 50MW をサーバー群に供給する。建物全体では 100MW ~ 120MW くらいの電力消費だろうか? 関東近郊の市より大きな電力を消費する。一つの市の電力に匹敵する配電がデータセンター内で行われる。関電工の出番なのだろう。建物の見せ所はこの角度からだろうか?足場で囲んだ状態で立体造形を強調する張り出し部分を魅せてくる。稼働状態を示す LED イルミネーションが点くとか変な飾りはしないと思う。白井市市役所を背中にして新白井データセンターを見る (Google Map)色々な方向から見ると姿が変わる。屋上部分に突き出した部分は何を配置するのだろう?巨大な水槽?万が一停電になったらポンプ類を止めつつ電力消費を抑えて、自然冷却をするのだろうか?上記画像を撮影した位置 (Google Map)今立っている場所は道を新しく作ったのだろうか? Google Street View で過去の記録が見つからない。NTT と TEPCO の名前が並んでいる。東京電力も推進する事業なのか。データセンターに対する電力供給のケーススタディというかショーケースなんだろうな。だとすると電気はどこから来るのだろうか?意味深なアスファルト舗装されつつ、フェンスで囲まれた空き地とその隣に建設予定看板が立っていた。275kV/66kV 白井変電所 新設工事、建設期間はR8年10月(AD 2026年/10月)~R15年7月(AD 2033年/7月)、随分と完成が先な様な。データセンター向けの印西変電所に続いて最近では珍しい 275kV クラスの変電所新設になるのか。途中の電圧階級 154kV を飛ばして 66kV に降圧するのか。275kVって背後に写る東京東線から引き込むってこと?東京東線はこのリンク先によれば昭和33年(AD 1958年)に建設された。千葉の火力発電所で発電した電力を東京に向けて供給する環状線として機能する送電線だ。今は 500kV の新京葉線にその大半の役割を譲っている。実績系統図 によれば東京東線が 620MW を送電、新京葉線が 3760MW を送電、この 2 線路は新野田変電所まで並走している。令和になって昭和の高度経済成長期に完成した送電線の処遇に困っていたのかも。どこで 275kV の送電線を引き下げるのだろうか?国道 464 号線に向かって畑の中を通る道を進む。鉄塔の周りが工事フェンスで囲まれていた。東京東線 4067 号鉄塔だ。東京東線 4067 号鉄塔 (GoogleMap)ペンキ塗り?鉄塔ピカピカだしなぁ。近くに建設現場看板を見つける。ここに引き下げ線取付工事をするのか。建設業者は送電線を専門に建設する会社だ。4067 号鉄塔の形は建設当時の原形ではない。千葉ニュータウン建設で建て替えたのだと思う。令和になって東京東線では初の需要家向けの分岐を行う鉄塔になるのか(自分が見て覚えの有る範囲で初だと思う)。白井変電所完成は令和15年(AD 2033年/7月)だ。2033年までデータセンターに電気が来ない?どうするのだろう?66kV 高柳沼南線から分岐して地下に下ろす鉄塔も工事塀で囲われている。引き下げ線がピカピカしているので大電流対応で引き直したのだろう (2026/7/29 訂正 「google street view の過去画像を見ると引き下げ鉄塔を新設したと思われる」)。変電所完成までは高柳沼南線から電力を得るのか。将来的に新京葉変電所の負荷分散のため、白井変電所が高柳沼南線の出発変電所になるのかな。高柳沼南線の歴史は正確に分かっていない。国土地理院地図でこの送電線の終点である東武アーバンパークライン高柳駅付近の航空写真を見ると昭和22年(AD 1947年 終戦2年後)には既に鉄塔が写っている。戦後間もない頃に送電線が存在しているので、第二次世界大戦中には既に存在したと考えている。歴史有る 2 つの送電線が令和に建てられるデータセンターを支えることになるとは。下は新野田変電所へ東京東線が繋がるところ。東京電力パワーグリッドの最大の売りは、2系統の上流変電所から電力を安定供給することだろうか?上の画像の新野田変電所周辺 (Google Map)昭和の時代の怪獣映画と言えば怪獣が送電線をなぎ倒したり、齧り付くシーンが必ず入っていたなぁ。ガオー、足場の殻を破って怪獣データセンターが現れた!送電線に齧り付こうとしている!
2026.07.29
コメント(0)

撮影した画像、撮影位置の確認をしながら、印西へ行った時の日記を書いていた。「平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?」を書いているときに本当にデータセンターは静かな施設なのか?と疑問が出てくる。再確認することにした。地図を探し、MC DigitalReality NRT12 の近くに行けそうなことが分かる。裏手側とダクト、冷却配管、各階冷却室外機が並ぶ側に沿うように遊歩道があることがわかった。NRT12 の裏手に回る。配管、貯水タンク、バルブ、制御盤、サージ抑制タンク?、計装センサー、音からして多数のポンプ、どう考えたらこんなに詰め込んだ設計をして稼働できているの?プラントエンジニアではないので詳しくは分からない。良くある学校やマンションの上水道受水・送水設備と比べ規模が大きい 20 ~ 30 倍以上はありそうだ。冷却水循環ポンプ建屋だろうか?次はこの場所で撮影した動画だ。デジタルカメラ撮影動画(解析用途, 映像・音声とも再圧縮・フォーマット変換無し, .MOV file, 97.2Mbytes, 音声が再生されない場合があるので、ダウンロード(保存)してから、プレイヤーで再生して下さい)上の動画の映像・音声とも再圧縮したもの .mp4 file, 20.4Mbytes)後の方に、撮影時に手で触れたのかカチッと言うノイズが入っている。それ以外はほぼその場の音と映像が入っている。リンクをクリックするとダウンロードして再生が始まるはず。サイズが大きいので通信量が気になるスマホで見るよりは、固定回線を使っている PC で視聴することをお勧めする。使ったカメラは OLYMPUS TG-6で風切り音低減 Off だ。製品仕様に録音周波数特性は書いていない。撮影した動画の音声を解析してみる。dB でレベルが示されている。これはサンプリングデータとしてみた dB 表示だ。騒音で良く見られる音圧レベルでの dB 表示ではない。実際の音の大きさは撮影動画の音を聞いて欲しい。一緒に入っている環境音との比を感じるのが分かりやすいだろう。ピークは 143Hz 辺り、これは撮影動画で一番良く聞こえる「ビー」と言う音の基本周波数だ。低い周波数 11Hz, 13Hz 辺りからピークが出始めている。恐らくデジカメの録音可能周波数範囲から外れた範囲なので、録音レベルが落ちていると考えている。この範囲はマイクではなく、圧力センサーで測る範囲だ。23Hz, 27Hz にもピークがある。低周波騒音の範囲だ。聴覚として感じない人が多い。何となく気分が悪くなる、不安を感じる、眠れない、疲れる、集中できないといった症状で感じる。サブウーファーの再生範囲だ。映画だと心理的圧迫、不安などを鑑賞者に与える効果として使われる。48Hz, 51Hz 辺りのピークまでなだらかにレベルは上昇する。この辺りになるとブーンという音として聞こえる範囲になる。100Hz ~ 200Hz の範囲がなだらかなピークになる。おおよそ 1kHz 程度まで続くので、言葉を聞き取るのが難しい人も出てくる。人間の声に丁度被る範囲だ。1.5kHz, 3.1kHz 付近にピークを伴いながら、レベルは一旦落ち始める。この辺りの周波数は電子器機の「ピッ」という操作音によく使われる。それ程大きくない音で知覚可能な音だ。うるささの原因になりやすい。4.1kHz に鋭いピーク、5.9kHz, 7.8kHz もピークになっている。これより高い周波数は録音可能なのか確かめていない。4kHz 以上の音になると、耳障りな音になる。「キー」「キーン」という擬態音が使われ始める音だ。次は時間経過と周波数分布の変化を見るスペクトログラム表示だ。連続してほぼ同じ周波数分布で聞こえていることか分かる。低周波側は 20Hz ~ 1kHz の範囲で広く分布し、高周波側は鋭いピークが並ぶ状態が継続している。個人的な感想としては「敵わない、勘弁して欲しい」だ。防音壁を立てるとか建屋全体を鉄筋コンクリート構造にして設備を部屋に閉じ込めるとか、丁寧な作りも出来たと思う。他のデータセンターでは出来ているのだし、強いて開放建屋にする理由も無いと思う(え?循環しているの水では無くて引火・爆発性のある液体?)。他のデータセンターと背中合わせだから、配慮が無くても大丈夫という判断なのか。目の前にある建屋、事務所なんだよね。多分、きっと。データセンターの町印西へ行ってみる - 砂嵐の大地だったのに平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?
2026.07.25
コメント(0)

Google Inzai Data Center を遠くから見る。この景色もいつまで続くのだろう。手前の駐車場も別の用途に割り当てられ、駐車場を兼ねた物流拠点に変わるのだろうか?別の日に行って夕方の様子も撮ってみた。手前の ST Telemedia GDC STT Tokyo1 の建物に照明が灯っていた。タイミングチャートの波部分が光る。TRON 映画風?と言っても、世代的に見たことが無い人も多いか。昭和の時代の論理設計と映画にインスパイアされたアートになっていた。the Green に寄る。商業施設だ。行きがけの途中スターバックスを見つけた所になる。空間設計は何かのミニホール、集会施設、あるいはスタートアップ向けの工房集合といった感じだろうか。目的はトイレだ。オシャレ。アートに全振りせず分かりやすさを考えてある。お金や時間に余裕があれば施設内の日帰り温泉も有りだろう。屋外に子供向けの遊び場もある。ちょと hard mode の遊具かな。自由にあちこち登ったり、渡ったりする楽しみがありそうだ。子供にとって都会の 100% 大人向け商業施設、ショッピングモール内の{スポンジブロック|ボール}プールの様な良くある施設より魅力ある場所になっている。おや、泉野洞道の敷地にトラックが 3 台止まっている。クレーン付きが 2 台、普通のトラックが 1 台、来たときには 1 台だけだった。今も何かの工事を続けている。トラック 3 台分の工事って、それなりに大掛かりか、あるいは急ぎの工事なのだろうか?現場に資材や人員を運ぶ車はまた別に有るのだろう。自分の近所でこんなに手を掛けた電力ラインの工事は見たこと無い。県道 61 号線を南下する。正直これは失敗だった。国道 464 号線とインターチェンジ構造で交差する掘り割り構造で、普通の住宅街も、データセンターも近づくことができない。掘り割りの上に上がる階段が全く見つからない。どこまで行けばこの掘り割りを脱出できるのだろうという不安を覚える。何か無いのかな... あっ、KDDI のマンホールだ。通信回線だろう。成田方向に向かい茨城の海岸あるいは房総半島の南の辺りで海底ケーブルに接続するか、小室にある新京葉変電所に向かい、架空地線の中を通る光ファイバーに接続し、関東一円を一周する経路や遠く東北、北陸、東海に向かうルートに乗るのだろう。北総鉄道、京成電鉄、都営地下鉄もその鉄道ネットワークを光ファイバー通信路線として生かしているのだろうか。あるいは国道 464 号線とそれに接続する予定の外環も魅力的な通信路になるはず。なんだな、印西は地盤が固く、電力も安定とは言うものの災害は予想もしない形で襲う。大規模災害時データセンターからミラーやバックアップが無く逃げ出すデータはここを通るのだろうか?逃げ切れるかな... 輻輳状態になり、地下の光ファイバーの中でパケットは静かに行き場を失い尽きるのだろうか。印西の砂嵐、元はといえば関東ローム層、富士山、箱根山辺りの火山灰なんだ。Keppel Tokyo Data Center 3の裏手に来た。水抜き穴の周りが白く汚れている。外壁パネルの内側に入った水を抜く穴だから、設計通りの結果だと思う。白くなっているのは内側のコンクリートを伝わった結果だと思われる。過剰に長持ちする作りでは無く、中に入っているサーバー群が陳腐化するまで保ってくれれば良いという作りに見える。データセンター投資は消耗品購入の肩代わりをするだけなんだよなぁ。今のところ AI 商売は赤字の大安売りだ。売った情報も本当に役立つかは疑わしい。ハルシネーション、極端に質問に対して肯定的な出力、ネット情報を奇妙な塩梅で捏ねて最もらしく言葉を並べる。肩代わりした借金を返してもらえるアテは有るのか?と思う。利用料を払わないなら、サーバーへの電力供給、水冷、空冷、ネットワークを止められるかというと、技術的に難しいと思う。止めると事態を拗らせる。半導体工場と同じように、何もしなくても動かし続ける必要が有る。ファンを回し続け、SSD をスクレーピングし続け、冷却液を流し続けて化学的劣化を押し流し続け、空冷を続けて熱的劣化を避ける、ネットワークを繋いで配架してある器機の健全性を示し続ける。何もしないのに維持費が必要だ。千葉ニュータウン中央駅前に戻る。そろばん教室と音楽教室が見えた。頑張れちびっ子たち。考える、判断するという裏付けに数値的な把握をするという癖は役立つはず。10 桁 20 桁という計算を間違いなくするのでは無く、2, 3 桁精度で物理量、あるいは金額を把握する。曖昧な「ものすごく{大きい|小さい}」といった言葉による判断より良い結果になる。指数・対数(簡単に言えば桁数)という考え方もできる様になると良い。AI のハッタリに違和感を感じることができる様になるし、AI に対する質問に数値を入れて、より解像度が高い結果に達することができる。今のところ AI は自発的に内部に有る状態を外部に出力したいといった機能は無いか乏しい。人間に近い言葉を使うなら、「感情の表現」だろう。AI に指示して絵を描いたり作曲はできるかもしれない。それは自身の内部にある思いに近いものであっても、上回ることは無いし、殆どの場合は妥協が必要だ。ネットに溢れる AI 絵、動画、音楽をみていると AI 生成を使った人は妥協点すら分かっていないことが殆どだと考えている。自分で表現してみるという練習を積んでこそ、AI を使うにしてより良い表現ができる様になると考えている。おお、書道教室ですか...偉い人になって、どこかの大統領みたいにマジックペンでは無く、毛筆でサインできる様になるのも良し。お店のポップに親しみを覚える字を書くのも良し。一連の日記リンクデータセンターの町印西へ行ってみる - 砂嵐の大地だったのに平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?田舎道を進んだ先にスタバがあるGoogle Inzai Data Center に辿り着く - 徹底した多重化設計と首都圏近郊の町に匹敵するインフラ規模戸建て住宅街の向こうに見えるデータセンターは超高密度設計?配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く送電線がある所にデータセンターあり - 白井駅の近くに 275kV/66kV 変電所込みで建設中
2026.07.24
コメント(0)

向こうに見えているGoodman Business Park East Building 3 データセンター (Google map link)に行ってみるかな。Google Inzai Data Center を見ることが出来たので、少し遠回りな帰路につく。気持ちはクールダウンに入る。普段歩きなれていない。千葉ニュータウン中央駅から Google Inzai Data Center まで3.3km、歩くと足に疲れを覚える。コンビニを見つけたら水分補給したほうが良かったか。途中に住宅街がある。住宅街からデータセンターを眺める。景観の評価は難しいと思う。住宅に隣接する様に大きな建物がある景色は都内では普通た。彼方此方歩いていると、どこからか冷却あるいは換気設備の音が聞こえてくる場所がある。モーター、ファン、風切り音、ダクト振動、5~6m 移動すると再び静かになる。住宅街からデータセンターを眺めた位置 (Google Map)音が出そうな機器類は、屋上か壁のテラスに配置されている。防音壁で囲まれていて、騒音対策はされている。周囲の全方位、距離 200 ~ 300m までの範囲が静かかというと、特定の所だけ、音の重なり合わせで騒音が聞こえてくる?と思う場所がある。防音壁で全周波数範囲満遍なく防音、消音するのは難しい。空調機器は面積効率を重視しアレイ状に配置される。フェーズド・アレイ・アンテナと同じように特定の方向で大きな音になっていると思う。どうやって更なる騒音低減を図る?モーターの VFD (Variable Frequency Driver) 回転数分散、スペクトラム拡散を搭載する?防音壁に空ける穴の配置、大きさを準結晶の様に周期構造を持たないようにする?あるいは、錐形の剣山突起が配列されている壁か。2, 3 世代進んだデータセンターで周囲環境負荷低減対策がより進むと考えている。まだ工事中だ。足場が組まれている。隙間から大きな換気ガラリ、パイプが見える。見た目の建物の大きさに比べて広い。ガランの幅は建物幅の 30~40%、ルーバーの目も広い。パイプは断熱材で太く見えているだけだろうか? 400~500φ くらい?荷物搬入口の様なアプローチを 1 階に設ける代わりに、離れを建てて、変電設備か受水・配水設備、あるいはバッテリを配置だろうか。何かの建築制限を回避しつつ、分散配置で1ブロックが災害を起こしても全体に波及しないようにした設計かも?サーバー群の収納は密度勝負と言ったところか。もう少し見て回って、構造を理解した方が良かったかも。何だな、死角の無い(さらに 1 柱機能障害になってもカバー可能な)監視カメラ群にビビって見て回れないか...とにかく廃熱なのだろうか?大きなガラリの口がフロアの側面に連なる。こちらの側は道を挟んだ向かいに家屋、畑がある。廃熱を横方向にすると、気温上昇を生活動線の中で感じる様になるはず。周囲と折り合いがつくのだろうか?Google Map で見る限り屋上にも冷却塔がある。2つの冷却機構が必要な理由は何だろうか?各フロアにあるサブ変電設備?冷却水循環のためのポンプ?それとも GPU が要求する水冷と入出力やストレージを司る CPU 空冷の並立だろうか? GPU サーバーの冷却水は Coolant Distribution Unit (CDU, サーバーラックに隣接する様に配置された熱交換器) からサーバーに向かう水温が 30℃ 程度、戻ってくる水温が 50℃ ~ だ。これを 1 次側と熱交換する。GPU, CPU 冷却を屋上冷却塔にまとめず、別々の循環を構成しているのかも。既に稼働中のGoodman Business Park East Building 2 データセンター (Google map link)の裏手へ進む。歩いていたら熱風に突っ込んでしまった。どこが熱風を出す開口部なのだろうか?熱風を感じたビルの前を通り過ぎる所で振り返る。サーマルカメラで写せば興味深い状況を撮影できたのかもしれない。また熱い空気の流れを感じた。このブロックは変電設備だろうか?発電機の煙突が並ぶブロックに近い。Google Inzai Data Center も変電設備に一番近いところに煙突が並んでいた。データセンターに接続する水道が通る量水器だと思われる。大きい。良くある縁石ブロックの幅が 600mm なので蓋の横幅は 1200mm くらいありそうだ。夏場だとデータセンターの外からは一滴の水も外からは見えない。冬場になれば冷却塔から水蒸気の白煙が上がるくらいだろうか。タンクのようにシンボリックな施設が見えないデータセンターでも見た目と違い、大量の水を使っている。掛け流しの様な使い方はしていないと思いたい。夜に出向いて、量水器の蓋に耳を当てれば流れがわかるかな。思いっきり監視カメラのターゲットになりそうな...工業用水なのかな... 飲用水だと水道の供給能力が追いつかなくなると一般家庭と水利を争うようなことになる。「お金を出したのだから水をよこせ」となったら、町の存続が危機的な状況になってしまう。あっ、そうかデータセンターって「事務所」だった。飲用水が必要という立ち位置か。中に goodman (良き人)? が沢山居る? AI サーバー群だと思うんだ。一連の日記リンクデータセンターの町印西へ行ってみる - 砂嵐の大地だったのに平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?田舎道を進んだ先にスタバがあるGoogle Inzai Data Center に辿り着く - 徹底した多重化設計と首都圏近郊の町に匹敵するインフラ規模Google Inzai Data Center を遠くから見て帰路へ配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く送電線がある所にデータセンターあり - 白井駅の近くに 275kV/66kV 変電所込みで建設中
2026.07.22
コメント(0)

ST Telemedia (STT) Tokyo1 だと思われるデータセンター建屋が見えてきた。既に左手に Google Inzai Data Center が見えている。歩いて辿り着いた順を少し入れ替えて、この STT Tokyo1 と兄弟である STT Tokyo2 のことを先に書く。ST telemedia Tokyo1紹介ページだと STT Tokyo1 は稼働中、STT Tokyo2 は外回りの様子からするとまだ建設中だ。自家発電機の排煙塔だと思われる構造を包む覆いはタイミングチャートをデザインにしたのだろうか。今時の論理回路設計者ってタイミングチャートを使っているのだろうか?チップ内はほぼ言語で書かれた論理・ステートマシン設計をしていると思う。タイミングチャートを使っているのはチップの外部信号を担当する設計者くらいだろうか。覆いは単なるアートデザインでは無さそうだ。恐らく排煙塔から出る騒音を軽減する役割がある。高速道路の防音壁に見られる格子構造、穴が開いた波型板を使用している。ここでは、格子構造だ。うるさそうな構造を見せないというのも心理的効果が高いはず。テラスに置いたチラー(室外機)の頭が見えるのはマイナスかな。避難テラスの役割もあるから高く出来ないか... 火災発生時、20人くらいがこのテラスに避難するのだろうか?STT Tokyo1 の向こうにある STT Tokyo2 の脇に行ってみる。引き込み線とか周りの様子からすると、地下ケーブルで特別高圧変電室と接続している。蓄電池設備あり、変圧器の磁歪音が聞こえてくる。完成間近、既に Tokyo2 建物は生き始めている。やっぱりデータセンターの変圧器だよなぁ。「ビー」というブザーの音に近い高調波を多く含んだ音が聞こえてくる。3 相交流を整流するとコンデンサ無しでも途切れが無い直流を得られる。Active PFC とか入れていないのかなぁ。精々単純なフィルタリアクトルくらい?オイルタンク工事は建設会社が同じでも別の看板を使うのか。法的扱いが違うのかな。タンクらしい構造は見つけられなかった。タンクと態々言うからには、見えないところに大きな構造が有るのだろうか? STT Tokyo1 で計算してみる。32MW (3.2万kW) の電力供給能力が有るので、単純な計算で建屋全体で 80MW (8.0万kW) 位消費するはず、これを数日バックアップできる程度の自家発電ができると仮定して計算してみる。Google 先生の力を借りる。5MW (正確には 5,000kVA) クラスのディーゼル発電機の重油消費量が 0.260kL/MW/h なので、これを並列運転にて 80MW、72 時間運転すると 0.260kL/MW/h x 80MW x 72h = 1,497.6kL (約 1500kL) (円形タンクで直径 12m、高さ 15m ほど) になる。うーん、現実的ではないか... そうするとバックアップ時間 18 時間程度として、油量を 1/4 にすると 375kL (円形タンクで 直径 8m, 高さ 8m 程度のタンク) か。どこに巨大なタンク(油槽)が有るのだろう?保守、給油、燃料ライン、建物重心の都合を考えると 1階 か 地下か。タンク火災になったら、まるで火炙りになる様にデータセンターが燃える?Google Inzai Data Center の話に戻る。他のデータセンターに比べて端正な外観になっている。一目でわかるように Google ロゴカラーのアクセントを入れてある。Google Inzai Data Center 入口 Google Street Viewフロアか非常用発電機の冷却配管だろうか、建物の階数に比べて多い配管が建物側壁に伸びる。徹底した多重化冗長設計を思わせる。パイプラックに予備スペースがあるので、新設あるいは作り変えも考慮してあるのだろう。手前にあるバス停は京成バス千葉セントラルの鹿黒循環線(鹿黒環状線という表記もある) ビジネスパーク ノースだ。バスの運行頻度からすると通勤需要はほぼ無い。車通勤かそもそも従業員が少ないのか。建屋の中にいるのは掃除のおばちゃんではなく、掃除ロボットなのだろう。(2026/07/23 追記訂正)鹿黒(がぐろ)循環線の様子を退勤時間帯で観察してみた。バスの前から後まで乗客が立つほどに混んでいることがわかった。下の画像は路線途中 18:22 頃に千葉ニュータウン中央駅に向かうバスを撮影。Google Inzai Data Center の裏手に回る。栗畑だ。元々の印西の風景だ。データセンターの裏側に千葉ニュータウン開発前の昭和の風景が残っている。千葉ニュータウンが開発されなければデータセンター群も建てられなかったのだろうか?地の利は複合的だ。千葉ニュータウン開発により、台地故の不利な水利は解消された。中央を通る国道 464 号線も、アクセス性向上と通信回線確保に繋がる。成田空港は海外との距離を近づける。新京葉変電所は建設当初は千葉、茨城、福島の火力発電所群、茨城・福島・東北の原子力発電所群の電力を東京に中継する拠点だった。1 企業の銀行や保険の計算センターを集約する構想は有っても、世界を相手にするデータセンター適地だという構想は無かったと思う。Private Property (直訳: 私的財産、意訳: 立ち入り禁止) ですか。データセンター地域全体で英語表記の敷地境界標識が目に入る。外国人を良く見る地域だ。英語表記は常識なのだろう。国道 16 号線から近いのも理由だろう。国道 16 号線は海外輸出を目的とした中古・スクラップの自動車・重機の集約オークションヤードが並ぶ。外国人グループによる車の窃盗、荒しという話はよく聞く、残念なことである。データセンターも銅・アルミの宝庫だ。狙われやすい。2基の大型水タンクと1基の小型タンク(これも水?)が並んでいた。そのうちの一つに MWT1 (Main Water Tank 1 ?) という塗装がされていた。大きさが画像では伝わりにくい。タンク一つは埼玉県内高崎線の北側あるいは東部伊勢崎線東部動物公園以北の町に上水を配水する施設にあるタンクと同程度か一回り小さい程の大きさだ。2 ~ 3 万人程度の町に必要な規模だ。それが 2 基(+1 基)、冷却水も多重化冗長設計をしている。大きさが違うものを配置しているのは、何かの災害の時に「同一構造は同じように壊れて冗長構成をなさない」という設計思想が有るのかもしれない。後ろに写る楕円形の開口を持つ排気塔は発電設備の煙突だろうか?大小合わせて ( 3 x 2 ) + 8 x (3 x 2) + (2 + 1 + 1) + (2 + 3) = 63 本立っている。これも多重化冗長設計を徹底している。独特な形は消音設計のためであろうか。パイプ途中にサイレンサーが入っているのか。変電設備も大がかりだ。なんだな、大人の事情もあって、奥側の画像は無しである。Google Map の上空写真でその構造を確認してほしい。奥にも 2 基の大型変圧器を備える。Google Data Center Inzai の変電設備 - Google MapGIS で構成した受電開閉設備と母線、露出設置の変圧器で構成されている。良く見る工場の受電設備と比べると違和感というか、設備が大きい感がある。次のように想像している。66kV x 2 回線、154kV x 2 回線、計 4 回線を受電する設備になっていると思われる。66kV は地上送電線を地下に引き下げて接続、154kV は全て洞道を通った接続だろう。絶対に止まらないという思想でこの様な設備になっているか、段階的に 66kV 受電から 154kV 受電に移行して、そのまま 66kV 設備を残したのだろう。災害時に「どの非常食から食べたらいい?」という AI に対する問いかけが有っても、レスポンスを返すという意気込みだ。ここまで徹底するなら、鉄構あるいは複数の小型鉄塔か柱で避雷設備を配置しても良さそうな。完全 GIS (タンク) ではなく、一部の高圧配線が露出している。自然は弱い部分を目ざとく見つけて突いてくる。データセンターの隣でヤギが雑草を食べていた。AI に「雑草取りにヤギは役立ちますか?」と聞いたらどう答えるだろうか?ヤギはひたすら雑草を食べている様に見える。ロボット草刈り機よりも早いかというと... いや、この景色に 数 Tops(2026.7.20 訂正 1,000Tops 程) の AI 演算と、数 10Gbyte のメモリと、数 100km を渡る通信を介した問答を 1 秒も掛からずに行える仕組みを必要とするのか?のんびりとヤギが草を食む、それで良いじゃないか。データセンター周辺で私設のハンドホール(マンホール)を良く見る。ふつう道路の埋設物は自治体、電力・ガス・水道・通信といった公共企業が敷設する。colt は Data Center Seivce を提供する会社の様だ。Colt Private Hand Hole - Google Street View自治体が共同溝を建設するのを待つより、道路に私設の管路を建設するのが印西市の事情の様だ。リニア新幹線の様に自然破壊だ、水利毀損だといった話は今のところ無いにして、企業が町を弄っている。令和の企業城下町と言えるのかも。あの引き下げ線がある鉄塔かなぁ。Google Inzai Data Center, STT Tokyo1, STT Tokyo2 のどれかか、全てに電力を供給する接続点を持つ鉄塔は。Google Inzai Data Center 接続送電線の地中引き下げ? - Google Street View左手側(北側)が下流、右手側(南側)が上流になっていて、上流側の送電線が太くキラキラしている(画像では見えにくい)。データセンターが必要とする電力に合わせて引き直したのかな。66kV 送電線にしては目いっぱい太い線だ。重い 66kV 送電線を配架したために、154kV 送電線の腕木は有っても重量制限で使えなくなったのかも(前後の鉄塔には 154kV 用の腕木が用意してある)。それでも 154kV で下流側を延ばして、鹿島か新佐原変電所に繋げる未来も有るのだろうか?え?東海第二原子力発電所が到達先?一連の日記リンクデータセンターの町印西へ行ってみる - 砂嵐の大地だったのに平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?田舎道を進んだ先にスタバがある戸建て住宅街の向こうに見えるデータセンターは超高密度設計?Google Inzai Data Center を遠くから見て帰路へ配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く送電線がある所にデータセンターあり - 白井駅の近くに 275kV/66kV 変電所込みで建設中
2026.07.19
コメント(0)

12:30 ~ 13:30 に掛けて激しい雷雨となった。12:52:30 頃から落雷による瞬時電圧低下が商用電源監視サーバーに記録されるようになった。2026/7/17 12:00 - 13:002026/7/17 13:00 - 14:00外が暗かったので電灯を付けていた。落雷により電灯が一瞬暗くなり、UPS の切り替えアラームが鳴る。商用電源からバッテリ供給に切り替わるリレーの音も聞こえた。ん?「シャッ」というリレーの音とは違う大きめの器機が動作する様な音がした直後に裂けるような「バリバリバリ... ドカーン」という近くに雷が落ちた音が聞こえた。間が悪いので作業を中止して昼寝することにした。起き上がって、作業を再開しようとしたら、パソコン、モニターの電源が入らない。あれ?壁コンセントから工事用の過電流・漏電兼用ブレーカーを通して各器機に電源を分配してあるのを思い出す。ブレーカーを見ると切れていた。「寝ぼけて切ったっけ?」、「このブレーカーはトリップ位置無かった?」、いやいや、「午前中このブレーカーの下流にある RaspberryPi Zero W の作業を電源入れたまま中断して、午後に再開すればいいや」と思っていたよね。どうやら落雷で工事用のブレーカーハタヤ BFX-013KC2が落ちてしまったようだ。このブレーカーの下流に自作のアレスタを繋げてある。ブレークダウン電圧 230V、2極 と 3極 のガス放電管を使った回路をプラグにして作ったものだ。もう少しちゃんと作るなら温度ヒューズを LINE(LIVE) 側に入れた方が良い。ブレーカーの下流に入れるので割り切った作りにしてある。2024年 6月 頃に作ったと思う。自分が生きている間(おおよそ 30年)、このガラクタが機能することは無いだろうと思っていた。住んでいる部屋は鉄筋コンクリート造り、一般に「落雷があっても室内の電気器機には影響が無い」と言われる構造だ。今日の落雷でアレスタの上流ブレーカーが落ちた。アレスタがサージ電圧を吸収した(放電電流が流れた)のだろう。サージ放電電流を漏電として検出してブレーカーが落ちたと推測している。最上階の部屋だから、屋根か庇に落ちて、誘導雷が発生したのかな。同様の過電流・漏電ブレーカーと自作アレスタを各部屋に配備してある。一部屋だけブレーカーが落ちた。アレスタが無ければ即死だった。電気器機の被害は無さそうだ。
2026.07.17
コメント(0)

駅前から続いていた町を離れる。景色は一転して草むらを進む道へと変わる。この先にデータセンター有るのかなぁ... テンション下がるなぁ。一応頭の中に地図は入れておいた。急に自信が無くなる。スマホの Googlemap? 契約プランで通信量最小プランだからパケット消費はしたくないし。デジタル大臣?なんだな。ここも誰かの土地であろうけど、データセンター周囲だと明らかに私有地と分かる所にポスター看板は立てられないし、支援者も見つからないのだろう。上記画像の Google MAP link (泉新田大木戸野馬掘遺跡付近)データセンター大臣になろうとしたら、CCIE(CISCO 資格)、LPIC-3(Linux 資格)、AZ-802(Windows Server 資格)、ネットワークスペシャリスト、電気主任技術者2種、危険物甲種、高圧ガス製造保安責任者、ビル管理士、水道技術管理者くらいは資格を持っていた方が良さそうだろう。デジタル大臣になろうとすると医師免許も要るのか... 遠いな。遠くに送電線が見える。鉄塔に腕木が有るのに送電線が掛かっていない部分がある。画像では良く見えない。Google Street View で景色の先に写る鉄塔の近くを見てみる。千葉NT変電所まで 154kV の送電線と 66kV の送電線が共架されているのに、その先は 66kV だけになっている。データセンター地域だから 154kV も送電線を張れば良さそうなのに架線がない。整備計画を見ると千葉NT線とその先にある草深線?周囲の強化、系統変更工事が並んでいて、データセンターに電力を供給できるように、普通の町中に供給する上流変電所を遠くの変電所へ逃がそうとしている様に見える まさか 66kV, 154kV 送電線を潮流融通線として使おうとしている?データセンターが増えても素直に送電線を増設できていない。困った事情でも有るのだろうか?鉄塔のフレームの太さからして、154kV を 2 条で配線出来ないので諦めた?国道16号、成田空港と容易に往来できる国道 464 号線沿いだから物流基地としても魅力ある地域なのか。緑のアクセントカラーはグッドマンビジネスパークのアイデンティティらしい。物流倉庫の向こうにきっとデータセンターが有るに違いない。ああ、そう言うことか。東京電力PGの洞道地上施設が見えてきた。仮設トイレがあるので現在も何かの工事を継続中だと思われる。ちまちまと地上送電線を強化をするよりは、地下に大電力ケーブルを敷設するのか。鉄塔からの引き下げ線用地確保とか、保護範囲拡大とか、テレビ映り補償とか、変電所バンク分配再設計とか、目立って面倒なことは全て飛ばして新設するのか。防災面でも、地下ケーブルの方が有利だし。とは言っても冷却・監視・ユーティリティ用の低圧引き込みが、行き止まりの 6.6kV 配電線(電柱)からというのは、如何なものかと。電柱に軽トラがぶつかったら、洞道は機能停止か、制限ありの状態で運用することになりそうだし。2 系統受電じゃないのか(洞道内に渡りバイパスが有るのだろう... きっと)。泉野洞道なのね。No.2 ということは探せば No.1 とか No.3 とか有るのかなぁ。千葉ニュータウンそのものも、ここの土地にとっては元々なかった町なのだ。台地故に水に乏しく、栗畑のような水が少なくてもできる農業、牧畜(飼料はどこからか持ってくるとして)とか、林に埋もれる様な人の営みが広がる地域だったのだ。グッドマンビジネスパーク地域に入る。スターバックスだと?自分の町にはないのに! 屋外席もある。この辺の砂嵐気にならないの?近くに駅はない、名所・景勝もない、着ていく服は何でもよい地域だ。スターバックス コーヒー theGreen千葉ニュータウン店(Google MAP link)それなりにお客さんは居るのだろうな。グッドマンビジネスパーク地域に入り、歩いていると入館証を下げた外国人を良く見る様になった。入館証にはカタカナで名前が書いてある。日本人も同様に入館証を下げて歩いていた。データセンター内で休息、打ち合わせ、作業指示受け取り、報告の連絡をするよりは外のスターバックスの方がやり易いのかもしれない。データセンター内だと電波は遮蔽されているだろうし、インターネットにルーティングされているネットワークがあったとしても自由に接続するのは禁止されているだろうし。佐川急便の拠点もオシャレだ。ラックに掛けたり、外したりする機器を着荷・発送するのもここで扱っているのかな。高機密情報が入ったストレージは手荷物かもしれない。自分の所の佐川急便は青空拠点なんだ。一連の日記リンクデータセンターの町印西へ行ってみる - 砂嵐の大地だったのに平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?Google Inzai Data Center に辿り着く - 徹底した多重化設計と首都圏近郊の町に匹敵するインフラ規模戸建て住宅街の向こうに見えるデータセンターは超高密度設計?Google Inzai Data Center を遠くから見て帰路へ配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く送電線がある所にデータセンターあり - 白井駅の近くに 275kV/66kV 変電所込みで建設中
2026.07.16
コメント(0)

千葉ニュータウン(印西)近辺の貸し自転車the Green Cycleのアプリ登録をした。都合で支払いは PayPay を選ぶ。デポジット 2,000円 の支払いが必要だというので、直近で自転車を借りる積もりは無い状況で、デポジットを支払ってみた。the Green Cycle はecobikeのサービス基盤を使っているようだ。支払い画面の説明で、自転車を借りなかった場合は 1 ~ 2 日で全額返金と書かれていた。2,000円 の実験だ。おおよそ 35 時間後に返金となった。支払いを 7/12 12:44 に実施、返金が 7/13 23:50 に行われた。日替わり直前のバッチ処理だろうか?使う積もりができたなら、デポジットを支払えば良いことがわかる。
2026.07.14
コメント(0)

竹中技術研究所の前を通り、駅から離れたデータセンター群へ向かう。竹中技術研究所は1993年に建てられた建物だ。建物というよりは、現代的解釈で作られた古墳とでも言うような作りをしている。キジバトたちも、マンション、戸建て、ロードサイト店、データセンター、物流拠点が集中する地域になると思っていたのだろうか?千葉ニュータウン(印西)は昭和末期から平成初期の頃辺りからデータセンター地域として開発されている。解体中の三菱 UFJ 千葉センターがそれだ。下の画像の奥側に写る建物だ。足場で囲われている。開発当初はデータセンターという言葉は定着していなかった。事務センター、電算センター、計算センターという呼び方だったと記憶している。手前に MC Digital Realty NRT12 データセンターが建っている。こちらは見た目もデータセンターだ。2012/9 頃の様子を見ると、三菱 UFJ 千葉センターと一体となった建物(というよりは庭園)があった様だ。見た目は大事だよなぁ。空調ダクト、排熱・熱交換ユニット、発電機排気口、冷却水循環配管と思われる設備が見られる。画像からうるさそうな建物に見えてしまう。音声+動画で撮影してみる(3.88Mbyte, MP4 動画)。手前を通る車の走行音の方が大きい。稼働しているのだろうか?と疑いたくなるほどに音は聞こえない(2026年1月よりサービス提供開始とある)。2026/7/25 追記 NRT12 の騒音を再確認するためもう少し近くに寄ってみた「配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く」フル稼働に到達した後、何年使うのだろうか?隣で解体中の三菱 UFJ 千葉センターは 1996年1月 竣工、実際に利用されたのは30年間あるかどうか。30年経ってどうにも使いづらくなった?データセンターのことを検索していると、データセンターが不動産投資対象として広告に出てくる様になった。利回りは 12% ~ 13% 程度。普通の賃貸、雑居ビル、工場と比べるとかなり高い利回り設定になっている。美味い案件?自分は疑問に思っている。データセンターは消耗品だからだ。空調、熱交換設備、非常用発電機・バッテリ、燃料タンク、電源、受水・排水設備、消火設備、場合によってはラックも消耗品だろう(ウイスカや錆の剥離浮遊を嫌う)。これらは可動部があり 24h 365day 動く、動かなくても定期点検、利用期限がある。不動産ではなく、地面の上に乗っているでっかいタワー型パソコンなのだ。十分に保守をすると保守費用はどのくらい掛かるのだろうか。A 系, B 系有るにしても無停止前提だから、綿密な計画と手間が必要だ。5 年後は新しいサーバーの規格が合わずに利用価値が下がってしまう。特に AI 向けデータセンターは冷却設備が特殊だ。冷却水の温度が往還とも普通のチラーの入出力と違う。用途を広げようとデータセンターを一般サーバー向けに転換しようとしたら、冷却設備を全交換する必要がある。古いパソコン部品を新しいパソコンで使おうとしても使えないのと一緒だ。ジャンク箱行きなのだ。お向かいでも建て替え?「労働金庫千葉ニュータウンビル」と思ったら、看板の足元で芝刈りロボット?が動いていた。クリックすると芝刈りロボットが動いている 10.9Mbyte の動画再生このロボット、GPS 衛星みちびきの電波を使って cm 精度で位置を把握、データセンターにあるサーバーからダウンロードした地図情報で草刈り計画を実行、結果をサーバーに返しているのだろうか?データセンターの足元でひたすら動くロボットが宇宙からの電波を拾って、お隣のビルにある何かのサーバーと繋がっている?奥に進む、MC Digital Realty 系列のデータセンター NRT10 が見えてきた。NRT12 より先にできたデータセンターだ。大きい。こうやって見ると、やはりスケールメリットだよなぁ。と思う。外観は敷地面積の広さ故にスマートだ。AI バブルの真っ只中、データセンターであれば何でも良いか?諸元の一致、規模、近隣建物との折り合い、既に厳しい選別が始まっているのかも。一連の日記リンクデータセンターの町印西へ行ってみる - 砂嵐の大地だったのに田舎道を進んだ先にスタバがあるGoogle Inzai Data Center に辿り着く - 徹底した多重化設計と首都圏近郊の町に匹敵するインフラ規模戸建て住宅街の向こうに見えるデータセンターは超高密度設計?Google Inzai Data Center を遠くから見て帰路へ配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く送電線がある所にデータセンターあり - 白井駅の近くに 275kV/66kV 変電所込みで建設中
2026.07.14
コメント(0)

7/9 にデータセンターの町印西へ行ってみる。千葉ニュータウン中央駅から、Google Data Center Inzaiの辺りまでを歩く。長い内容になりそうなのでいくつかの日記に分割して書こうと思う。Goole Data Center Inzai を千葉県道 4 号線より見る位置久しぶりに千葉ニュータウンに行って驚いたのが人通りがあることだった。14:20 頃、通勤・通学時間帯でもなく、電車から降りた人、乗ろうとする人の流れがあった。覚えている30年くらい前の風景から大きく変わっていた。本当に人が居る町なのだろうか?にわかには信じがたい光景だった。駅の近くにある居酒屋の勝手口を見てみる。勝手口から黒い油汚れが続いていた。居酒屋にお客さんが来ていて、料理が出されている。東京の繁華街ほどには汚れは濃くないにして、千葉の内陸部としては上手くやっている様に見える。ようやく人が居る町だと確信した。かつてはラーメン屋すら出店が厳しい町だったのに。電車で現地に行く場合、自転車を借りられるようにThe Green Cycleのアプリをスマホにインストールして登録と使い方の予習を予めしておくと良いだろう。2026/7/14 追記: 自転車を借りなかった場合のデポジット支払いと返金についてThe Green Cycle 千葉ニュータウン中央駅拠点位置貸し出し・返却拠点は 2 箇所、駅前と Google Data Center Inzai より直線距離で 390m ほど離れた場所だ。the Green Cycle ショッピングモール内拠点位置駅から Google Data Center Inzai まで行くとして、3.3km (往復で 6.6km) ある。周辺の探索、色々な方向から眺めてみようと思っているのであれば、自転車の機動力は助けになるだろう。下総台地と言われる地形であっても、起伏はある。電動アシスト自転車なので走破性は良いだろう。ここなのかな。駅前データセンター問題って。画像にはぼかしを入れてある。現地に行ってみるとぼかしの理由がわかると思う。色々と神経を尖らせている。ぼかした部分は印西市の公表資料としてアクセスできる。色々と考えを書き出してみる。隣のイオンショッピングモールから出る騒音は気になるレベルなのだろうか。画像の手前に見える道路の通行量は多い。データセンターの騒音、イオンモールの騒音、車の騒音を純粋に測定しようとすると、早朝、朝夕、昼間、夜間のそれぞれの時間を選び測定する必要が有りそうだ。高さも地平、10m, 20m, データセンターより高い位置に有る隣接マンションの部屋を選ぶことになる。屋上廃熱なのかな、廃熱量、周囲の温度変化、クーリングタワーからの水滴拡散、消毒設備、水道使用量(周囲の水道水圧影響)、定期的な環境測定報告、実務的な交渉要点は多岐にわたる。データセンターそのものの機能として、スケールメリットが有るのだろうか?と疑問に思う。奥地(といっても駅から移動距離にして 2km ~ 4km 程の所)にあるデータセンター群はここに建てようとするデータセンターと同じか 2 倍程度以上の電力・ラックスペース・通信量・災害時の稼働継続性が有りそうに見える。さて、クラウドサービスを行っている事業者の第一選択になるだろうか? NTT 自身で全て使い果たすつもり?印西温水センター(廃棄物焼却施設)の塔が見えてきた。30年くらい前の記憶だとこの塔は砂嵐の向こうに霞んで見えていた。砂漠のオアシスの様に見えていた。印西西消防署がすぐ隣有る。マンション群、戸建て住宅だけが並ぶ地域だったら、十分な消防署だったかもしれない。今はデータセンターが有り、物流拠点が有り、巨大ロードサイド店舗がある。印西西消防署の消防車は多く見て 5 台程度だろうか?牧の原消防署と合わせて 10 ~ 15 台程度か。普通の町なら十分な配置だと思う。データセンターは地震の時に火災にならない?本当だろうか?東京電力 PG 管内で言うと山梨県が消費する電力の 2 倍程度を印西地域のデータセンター群で消費する。地震災害発生時、データセンターは自家発電設備によって 2 ~ 3 日程度稼働継続できる様にしてある。継続に必要な燃料も敷地内に確保してある。おそらくちょっとした地方の石油化学コンビナードに備蓄されている油の量と同程度が印西地域に有るのでは?と思っている。地盤が固くても遠地から来る長周期地震動によってタンク内の油が溢れる可能性は有りそうだ。データセンター、自動倉庫で火災発生、モウモウと上がる黒煙、ロードサイト店で商品荷崩れ、戸建て、マンション群も火災や要救助が発生するだろう。台地故の水道水圧低下、周囲の自治体も十分な消防・救助能力はない。成田市は空港で手一杯だろうし、船橋市も沿岸部に集中させるだろう。砂の台地なのだ。大量の砂を撒いて消火できるって?一連の日記リンク平成初期の頃に建てた事務センター建て替え 30年くらいで使いづらくなる?田舎道を進んだ先にスタバがあるGoogle Inzai Data Center に辿り着く - 徹底した多重化設計と首都圏近郊の町に匹敵するインフラ規模戸建て住宅街の向こうに見えるデータセンターは超高密度設計?Google Inzai Data Center を遠くから見て帰路へ配管とポンプのジャングルジム - もう一度データセンターの町印西へ行く送電線がある所にデータセンターあり - 白井駅の近くに 275kV/66kV 変電所込みで建設中
2026.07.13
コメント(0)

自電車で立ち寄った先のショッピングセンターに家電量販店のノジマが入っていた。エスカレーターでフロアに上がったら、「ナフサや銅が足りないと工事部材不足で工事が遅れる!」と、エアコン室内機・室外機があったとして、ドレンホース、配管カバー、樹脂設置台、貫通孔パテ、冷媒パイプとホースの保護テープ、室外機接続ケーブル、冷媒配管、配線方法によっては接地線、接地棒などが部材として必要だ。ナフサ不足で有れば、どれも足らなくなるか価格高騰しやすいものだ。原料から加工品に至る工程も様々で、ナフサが有れば作れるかというと、難が出てくるだろう。エアコン室内機・室外機を作る部品にアルミがある。アルミ? UAE アラブ首長国連邦も輸出国の一つだ。ホルムズ海峡の内側の国になる(一部外側も領有している)。え?無事に取り付けができたとして、そもそも発電のための重油やガスは大丈夫なのかって?
2026.06.21
コメント(0)

ちょっと過去のネタ発掘、Aliexpress 通販で買い物、配送途中で「製品情報に不備があります」になってしまった。英語で見ているので "incomplete product information" だ。画像のリンク先は Tracking page を印刷した PDF ファイル 801kbyte ある。特に連絡もせず放置していたら 4 日半経過したところで、エスポ便に渡った。経緯を詳しく見て行く、日本の通関手続きで引っかかった。問題が有ったら、エスポ便か税関から通知はがきが来るかなと思っていた。通関記録から見ると 4/29 13:42 に手続き開始、半日ほど経過して、"Change the customs declaration method for the package" となって通関方法変更、その 1 時間後に "Incomplete product information" となった。ああ、面倒なことになった。川崎に出頭かなぁ... 通知はがきが来ないことには何も行動を起こせない。3 日経過した 5/1 13:39 にて突如として税関検査完了となった。エスポ便頑張ってくれたのかなぁ。"Change the customs declaration method for the package" を実施してくれたのか、それとも要審査となった荷物に AliExpress の注文状況を調べてくれて説明したのか。この時点で通販で買った品物の荷物は 2 個有って、後かから発送された荷物が追い越して配達ルートに乗った。4 日と半日経過したところで、エスポ便集荷となる。さて、問題の原因を考えてみる。荷札と内容物が合わなかった。荷札は「衣類」(いゃ、もう少し詳しく見ると... この年齢で恥ずかしがっても仕方か無いか)。袋の中は、衣類、PCパーツ、電子部品だ。これは引っかかるなぁ...衣類は細かく関税が決まっている。個人輸入なのでそれほどうるさく言わないはず。政権の方針?最近は厳しい。うーん、PC パーツとか電子部品を買う時は衣類とかと発注時機ずらした方が良いのかなぁ... Choice で送料無料化の魅力は有るにしても。
2026.06.20
コメント(0)

今時 Windows 98 client に共有フォルダと PDF 仮想プリンタをサービスする samba server を構築する。普通に最新の Ubuntu に samba package をインストールすればよいのでは? と思っていたら、動かなかった。色々と解決策はあったと思う。samba 3 系列をビルドして何とかして動かす方針を選択する。Google gemini に相談したらパッチ地獄だよと脅された。確かにパッチ地獄だった。samba-3.6.25 をビルドして server を構築し、Windows 98 client に共有フォルダと仮想 PDF printer をサービスするまでの作業結果を github にまとめておく。Ubuntu 22.04, 24.04, 26.04 と Raspberry Pi OS trixie をサポートしている。Raspberry Pi Zero W (Single Core, armv6l, 512Mbyte RAM, 16Gbyte Micro SD card)で動くことを確認している。小さな Raspberry Pi で小規模な隔離ネットワークを構築することも容易なはず。samba の build は 2 ~ 6 時間程度かかるだろう。Gemini に相談を進めれば今時な AI バイブコーディングができたかも。今回は使わなかった。ほぼ手作業で行う。時間は有るのだ。解決したのは次の 2 つの問題。Configure が失敗する。正しい結果にならない。User Intervention Required (ユーザーの介入が必要) となって印刷が始まらない。途中 VScode の copilot auto complete をドキュメント作成で 5 時間ほど試している。Free plan の枠を 33% 消費したのが衝撃だった。以降は普通の auto complete に戻す。samba を build するに至った状況を書いていく。切っ掛けは Lubuntu 22.04 で samba server を Windows 98 ベースの古い計測器向けに共有フォルダと仮想 PDF プリンタをサービスしていた。これを Lubuntu 24.04 に dist upgrade したら、PDF 仮想プリンタが動かなくなった。spool 詰まりを起こす。samba server の方で back trace が発生していた。こんなことだったら、24.04 に upgrade しなければ良かった。dist upgrade する前にバックアップをしていなかった。後戻りはできない。実は後から、server 構築作業途上のバックアップも見つかっている(途上なので怪しい)。もともと Windows 98 ベースの計測器を隔離されたネットワークに置く必要が有った。場所を取らない Raspberry Pi をネットワーク隔離装置として仕立てる積もりも実現していなかった。samba を build できれば何かと自由度が上がるのだ。samba 4 系列で Windows 98 サポートは期待できないし。バイブコーディングせず、今時誰得プロジェクト、相手は古い計測器、ゆっくりで良いじゃないの。
2026.06.20
コメント(0)

茨城県の坂東市辺りで 19:46 頃に大きめの地震、太田市、千代田町、加須市、本庄市、美里町で震度 5 弱。太田、千代田、加須、本庄は埼玉、群馬に住んでいたときによく行った場所だ。電車が動いていたり、夜間稼働の工場がある時間帯なのだろうか?商用電源変動が 19:46 ~ 20:02 の間に見られた。19:46 ~ 19:50 の辺りはいつもの地震と同じように、一斉停止により 50.18Hz まで周波数上昇、その後は情報収集のためのテレビやパソコンの一斉電源 ON で 49.89Hz まで周波数低下が起きた。電圧変動も同時に起きている。19:50 ~ 20:00 若干周波数が下がり気味状態が続いていた。内陸の水力発電の一部が異常振動かなにかで停止したのだろうか?送電網の安定化が早くなったような。最近 youtube でお勧めによく出てくる様になった系統蓄電設備(ビジネス)のおかげなんだろうか?ちょっと心配事、落雷や地震などで送電網の遮断器が動作すると瞬時電圧低下が発生する(今回は起きていないみたい)。そうするとデータセンターの UPS が瞬時に受電を停止して、自家発電に切り替わる。100MW くらいのデータセンター 5, 6 棟が同時に同じ切り替えをすると、火力発電所 1 基程度の変動になる。発電所の脱落という事象で、供給不足になることは経験している。とは言っても多くの場合は計画的だ。需要が突然(数10ms)で無くなることは経験しているのだろうか?(そう言えば北海道広域停電の時に本州-北海道連系系が停止したときが有った)データセンター原因でフラッシュブラックアウト?それとも、未経験の数 100MW 定電力負荷特性で夏場の冷却需要が大きくなったときに系統制御限界を超えて電圧崩壊?
2026.06.16
コメント(0)

Aliexpress で買い物をしたら 追跡番号が USxxxyyyzzzSL という US 9桁番号 SL になった。日本郵便のサイトで追跡出来る様になったら、5/8 SIERRA LEONE FREETOWN (シエラレオネ フリータウン)を経由しているか、あるいは発送地になっていた。シエラレオネ? アフリカ大陸の国だった。Aliexpress の追跡は比較的早い段階から追跡できるようになっていた。17track では手元に着荷するまで追跡不能だった。Aliexpress の追跡と日本郵便の追跡情報を注意深く付き合わせて見てもらうと判る様に、5/4 "Package leving origin country/region" から 5/9 "In transit/Your package arrived at local airport" の間で SIERRA LEONE を経由しているか発送になっている。着荷は 5/18 だった。5/10 から "Collected by destination carrier" となっていてる状態が続いていた。アフリカ大陸を出て日本に向けて空を飛んで、いくつかの空港を経由しているのか、荷物追跡が途絶えたのか。地球の中心を貫くワープトンネルでも有るのだろうか?存在が確率的状態になってしまったので追跡不能だった?中身は... まぁ、いいや。この年になって恥ずかしがってもしょうが無いし。
2026.05.20
コメント(0)

クワガタムシを見つける。団地の階段にいた。近くに林が有るので飛んできたと思われる。10m 程の高さまで飛べる元気は有りそうだ。夏休みの虫だったのに。5 月に見つける様になった。そうすると、夏休み期間中に出てくる虫は?
2026.05.09
コメント(0)
Linux Kernel にも Rust か入ってきたので Rust の勉強を始めた。仕様書 The book と呼ばれる物を読み始めて、「これは勉強しても身につかないな」と思うようになる。実際に殆ど書かずに諦めに達してしまった。AI に色々と疑問を聞ける様になったのも大きい。以下諦めた思いを悪乗りで語っていく、いつもと違って長い日記だ。Rust が好きな人にとってはあまり面白くないと思う。初心で Rust 勉強は The book だね。チュートリアルの 3 章で「変数は標準で不変になります」とか禅問答を楽しもう。こんなノリが 24章 まで続くよ。hello world で使う println!() は 17章でようやく明らかにる。楽しみが続くね。用語だって Computer Science とか産業で使われている用い方をちょっと無理して Rsut 独特な解釈が必要な所に当てはめているよ。どうしても既存用語が当てはまらない所は Rust 用語を使ってキラキラしているよ。とても眩しいよ。あっ、でも仕様書とか論文でオレ的用語使いは怒られるからね。相対的にサンプルは少ない。他言語の歴史には勝てない。それらが仕様・アルゴリズム視点でちゃんと動いているかというと注意してね。「Rust で再実装しました」的なものを見るけど、元の機能を100%移植してないかも、テスト十分なの?というのを見ることがある。いつかは査読批判できる様になるさ。マクロは攻略ポイントの一つだよ。BNF 的な記述で言語拡張ができる。画期的だよ。xxx! って書かれた所は日本語喋ってて突然英語を喋る感じにできるよ。マクロを理解し新しい書き方を創作し、1 ヶ月後の自分にラブレターを送ろう。Python とか他の言語はアルゴリズムとかメモリ使用量の感覚が得にくい? Rust もそんなの気にしないよ。メソッドチェーン var_x.a().b().c()... だカッコイイ。効率的なアルゴリズムやメモリ利用なの?気にしたら負けだよ。'.' を跨ぐ度に文字列、文字列配列、何かの option 型配列、... と型が変わる。panic!() フリーでフィニッシュできる様になるさ。Rust knowhow を定型句の様に覚えよう。双方向リンクリストを作るのに小難しい記述で memory leak, borrow chcker 回避できるよ。AI に聞いてビックリ C, C++ では容易に同一値の enumerator を enum で書けるところを Rust では struct 中のフィールドを定数で書いてフィールドを読めば解決するよ。定数列挙は struct だよ。enum は数学の集合に近い概念を取り入れたカッコイイ物だよ。あっ、数学好きだよね。Linux 環境だと rustup update で ~/.cargo ~/.rustup 以下にコンパイラ、ライブラリとかが流れ込んでくるから、それらが本当に安全なものなのか確かめて使おう。cargo-audit だよ初心者でも使ってね。Rust の procedural macro (println!() の内部 format_args!() ね) って compile time に実行されて何でもやりたい放題だから。普段は昨日書いたコードが今日動かなくなる破壊的な変更に慣れよう。文法・ライブラリ知識の update、長いビルドタイム、自分起因では無い再テストで Rust の日課をこなそう。エラーメッセージが親切?世界を止めた .unwrap() の使用/不使用 本質的には panic!() の使用をライブラリの中に潜んだものまでコンパイル時にチェックする機構は用意されていないよ。AI に聞くと今後も期待薄だ。Clippy に書いた範囲だけチェックして貰おう。どうしても気になる? ~/.cargo から深いところに潜む index.crates.io-*/*/* を毎日読むんだ。勉強になるよ。ドキュメントも使う積もりの無い関数までちゃんと読んでね。cargo test で実行されるやりたい放題コードをコメントに埋め込むことができるから。何をしているかちゃんと理解するんだ。さて、悪乗りはここまで。Rust の設計思想がことごとく読みにくさ、アプリ実装が中途、斜め上の安全を量産していると思っている。悪乗りで書いた内容の随所に書いたとおり、Rust、その周辺ツール、クレート群は Rust 利用者がアクセス権を持つ範囲(簡単に言えば $HOME 以下のファイル群)のセキュリティを脅かす可能性がある仕様が複数有るし、そのやりかたも複数存在する。ビルドプロセスでセキュリティ侵害を試みることができる。自分が間接的にも使わない関数に悪意を仕込み発動させることができる。悪意を忍ばせる難易度はディストリビュータが提供する package に忍ばせるよりも遙かに低い。オープンソースは完全な善意で提供されるというのは、残念だけど期待できない。長く生きているので、$HOME 以下に知られたくない情報も沢山溜まっている。小さな統治範囲であっても政治は必要だ。Rust は「政治的」に使いたくない言語だと初めて思えた言語だ。Rust ソースを読んでいて、「読みにくいな」という説明が付かないモヤモヤが常に有った。その一つがマクロの言語拡張機能だったと思うようになる。BNF でマクロを定義できるので、文法を作りたい放題、方言だらけの記述でツギハギを作っている。似たような失敗をした syntax sugar だらけの perl を忘れたのだろうか? perl は syntax sugar の一つを縛りで使えばそんなに可読性は落ちない。Rust はほぼ強制だ。AI に投げつけた醜い問答はもっといっぱい有る。ここにコピペしても面白くないだろう。静かに片田舎で C 言語を使い続ける。自分にとっての平穏だ。
2026.04.19
コメント(0)

久しぶりに秋月八潮店へ行く、去年の夏に平衡感覚を失う。長距離の移動が困難になってしまった。ようやく長時間外を移動しても平衡感覚に違和感を覚えなくなった。試しに八潮まで行くことにした。注: 以下クリックして開く画像は 1.5Mbyte ~ 2Mbyte の大きさがあります。左側ワゴンに 2SA1015GR のカートン(3,000個)売りと、テープ切り出し売りが有った。20 個で 100 円。スタンプ刻印なので古い?最終ロットはレーザー刻印だったような。謎の D-sub 25pin ターミナルブレークアウトボード、端子配線をみると AGx(多分アナロググランド), +5V, -5V, +2.5V, DG(多分デジタルグランド) が有り、プリンタポートとピン配置が異なる。パターンが引かれた C タイプ基板の束、多分 YDS シリーズ スイッチングレギュレータを動かすためのパターンが引かれている。ほぼベタパターンなのでケースの蓋や底板として使ってシールド板として使った方か良さそう? それとも表面実装半導体 TO252 の放熱板?ATMEL AT90S8535-8 と TLP2200 が小分け売りとレール(チューブ)売りで出ていた。シールとポップには TLP2200F と書かれている。レールを確認すると TLP2200 だった。F が付く / 付かないで規格が違う。AT90S8535 は 後継 ATmega8535 に比べて CPU 命令が少ないので開発環境で一手間掛かってしまうかも。AVR studio 4, WinAVR-20100110(これをインストールするとシステムの PATH 環境変数文字列が WinAVR 以外消されてしまう), C:\WinAVR-20100110\utils\bin\msys-1.0.dll 差し替え (msys-1.0-vista64.zip に含まれる msys-1.0.dll を使う、再差し替え) が必要。WinAVR をインストールする前に環境変数レジストリを保存する方法(PATH は hex 列で保存される)、管理者権限で cmd (コマンドプロンプト)を開いて、cd /D %USERPROFILE%\Documentsreg export "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" system-env.regその他レール売り品、uPC4570 (バイポーラ、GBW=15MHz, SR=7V/us, オーディオ用途向けローノイズ) は前来たとき有ったかな...入って右側のワゴンはスピーカがあった。ディスクリートアンプは八潮店限定販売になったのか...スピーカーはかつて販売されていた F02408H0、9253 が Date code だとすると約 33 年前に製造したはず。クリスマス、年末も製造していたってことか。ガレージの中を見て回る。今時の車はシガー(アクセサリ)ソケット有るのだろうか? USB とか Type-C PD, AC100V なのかな。ラックにあった訳あり B タイプ基板を買って見た。穴に目詰まり、ランドに半田半田滴の付着があった。足を通さなければどうと言うことは無い。FET が大分増えてきたような。32bit 192kHz ステレオ D/A をちゃんと動かそうとしたら、アルミ厚板削り出しでカバーかダイカストボックスに密閉か。太陽電池パネルはあまり変化が無い様な。さて、今年の夏は高温のエルニーニョ現象と原油不足原因の電力供給制限?太陽光自立発電運転で役立つ OA タップはヒット商品になるかな?HD61104 ってモノクロ液晶パネルのカラムドライバなのか。液晶以外に使えそうかというと、Zo=7.5kΩ (データシートでは RON と表記) なのか。出力を直接並列に繋ぐか抵抗を通して繋いで D/A コンバーターモドキ?手前の 4700uF 50V 電解コンデンサ、手持ちのリニアレギュレータ実験用電源に使えるかなぁ... 昔はとにかく大容量が正義だった。突入電流、力率、高調波、色々と気にすること多くなったよなぁ。平和な梱包資材コーナーだと思ったら、Nano VNA が吊り下がっている。防湿袋って、どこのご家庭にもシーラーとか有るのかな。パック詰めパーツの訳あり品が色々と。爪付きヒューズか、若い人だと見たこと無いかも。昔はカバー付きナイフスイッチ、陶器製の安全器(カットアウトスイッチ)に入っていた。電力会社が委託した電気保安点検で予備品を配っていたっけ。冷陰極管どうやって安全に持ち帰るかな... 八潮駅前のショッピングモール内 100 円ショップで食品ラップを買ってその筒の中に入れる?炊飯器って、ご飯食べていた?ヒートガンを使わずにシュリンクラップ?2SA1015GR がワゴンに乗ったのか... 東芝オリジナル品が無くなる日がくるのだろうな。
2026.04.14
コメント(0)

久しぶりに暖かい日差しになったので、少し遠いところにある東松戸駅付近のスーパーに行く。路上でバッタを見掛けた。足をたたんだ状態で体長は 35mm くらい。ツチイナゴかその仲間だろうか?調べてみると成虫で越冬するとある。今の時期に見掛けることもある昆虫なのか。
2026.03.28
コメント(0)

Aliexpress 荷物の追跡番号が 65xxxxxxxxxx となっていた。すぐに Aliexpress の追跡記録に「副都心EC第二営業支店」と出てきたので クロネコヤマトのネコポス扱いだとわかった。この番号はクロネコヤマトのサイトで追跡ができる。荷捌き量が少なかったのかエスポ便と比べて通関後から到着まで早かった。1 日で届く。クロネコヤマトって一度、Aliexpress 荷物から手を引いたというか、外部委託化と思っていたら、また手を付け始めた?
2026.03.25
コメント(0)

バックアップと復元(Windows7)をコントロールパネル内から起動したら次の様にダイアログが真っ白のままになってしまった。色々とやってみた挙げ句、次のコマンド入力が効いた。regsvr32.exe sdrsvc.dllバックアップと復元を司る SDRSVC.DLL をレジストリに再登録する。ここまで辿り着くのに AI 検索を使ってみた。回答を検証してみると、嘘や的外れな回答が多い。しかもそれをコマンドライン入力させる。一番驚いたのは sdcppkg.dll という有りもしない(少なくとも普通の Windows なら存在しない) DLL を regsvr32 /s sdcppkg.dll で登録しろと指示してきた。/s が厄介だ。存在しなくてもエラーを出力しない。あとで AI に問い詰めるとハルシネーションだと言い訳を始めた。最近は嘘がバレないように回答するのか?多分、嘘がバレると否定的な言葉あるいは回答は不適切だと返される。嘘とはバレない回答を選択すれば、肯定的返答が増えて出力選択確率が上がるのだろうな。なんだな、そろそろ バックアップと復元(Windows7) が予告も無く削除されそうな状況かもしれない。
2026.03.23
コメント(0)

2/22 20:50 頃にスカイツリーエレベーターが停止したとの速報を聞く。いきなり 110 番通報による状況検知だと聞いて、まさか?大きい加速度による自動通報?Android スマートホンには緊急情報サービスアプリがある(iPhone にも相当機能があると聞く)。上の画面のように自動車事故検出機能を使うことができる。大きい加速度が発生し、かつ、何らかの変化パターンに一致したら?に自動的に通報を発する。意図しない通報だった場合は、5 秒以内にキャンセルできる。キャンセルできなかったとしてもエレベーターに乗っている人たち全員が状況を説明できていない?後の報道を聞いて、深刻な事態ではなかったと分かる。原因は何だろうか?強風説がある。そうであれば 4 基停止かあるいは一部は減速してセーフモードに入ると思われるのに 2 台だけ停止?停止した 2 台の停止位置が違うので、ロープの共振周波数も違うはず。自分なりに電源異常説を考えてみる。東京電力PG の瞬時電圧低下の記録を見ると 2/22 に瞬時電圧低下の記録は無い。商用電源監視サーバーの記録を見てみる。2026/2/22 の記録の中から 20 時台の記録を見てみる。20:17:50 ~ 20:18:10 の間に電圧低下が発生している。このような事象は良く見るので特異な事象とは考えにくい。墨田区近辺で発生した事象を千葉県で観測した結果、小さな変動として見えている可能性はある。報道は 20:15 頃にエレベーターが停止したと 報じている。時間も 2, 3 分程度違う。スカイツリーはまだ登ったことが無い。お金が無いのが理由だ。もう一つ保守状況が良くないと思っている。下の画像は 2015年 頃に撮影した画像だ。一部ライトアップか消えている。この状態が長く(少なくとも数ヶ月程度)続いていたように記憶している。保守にお金を掛けることができないのか、保守性が悪いのか。何か問題が有った場合、対応に手間取る問題がありそうに考えている。なんだな、昭和の頃の話、電車をクリーム色一色に塗ってコストダウンを図る会社が親会社だからなぁ...
2026.02.23
コメント(0)

町中に衆議院選挙ポスター掲示板が設置されていた。昨日から見掛けている。今日が解散日だよなぁ。準備が良すぎる気がする。演出されているというか。良く見てみると、いつもは書いてある投票日が書かれていない。「選挙がある事なんて知らなかったんですよ」というお役所の立場表明か、それとも「総理大臣の専権事項に差し置いた行動は慎んでいますよ」という忖度か。そこまで急ぐなら、電子掲示板にして、画像入れ替えいつでも OK (タッチすれば経歴、政策も表示可能)、スマホ化したマイナンバーカードを使い毎日アプリで投票できる様にしたら良いのに。きっと高い政権支持率を維持できるに違いない。
2026.01.23
コメント(0)
Raspberrypi OS Trixie (Debian 13) release を QEMU で動かす対応 (リンク先は github の作業リポジトリ)を続けている。2026/2/22 追記 GitHub 公開している master branch をRaspberry Pi OS Trixie (Debian 13) 対応にしました(「実験的」に 32bit 対応しました。実行速度が遅くタイムアウトが頻発しています)。この対応により旧リリース Bookworm はサポートできなくなりました(両対応できるとしても日数を要します)。64bit(aarch64 or arm64) は対応に目処が立っている。文書整備を進める必要がある段階だ。bookworm (Debian 12) release で対応していた 32bit(arm or armhf) の対応を進めるか検討を始めた。情報を集め始めたばかりの段階で「32bit 対応はしない」という方向で考え始めている。Raspberrypi OS Trixie release 32bit は次の様に構成されている。Trixie Release の kernel は Raspberry Pi OS 32bit を選択しても 64bit(aarch64) であるUserland の binary は 32bit(armhf) である初期インストールされている gcc は arm-linux-gnueabihf-gcc-14 である詳細はこのリンク先にあるコマンドライン操作をした結果を参照してほしい。Trixie 対応するには kernel driver を build する必要がある。初期インストールされている gcc は armhf binary を出力する。kernel driver を build するには aarch64-linux-gnu-gcc-14 が必要になる。linux-header も aarch64(arm64) 向けの package が必要だ。遅いエミュレーション環境で gcc package をインストールする?恐らく /etc/apt/apt.conf.d/ 以下にファイルを追加して aarch64(arm64) linux-header package をダウンロードできる必要がありそうだ。そこまでして手を加えるか?作業時間が長くなりそうなのと、環境への影響が大きそうだ。もう少しだけ弄ってみるか...Raspberry Pi OS Trixie 32bit をインストールしたのに 64bit(aarch64) kernel なの?(リンク先は kernel boot log)、状況が飲み込めず混乱するところから始まった。
2026.01.20
コメント(0)

One shot 画像、多く評を語ることは無いと思う。あっ、そうだ食事中や食事前ならもう少し後でこの日記を見るのが良いと思う。うーん、何というかもっと良い形状というか施工は無いのだろうか?自分が生きてきた昭和の時代から色々と試されている。シックリきたことは無かった。強制吸引とか技術の限りを尽くす方法は有るのかもしれない。保守が大変か...この絵、Power Point ? Word? Excel? どれで書いたのだろうか? それとも生成 AI の名作なのかなぁ。
2026.01.18
コメント(0)

通勤をしなくなったので、ニュースで 1/16 の午前中に山手線停電障害が発生していたことを知る。停電の原因があった場所は田町駅なのか。品川、大崎、五反田に通勤していたことがある。世界線の分岐の乗り方次第では巻き込まれていた今も有ったのだろうな。ニュースの報道を見ると保護接地の外し忘れらしい。通常人が触れない電路を触る時(あるいは触れる恐れがある時)、作業の仕掛かり中で加圧(充電)することができない所がある場合、意図的に電路から切り離して、切り離した部分を接地する。並走する電線からの誘導で電圧が電線に乗ってしまい触れると感電する危険を防止したり、作業手順や状況の失念・勘違いで加圧してしまっても安全を確保する措置だ。誤って加圧した場合は、地絡保護リレーが働き、遮断器が切れる。大抵は上の画像の様に接地中で有ることを示す標識や旗を取り付ける。「接地旗」と呼ばれている。殆どの人は見たことが無い旗だと思う。その意味や状況を理解している人は少ないと思う。工事が終わった後に見ても「何だろう、この旗?」程度の認識で、電気工事担当に連絡すべき状況とは思わないのだろう。接地は2024/1/23東北新幹線上野~大宮間停電・感電事故を教訓にした措置のはず。
2026.01.17
コメント(2)

とりとめもなく書く。"reboot aging" と呼ぶテストをしている。前に仕事をしていた先で使っていたいわゆるローカル用語だと思う。reboot をひたすら繰り返すテストだ。組み込み開発でのやり方はいくつかあった。シリアルコンソールに teraterm を繋ぎ、マクロで login - reboot を繰り返す。watchdog を発動する様に仕向けて reboot する。スイッチ操作相当のことをして reboot する。普通にシャットダウンしてリブートするのではないか? 恐らくそう思う人が多いと思う。やってみると機能不全で立ち上がる。途中でハングする。ログが溢れて動かなくなる。想定以上に Flash Memory が損耗する。といった問題が露見することがある。QEMU 上で RaspberryPi OS Trixie を動かすことを試していて、reboot ができるように実装を進めていた。どうも「reboot するとハングアップしてしまうのでは?」という事象に遭遇する。初めのうちは「何かの見間違いか操作ミス?」と思っていた。手操作で 2, 3 回遭遇したあたりで、繰り返しテストを自動化しようと思い始める。/etc/init.d/reboot-agingとして配置するスクリプト/root/reboot-aging/reboot-aging.sh として配置するスクリプトスクリプトだけで reboot を繰り返す様にした。先に出したスクリーンショットに類似のハングアップ状態が 3 回得られた。様子を見ようと QEMU monitor の切り替え操作 [Ctrl]-[a] [c] を繰り返していると、kernel panic back trace が現れる。dwc_otg_handle_common_intr, dwc_otg_common_irq で何か悪いことが起きたのか。DWC (Design Ware Core) USB-OTG ドライバですか... 「またお前か」という既視感。デバッグはある程度進めていて、DWC の platform_driver の shutdown method が実装されていないのが原因だと推定している。shutdown method にて少なくとも割り込みマスク(割り込み発生を止める設定)が必要だということまで分かっている。推定を元に dirty hack な修正を実験中だ。Linux の kernel driver は open source で優秀なエンジニアが書いて、レビューをして、テストをしているから、安定して動くというのは幻想だ。実際はちょっと激しく叩くと問題が露見する。ログとか Flash Memory の問題は OS が立ち上がってからの処理なので対応は比較的容易だ。reboot を繰り返して出てくる悩ましい問題の例は初期化に問題があって機能不全Clock, Power domain 制御に必要な待ち時間が確保されていない(Linux kernel 内の clk, regulator class driver はある程度考慮されている)割り込み処理の準備が整っていないのに割り込みを発生させて handler が動いてしまう、あるいは動かずに IRQ storm 状態に陥るDMA controller 連系などがあるのに連系先の準備ができていない状態で動作開始Firmware download のタイミングが遅く、仮 firmware で動いてしまう終了処理に問題があって望ましくない終了状態device context を破棄してしまったのに割り込み処理をしてしまう道連れに止めきれなかった timer, work, thread が動いて片付け終わった領域・レジスタを操作してしまう連系先は既に止まっているのに使おうとする入出力端子が望ましい状態では無く、電圧・電流が出たままと言ったところだろうか。今時は階層構造の整備, device tree による構造表現が整備されているので、問題は起きにくくなっている。なんだな、除夜の鐘をつく回数 108 回よりは多く連続 reboot できてほしいものだ。
2025.12.31
コメント(0)
![]()
Aliexpress で買い物をしたらキルギスタン経由荷物になってしまった。初めは Cainiao Super Economy Global 扱いで AP007xxxxxxx4645 という追跡番号が付番された。途中からキルギスタン経由を示す UN9xxxxx982KG という追跡番号も同時に付くようになった。発送日から 27 日後にポスト投函にて受け取った。買った日を含めると 29 日掛かっている。うーん、ラベルに 0.2 USD と書かれている。3 USD くらいの物を買ったつもり。"Priority Small Packet" って、「優先配達の小さな荷物」ではなくて「優先度が小さい荷物」ということなのか。Aliexpress の追跡情報 (Track Order) を受取日に近い方から並べる。空港出発待ち → 地元配達業者の記録は次の通りだ。空港を離れるまで 3 日掛かっている。情報を真面目に受け取るなら空を 7 日間飛んでいることになる(空港内保税地域に留まっている時間が長い?)。17trackから得た情報だと 11/23 にはキルギスタンの空輸業者に渡されていて 11/29 には日本に着いている(後で示す)。空港に着くまでの Aliexpress 記録はいつも通りの中国国内 Seller 発送 → 仕分けセンター → 空港だった。輸出税関検査が無いのが気になる所だ。17track で AP007xxxxxxx4645 を追跡すると Aliexpress の Track Order と同じ情報が得られた。微妙な表現の違いはある。荷物ラベルに印刷された内容物説明を読むと 11/21 にラベルが貼られた様に思える。キルギスタンが返送先になっているラベルを Fenggang Town で貼り、まとめてキルギスタン内拠点に送っている?17track の More info からも UN9xxxxx982KG が次の追跡番号だと分かる。あれ?輸送中に UN9xxxxx982KG 追跡情報を得られたっけ?着荷してから見ることができるようになった気が... どうなったか心配であれば次の追跡番号が分かった時点で 17track で追跡を試すのが良いのかも。得られた追跡情報を突き合わせる。しっくりこない。Fenggang Town で荷造りして実質 8 時間以内にキルギスタンに着くのだろうか?時間が掛かったところは、キルギスタンで航空便待ち 5 日 (11/21→11/26、Aliexpress の情報と合わない)空輸 3 日 (11/26→11/29)日本国内通関?配達業者集荷 4 日 (11/29→12/02)ポスト投函ルート乗せ 15 日 (12/02→12/17、あるいはこの期間に通関が入っている?)UN9xxxxx982KG は国際郵便の追跡番号に見えても日本郵便の追跡サイトでは追跡できず。
2025.12.17
コメント(0)

青森県八戸市の NTT 局舎の上に立つ鉄塔が地震によって損傷した状況はまだ収束に至っていない。NTT (というよりは電電公社)の局舎にある鉄塔は物心ついたときから興味の対象だった。今から 50 年くらい前、5 歳くらいの時だろうか、自分が住む地域の近くに電電公社の局舎とその屋上にマイクロウエーブ回線用鉄塔が建った。NTT高塚今の画像に写る鉄塔には携帯電話の基地局アンテナが取り付けられている。以前は南の方を向いたパラボラアンテナが 1 基最上段に取り付けられていた。方向からして船橋か中山の方だと思っていた。電電公社局舎が建ち、パラボラアンテナを備えた塔がそびえる光景は「僕らの町」が発展している象徴だった。塔の構造は恐らくどこにでもある標準設計だと思う。良く見ると青森県八戸市でニュースになっている構造と比べて筋交いの入り方が違う。逆 V 字型に入っている。コスト削減なのか、耐震性向上の変化なのか。今時の固定電話手続きはほぼ Web で完結する。昔は営業窓口がある電電公社に出向いて手続きした。母に連れられて、共同電話を戸別回線に変更する手続きをしたのを覚えている。NTT松戸 昭和 40年~50年 頃は 1 つの電話回線を数戸で共同で使っていた。電話を掛けたり共同で使っている別の電話機が使われると、今で言うとローゼット端子がある位置にあるパウンドケーキ大のリレーボックスがカチッと鳴って回線が切り替わった。1 世帯当たり、2回線が使える様にメタル回線を強化する工事が行われて、これを機会に共同回線を戸別回線にした。昭和-平成-令和を振り返ると強化された通りに 1 世帯 2 回線(あるいは ISDN)は使われず、携帯電話、ADSL、VDSL、IPv6 光ファイバーへと移行し、増強したメタル回線は半分使われずに遺物になってしまった。昭和の頃は高層建築物はそれほど多くなく遠くの局舎にある塔もよく見えた。NTT市川中山電車の車窓から沢山のパラボラアンテナやホーン型アンテナが付いた電電公社の塔が見えた。NTT船橋湊町旧街道沿いが国道になり、その道筋の宿場町や寺社仏閣周辺にある町の発展を支えるように増強された局舎とマイクロウエーブ中継回線鉄塔、地震で損傷した場合は周囲の車・鉄道などの交通物流を止めてしまうのだろうか?自転車で散歩していたときに見つけて印象的だった塔をいくつか。柏市豊四季、長閑な周辺の町並みと比べると随分と頑丈に見える局舎と塔だった。あれ?近所に防衛施設とか、秘密基地とかあったっけ?NTT豊四季 台東区白鬚(あるいは清川と言った方が良いのだろうか)、周りの高層ビルに埋もれないよう高い塔が建つ局舎だ。NTT 白鬚(しらひげ) この付近に物理的なファイヤーウオール都営 白鬚東アパートがある。江戸の大火、あるいは関東大震災の大火によって焼失を経験した地域に近い。興味深いことに NTT白鬚、東京ガス供給拠点(東部導管ネットワークセンター)、清川清掃車庫、JR貨物墨田川駅、少し西に東京電力パワーグリッド上野支社、少し南に東京電力パワーグリッド蔵前変電所といった重要施設が集中する。人体で言えば五臓六腑と言える場所。八千代市米本にある塔は、小さいときの記憶が正しければ成田空港闘争で襲撃を受けた施設だ。親戚の家に近かったこともあり、ニュース映像で見たときに、あれ?見覚えのある景色だ。と思った。NTT米本(と言ったはず)電話回線ケーブルも幾度となく破壊工作の対象になった。襲撃事件の後、電話と電力マンホールは接着剤で開かないように固定される様になった。マイクロウエーブ回線は光ファイバーに置き換わり、パラボラアンテナを外した後も最低限の保守を続けて、オーバースペックな携帯電話基地局として使い続ける積もりの塔だったはず。地震で損傷・倒壊するかもしれない心配が増える遺構になってしまうとは。
2025.12.16
コメント(0)
Raspberry Pi OS trixie を QEMU Raspberry Pi model 3B Emulator で動かすためにbcm2835 power off driver (dkms driver の tar.gz file)を作ることにした。power off をするだけのドライバだ。QEMU の command line option か image file の中に含まれている /etc/systemd/system.conf の設定で watchdog を止めて power off 機能を維持する方法を発見できていない。device tree の watchdog node の compatible property の文字列を "brcm,bcm2835-pm-power-off" に変更して引き当てるドライバを作ったドライバにする。--- bcm2710-rpi-3-b.dts 2025-12-09 01:03:29.282524500 +0900+++ bcm2710-rpi-3-b-qemu.dts 2025-12-13 22:38:50.123397200 +0900@@ -868,7 +868,7 @@ }; watchdog@7e100000 {- compatible = "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt";+ compatible = "brcm,bcm2835-pm-power-off"; #power-domain-cells = ; #reset-cells = ; reg = ;@@ -876,6 +876,7 @@ clocks = ; clock-names = "v3d\0peri_image\0h264\0isp"; system-power-controller;+ status = "okay"; phandle = ; }; QEMU で動いている Raspberry Pi OS にbcm2835 power off dkms driver (リンク先はドライバの tar.gz file)を組み込む。sudo apt install dkms build-essential kmodsudo tar -C /usr/src -xvf /down-loaded/bcm2835-power-off-dkms-1.0.tar.gzsudo dkms build bcm2835-power-off-dkms/1.0sudo dkms install bcm2835-power-off-dkms/1.0Makefileは command line から dkms を使わなくても使える様にしてある。dkms で組み込めば(恐らくコマンドラインで手動で組み込んでも)起動したときに device-tree の compatible property からドライバを自動的に引き当てる様になる。やりたいことに対して大掛かり過ぎる感はある。「一つ解決策を見つけておく、上手い方法は他の誰かが見つけるさ」 色々と開発を経験してきて採るようになった自分なりの開発方針だ。
2025.12.15
コメント(0)

共立エレショップで買った部品の発送を頼み、荷物を追跡していたら奇妙な状態になったことに気づいた。次の状態が同時に発生していた。ご来店予定(保管中) いわゆる営業所止め営業所止めを指定した覚えは無いどこの営業所か不明受取:送り状の住所(対面)置き配指定できます日時を変更する(対面・置き配)グレーアウトしていて選択不可場所を変更する(営業所・コンビニなど)グレーアウトしていて選択不可荷物は一体どうなるの?「再配達依頼が無い場合は返品する」と表示されている。どうにもおかしな状態だ。電話してオペレーター扱いを試みる。朝一は混んでいたので 9:45 頃に電話した。送り状番号をオペレーターに伝えて困っている旨を伝えた。初めはオペレーターも状況を把握できず、混乱していた。Web で変更できますよね?という提案を受けのに対して、変更できなくなっていると返答、こちらでは手段が無い旨を伝える。混乱が落ち着いた所で配達を当日午後時間指定で配達を頼んだ。多分午前配達になる所、2, 3 時間の遅れ配達になったと思う。オペレーターは配達拠点営業所で登録する際に「保管(配達予定)」を「保管(営業所止め)」で登録したのでは?と推察していた。うーん、システム的に矛盾した状態だと検出できるはずなのに...最近ヤマトの荷物追跡ページが少し変わったような... もしかして流行の AI コーディング(バイブコーディング)をしたの?あの何も矛盾とかおかしな所を全く検証しないハッタリ・トンデモコードを提案してくる仕掛けを使った?
2025.12.14
コメント(0)

12/08 23:16 頃周期が長めで長時間続く地震を感じる。水平方向へ揺すられる感覚が強い。「遠くで地震かな」と考えた。青森県東方沖が震源の強い地震だった。商用電源変動記録を見てみたら、地震による変動が見られた。地震変動の様相がいつもと違う。23:16:10 ~ 23:16:20 頃に 0.1Hz 程の周波数低下が発生している。周波数低下が先行して 2 ~ 3 分後周波数が 0.2Hz 程急上昇している。珍しい変動だ。地震で見られる反応は負荷停止による周波数上昇が先行する場合が多い。ニュース記事(その1) (その2)を見ると苫東厚真火力発電所が停止、北本連系線も停止したようだ。北本連系線は調相設備に火災が発生した様だ。東京電力管内-東北電力管内-北本連系-北海道電力管内の様に繋がっているので、北海道電力管内の発電所停止が影響したのかもしれない。北本連系線は北海道胆振東部地震と同様に過潮流で停止した? 北海道→本州 潮流が急に 本州→北海道 に変わり、さらに過負荷停止になったか。調相設備火災は 12/9 4:45 に発生なので地震の揺れによる構造変形が原因?それとも過潮流によるダメージが時間経過で悪化したか。北海道全域停電は免れた一方で連系系は揺れによる構造変形か 2 分程度の過負荷でダメージを負ったのかも。北海道・三陸沖後発地震注意情報なのか。後発地震があった場合、手負いの北本連系で全域停電は死守で回避?
2025.12.09
コメント(0)
Aliexpress 通販で買い物をした。自分の荷物はいわゆるキルギス経由の UNxxxxxxxxxKG という追跡番号の荷物なので到着までに時間が掛かる(2025.12.18 荷物が届いたのでその日記のリンク追記)。良く知れ渡ったことだ。遅い理由をネットで調べていると、どうも中国から日本に直行する荷物も最近遅くなっているようだ。いわゆる 11.11 セールとか Black Friday は セールのピーク影響だけでは説明が付かない遅さのようだ。Aliexpress 海外通販出荷で普通に使われる Economy Cargo が遅くなっているのだろうな。Economy Cargo は航空機の荷物室に「空きが有ったら」そこに詰めて送る低優先度の輸送サービスだ。今の国際情勢、そもそも中国から来る航空機が減っている。遅くなるのだろうな。ネジ・クギも最近は中国産だ。今はインバウンド低迷ばかりが注目されている。そのうち物が作れない。注文があっても出荷できない。倉庫が空っぽになったと騒ぎが大きくなるかも。
2025.12.08
コメント(0)

ガス・ガバナで圧力調整ができずにガス器具から火が吹き出す事故が多発したニュースを見る。ガバナが不調になると発生する事故のことはあまり考えていなかった。場所を知っているガス・ガバナ施設を見に行く。昔のガス・ガバナ施設は分かりやすい大きな釜のようなタンクがあった。今時は目立たない箱形の建物か、金属箱だ。上の画像のガバナは排気管と動作状態ランプと思われる器具が付いている。屋根は爆発が有った場合、恐らく上に吹き飛ぶ様に作られている。金属箱型のガバナは外観から何の設備だか分からないほどに飾りや特徴が無い。文字板にガス整圧器(あるいは同様の意味)が書かれているか、ガス会社の社名やロゴで機能を確認できる。こちらは電源と通信線が繋がれている様に見える。遠隔監視していると思われる。圧力異常の場合、排気管からガス放出して周囲は強いガス臭がするのだろうか?今までガバナ周りで臭いを感じたとことは無い。
2025.12.05
コメント(0)

楽天ペイの支払いで取り消し(キャンセル)をした。楽天ペイアプリの画面ではすぐに取り消し記録を確認できた。楽天ペイの支払いにデビットカードを設定してある。デビットカードの出金記録は即時に付いた。返金の入金記録は即時では無かった。キャンセル当日を含めて 5 日後に返金入金記録が付いた。支払い経路は支払い先から順に、楽天ペイ加盟店(日帰り銭湯) - 楽天ペイ - デビットカード(VISA 扱い) - 銀行(楽天銀行では無い) だ。支払いもキャンセルも機械処理だった。調べてみると 返金までの時間は楽天銀行が支払い元にて最大 10 日ほどとあった。調べ方次第で 61 日という情報も有った(AI 検索のトンデモ情報という感がある)。いつ返ってくるのだろうか?と心配になる。キャンセル理由は自分の体調不良を日帰り銭湯のリラクゼーションサービスに申告したところ、施術できないとのこと、利用料金を返金にて退店となった。楽天ペイ払いは出金入金に時間差が生じるのか... キャンセルの可能性がある場合は使い方気をつけないと。
2025.12.04
コメント(0)

2026/2/22 追記 GitHub 公開している master branch をRaspberry Pi OS Trixie (Debian 13) 対応にしました。script と driver で Raspberry Pi OS を QEMU 上で動作させ GUI desktop も動作します。この対応により旧リリース Bookworm はサポートできなくなりました(両対応できるとしても日数を要します)。QEMU で RaspberryPi OS Trixie の GUI Desktop を動かすことができた。前の日記の続きで watchdog は無効化した状態に追加の修正を加えている。QEMU で起動する流れで関係がある修正を順に示す。Kernel parameter に bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768 も追記する必要がある。次は qemu-system-aarch64 に渡す option で書いた例だ。-append "console=ttyAMA1,115200 console=tty1\ root=/dev/mmcblk0p2 rootfstype=ext4 fsck.repair=yes rootwait\ dwc_otg.fiq_fsm_enable=0\ bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768\"Xorg で動く様に raspi-config で設定する。sudo raspi-configで起動すると容易に操作できる Text Graphic Interface が始まるので 6 Advanced Options / A7 Wayland / W1 X11 Openbox window manager with X11 backend で設定する(この設定だけでは QEMU 上で GUI Desktop は起動しない)。display-manager.service (実体は lightdm.service) の設定を修正する。sudo systemctl edit --full display-manager.service で次の様に修正する。--- /lib/systemd/system/lightdm.service 2025-03-15 00:02:00.000000000 +0900+++ lightdm.service 2025-11-25 13:14:40.222838504 +0900@@ -1,8 +1,10 @@ [Unit] Description=Light Display Manager Documentation=man:lightdm(1)-After=systemd-user-sessions.service dev-dri-card0.device dev-dri-renderD128.device-Wants=dev-dri-card0.device dev-dri-renderD128.device+#After=systemd-user-sessions.service dev-dri-card0.device dev-dri-renderD128.device+#Wants=dev-dri-card0.device dev-dri-renderD128.device+After=systemd-user-sessions.service+Wants= # replaces plymouth-quit since lightdm quits plymouth on its own Conflicts=plymouth-quit.service/etc/lightdm/lightdm.conf を修正する(差分ファイルのリンク)、(修正後のファイル、lightdm-qemu.conf を lightdm.conf にリネームして /etc/lightdm 以下に配置する)。差分は次の通り、logind-check-graphical=false に変更する。このようにすると lightdm.service が Xorg を起動する様になる。--- lightdm.conf 2025-11-25 13:45:47.000000000 +0900+++ lightdm-qemu.conf 2025-11-30 02:11:13.000000000 +0900@@ -26,7 +26,7 @@ #lock-memory=true #user-authority-in-system-dir=false #guest-account-script=guest-account-#logind-check-graphical=true+logind-check-graphical=false #log-directory=/var/log/lightdm #run-directory=/var/run/lightdm #cache-directory=/var/cache/lightdmXorg 設定ファイル /etc/X11/xorg.conf.d に Device, ServerLayout, Screen, Monitor を記述した 00-fbdev.conf を配置する必要があった(00-fbdeb.conf ファイルのリンク)。Section "Device" Identifier "Card0" Driver "fbdev"EndSectionSection "ServerLayout" Identifier "ServerLayout0" Screen 0 "QEMUFB"EndSectionSection "Screen" Identifier "QEMUFB" Device "Card0" Monitor "QEMUFBPanel" DefaultDepth 24 SubSection "Display" Depth 24 EndSubSectionEndSectionSection "Monitor" Identifier "QEMUFBPanel" VertRefresh 60EndSectionwatchdog 無効化に対してBooting Debian Trixie (13) on Qemu(Disable watchdog by modifying /etc/systemd/system.conf) が提案されていた。自分の手元では上手くいかず。RuntimeWatchdogSec, RuntimeWatchdogPreSec の設定も上手くいっていない。systemd の設定で watchdog の問題解決はできていない。まだスクリプト化をしていない。(2025/12/10 追記 GitHub に Raspberry Pi OS を書き込んだ SD card からイメージファイルを作成し QEMU で GUI desktop を動かすための修正をするスクリプトを公開しました。まだ作業途上です。watchdog を動かさないようにしているので shutdown をしても QEMU は動いたままです。QEMU の monitor console にて [Ctrl]-[a] [q] にてエミュレーションを終了する必要があります。)
2025.11.30
コメント(0)

新野田変電所で作業事故があったようだ(新聞記事なので消えるかもしれない)。商用電源監視サーバーの記録に 11/26 18:43:50 頃に瞬時電圧低下があったことが記録されていた。東京電力パワーグリッドの瞬時電圧低下記録 11月26日 18:43 に栃木県、群馬県、埼玉県、千葉県、東京都、山梨県、神奈川県、静岡県 で瞬時電圧低下が発生したと記録されている。500kV 系統かその下流の 275kV 系統で事故が起きた?同時刻に停電記録もある サージ電圧で放電した?急に周波数は 0.1Hz、電圧は 2.0V ほど上がっているのは瞬時電圧低下で停止した器機類が原因だろうか。あるいは 500kV 系統の遮断器を瞬時(恐らく 0.5 ~ 1 cycle の間)に操作して事故周辺切り離しをして迂回路を接続したのだろうか?夕飯時、突然 IH コンロ、電子レンジ、電気釜が停止して料理中断?気づかずご飯が炊けてなかったとか...1999年には世界最大の変電所として記録された新野田変電所、自転車で見に行ったこともあった。今は体調が良くなくどうなっているのかは見に行けず。
2025.11.26
コメント(0)

Raspberry Pi OS が更新されて Debian 13 "trixie"になった。QEMU 上で上手く動かせていない(GUI desktop が動く様になる追加修正)。2026/2/22 追記 GitHub 公開している master branch に含まれる script と driver で Raspberry Pi OS Trixie (Debian 13) を QEMU 上で動かすことができました。この対応により旧リリース Bookworm はサポートできなくなりました(両対応できるとしても日数を要します)。2025/12/10 追記 GitHub に Raspberry Pi OS を書き込んだ SD card からイメージファイルを作成し QEMU で GUI desktop を動かすための修正をするスクリプトを公開しました。まだ作業途上です。watchdog を動かさないようにしているので shutdown をしても QEMU は動いたままです。QEMU の monitor console にて [Ctrl]-[a] [q] にてエミュレーションを終了する必要があります。今のところ console mode で起動する様になった。対応作業の途中経過はgithub qemu-raspberrypi の follow-trixie に入れてある。状況と課題を挙げる。device tree を修正して watchdog を止める必要がある (修正 diff), (修正後の source), (修正後の device tree blob (表示はできないと思うので download をして下さい))上記に伴い shutdown をしても QEMU が終了しなくなった。watchdog driver が shutdown driver も抱えている。GUI desktop が動かない。/dev/fb0, Xorg driver 周りの問題だと思う。原因を特定できいない。最新の QEMU 10.1.50 を使わなくても動くのか?あー、bookworm (Debian 12) から kernel, initrd, kernel module だけ持って来る?
2025.11.21
コメント(0)

Redox OSを試す。動機はごく単純に rust で書かれた OS に対する興味だ。試し始めてすぐに「使えない」という結論になった。ここからは自分で可能な試行と解釈の結果で書いていく。他の人と意見が合わないかもしれない。まず現実的に実行可能な環境はQEMU Emulator 一択 (リンク先は Running Redox in a Virtual Machine - Redox OS)だ(Redox OS を QEMU にインストールしてみた結果をまとめたページへのリンク)。実マシンで動くとの説明は「そうかもしれないけれど」という疑問がある。試した結果、PS/2 Keyboard(US 配列限定), Mouse でのみ操作可能 (USB HID をサポートしているとの説明に対して、動いた環境は無かった)HDD/Optical drive の IDE 接続は ISA BUS address 空間に配置されている H/W だけ動作する(PCI Bus Configuration Register で配置情報が得られる I/F はサポートしていない。ソースコードを見る限りレジスタが Memory Mapped になっているのは非対応)SATA 接続の HDD は認識しないか認識・読み込み途中でハング(恐らくアクセスタイミングや手順に問題がある)サポートしているネットワークカードはRealtek RTL8139, Realtek RTL8168, Realtek RTL8169, Intel 82543GC, Intel 82540EM, Intel 82545EM, Intel 82573L, Intel 82579V だけだ。Realtek RTL8139, RTL8168, RTL8169 系列の OEM VID:PID や互換/クローンチップはサポートされていない(この様に判断した8139 driver と8168 driver のリンク)。Intel NIC も大雑把に e1000 系列であってもサポートは限定的だ(e1000d driver のリンク)ほぼ骨董品になってしまった PC, Keybpard, Mouse, NIC, IDE-HDD, IDE-Optical Drive を見つけて動かすしかない。骨董品が見つかり揃ったったとして、絶望的に Live USB Memory や CD-R(他の光学媒体も同様) の読み込みが遅い。精々 1 ~ 3Mbytes/sec の読み込み速度で live image を主記憶に読み込む。600Mbyte 程あるので、(linux で言う所の kernel + initrd) 起動だけで 3 ~ 10 分程度待たされる。それで起動すれば良い。大抵は HDD を認識したところでハングするか、起動まで漕ぎつけたとして、インストール先の HDD が見つからない。普通の人なら、窓から投げ捨てるだろう。自分はこの時点でやる気ゲージが 50% まで落ちてしまった。VirtualBox を普段使いしている人もいるかもしれない。VirtualBox は使えない。実マシン同様にHDD のアクセスに問題が有り(リンク先はログ、末尾に VirtualBox が検出した問題が記録されている)(VirtualBox は実マシンで起こりえる問題も厳密にエミュレーションしていると思われる)、Frame Buffer 書き込みで CPU cache 制御の問題も露見している様に見える(こちらも厳密エミュレーションなのだろう、そして実マシンで起動のための読み込みが遅いのも cache 制御に問題が有りそうだ)。QEMU で動かすことに辿り着き、試しにプログラムを動かしてみる(リンク先は試したプログラムのソースコード)ことにした。rust で書かれた OS には失礼だとは思いつつ C 言語と bash を使う。必要な package を GUI の cosmic-terminal ウインドウで sudo pkg install git gcc13 gnu-make gnu-grep と入力してインストールする。Page fault: 000000000000000C USRFLAG: 0000000000010297CS: 000000000000002bRIP: 000000000061ad77RSP: 0000000000d61e00SS: 0000000000000023FSBASE 000000000023e000GSBASE 0000000000000000KGSBASE ffff80007fc64000RAX: 0000000000000001RCX: 0000000000000000RDX: 0000000000000000RDI: 0000000000000004RSI: 0000000000000000R8: 0000000000000000R9: 000000000061ad70R10: 0000000000000001R11: 0000000000000246RBX: 0000000000000004RBP: 0000000000000010R12: 0000000000d61e60R13: 0000000000000018R14: 0000000000000001R15: 0000000000000000 FP ffff80000f02fe80: PC ffffffff8007c115 FFFFFFFF8007BF40+01D5 kernel::arch::x86_shared::interrupt::exception::page::inner FP ffff80000f02ff50: PC ffffffff80078e87 FFFFFFFF80078E50+0037 kernel::arch::x86_shared::interrupt::exception::page 0000000000000010: GUARD PAGEいきなり segmentation fault ですか(メッセージに UNIX 伝統の segmentation fault は含まれない。とは言ってもアドレス 0x000000000000000C って NULL pointer で指した構造体メンバーのアドレスだと思う)。え? rust で書いて segmentation fault ってあるの?なんだかなぁ... この問題は QEMU の monitor/terminal 混合ターミナル(Linux を動かすと serial port の tty になる疑似端末)で 操作すれば解決した。やる気ゲージ 20% down。Linux 上で一通り動作確認してたのですんなりコンパイルができて、動くかと思っていたら、コマンドライン解釈に問題がでた。getopt() が動作しない。何かの error return とか、"Not Implemented" の様なコンソールメッセージを出力するのかと思っていたら、沈黙をもって動作しない。うん、ここに辿り着くまでに次のような未実装メッセージを散々見ている。example 1: setsockopt(23, 1, 9, 0x20c7e0, 4) - unknown optionexample 2: relibc getgroups(65536, Pointer { addr: 0xd5a0, metadata: 65536 }): not implementedexample 3: relibc getrlimit(7, 0x7ffffffffba8): not implementedやる気ゲージ 10% down。ああ、普通に動いていない環境なんだ。普段使いは JP keyboard なので、US keyboard 入力を強要する GUI にも不満が溜まる(keyboard driver を見ると layout は hard coding だし JP layout は stub すらない)。急遽 getopt() の簡易代替実装をする(ソースコードのリンク)。コンパイルも通ったし、実装した個別のコマンドも動くようになった。test loop が回りだしてしばらくすると、kernel panic が起きる(起きなくても loop が途中で動かなくなって、UNIX で言う所の kill -HUP $pid をしないと終了しない)。できることは QEMU 毎終了するだけだ。KERNEL PANIC: panicked at src/memory/mod.rs:954:9:allocator-owned frames need a PageInfo, but none for [frame at 0x7ffffffffffff000] FP ffff800016caf730: PC ffffffff80050e55 FFFFFFFF80050CD0+0185 kernel::panic::panic_handler_inner FP ffff800016caf820: PC ffffffff8004ef39 FP ffff800016caf830: PC ffffffff800a732f FP ffff800016caf860: PC ffffffff80075d90 FFFFFFFF80075AF0+02A0 kernel::memory::deallocate_p2frame FP ffff800016caf8f0: PC ffffffff8001d2ae FFFFFFFF8001CAC0+07EE <kernel::context::memory::AddrSpace as core::ops::drop::Drop>::drop FP ffff800016cafac0: PC ffffffff80033b1c FFFFFFFF80033B00+001C alloc::sync::Arc<T,A>::drop_slow FP ffff800016cafb30: PC ffffffff80049d8f FFFFFFFF80049720+066F <kernel::scheme::proc::ProcScheme as kernel::scheme::KernelScheme>::close FP ffff800016cafc40: PC ffffffff800968ea FFFFFFFF800964B0+043A kernel::context::file::FileDescription::try_close FP ffff800016cafcd0: PC ffffffff80096464 FFFFFFFF800963A0+00C4 kernel::context::file::FileDescriptor::close FP ffff800016cafd40: PC ffffffff80066baa FFFFFFFF80066A30+017A kernel::syscall::fs::close FP ffff800016cafd70: PC ffffffff8006b2c3 FFFFFFFF8006AEF0+03D3 kernel::syscall::syscall FP ffff800016cafea0: PC ffffffff8005f6ee FFFFFFFF8005F640+00AE __inner_syscall_instruction FP ffff800016caff50: PC ffffffff80058693 FFFFFFFF80058650+0043 kernel::arch::x86_64::interrupt::syscall::syscall_instruction 0000000000000000: GUARD PAGECPU #2, CID 0xffffff7f801b7f20NAME: /usr/bin/tr, DEBUG ID: 825SYSCALL: close(8)HALTpipe line / redirect で繋いだ file descriptor の close() で問題が起きる?と言うことは、file descriptor で参照するかその操作で更新する情報の reference counter が不正操作されるか、そもそも up / down が必要な処理が抜けているか余計なのか。あれ、rust って Rc<> とか Arc<> とか有るんじゃなかったの(kernel 用に再実装するとして設計思想的に強要されるやり方では)?ここまできてやる気ゲージは 0% になった。他にも一々 UNIX 系 command とコマンドラインの使い方が違うとか、おせっかいすぎる completion とか、不便は微塵も感じていなかったことが変わっている。変えた意図を汲めないことが多い。rust への理解は殆どない。それでもRedox OS を実装している rust のソースコードを眺めて思う。rust を使えば Linus 氏程の才能が無くても安全かつ安定して動く kernel を書けるようになる訳では無いと。
2025.11.04
コメント(2)

久しぶりに Metronix model 521C のことを書く、前回は入手した 4 台の様子とシミュレーション用の回路図について書いた。改造を元に戻すために Unit #1 (前回の日記参照) の基板を取り出して調べたときの記録を書く。基板はトランスとスズメッキ線と単線を剥いた先で繋がっている。はんだごてを当てて外す。センタータップ付きの正負電源用 3 箇所(21, 22, 23)と、シールド接続(S1) の 1 箇所、計 4 箇所で接続されている。部品配置と機能の区分けは次の様になっていた。小信号用トランジスタを一直線に配置しつつも分かりやすいように纏まっている。上記画像の PNG 高解像度板おおよその動作確認用に各部 {GND, Ve6r5, Vee, Vref, Vc13r3, Vcc} の電圧を確かめる点を示しておく。画像に小さな札を振ってある。札の中の文字は端子を示す。基準電圧 GND は Model 524B と同様に (OUTPUT switch ON で) 正出力端子 と繋がっている。要注意だ。主電源の平滑回路の電圧は、1000uF 50V (世代によっては 2200uF かもしれない) 大型電解コンデンサの両端電圧で示した。32.6V である。綺麗な配置よりは、熱結合にもう少し気を使っても良かった様に思う。シルクハット型トランジスタは貼り合わせや海苔巻き作りは難しいか...基板のパターン面画像も撮影した。パースを修正して部品を書き込み、隠れてしまったパターンを書き足してある。試行錯誤しながら部品を書き込んでいるので間違いがあるかもしれない。部品面から透かして見たのと同じになる様に鏡像反転した画像3次元空間での回転のみ掛けた画像故障したら部品交換するのかなぁ... それとも今時の素子で作り直すのか...
2025.10.22
コメント(0)

Metronix model 521C をオークションで 4 台手に入れる。3,000円、安かったのには理由がある。下の画像を良く見ると判る様に改造されている。道理で入札競争が起きない訳だ。Unit #1, #3, #4 が改造されていた。#1, #3, #4 の出力電圧は 最大 3V ~ 3.5V、Unit #1 の最大電流は 30mA だった。#4 には 20V 電圧計が付いている。ツマミを回しても最大 3.5V だった。半導体類は全てディスクリートで構成されている。改造の種として好適だったのかも。最大電圧 3V ~ 3.5V, 電流 30mA 程に制限して何に使ったのだろうか?メッキに使っていた? 最大 30mA のユニット #1 はスプーンから弁当箱程の大きさの試作金物向けかな。背面にヒートシンクと TO-3 パワートランジスタを背負ったお決まりのデザインだ。昭和な安定化電源が背負うトランジスタの金属ケースは GND (ケースあるいは負側端子) と同電位ではない。うっかり金属パネルや支柱に触れるとショートする。トランジスタは Toshiba 2SD211-Y または NEC 2SD287 だった。名前は同じ Model 521C なのに部品が違う。改造の際に差し替えた?差し替える積極的な理由は無いと思う。そう言えばヒューズが無いのか... 中を確認するとスイッチを間に挟んで商用電源線はトランスと繋がっていた。ヒューズは中にも入っていない。昭和 40 年代的な設計だなぁ...1 次側トランス端子は左右に分離して配置、ケース内商用電源直通配線の短絡もほぼ起きない、2 次側短絡の場合ダイオードブリッジがいずれオープンに至るから大丈夫ということ?先にMetronix model 521C を LTSpice でシミュレーションするための回路 (リンク先は ZIP File)を出しておく。Metronix 521C LTSpice circuit PDFUnit #1 を元の仕様に戻すときに調べて回路を起こした。Unit #1 ~ #4 の違いは汲み取っていない。Model 521C の回路と次の様な違いがある。V1, V2, V3: トランスの代わりに交流電圧源を配置D3, D4: 実測値に近いツエナー電圧のダイオードを選択J1, R8: J1 に J201 を使ったので Q5, Q8 の Emitter 電流を近づけるため R8 を 2.7kΩ から 3.3kΩ に変更Q1a, Q1b, Q1c: 2SD111-Y の代わりに 3 連の 2SCR586D3 を充てるR3, Vcc, Vc13r3: CC 動作時の出力リプル低減のため R3 の電源ラインを Vcc から Vc13r3 へ変更、Q2.Collector に掛かる電圧値を調整するため R3 の抵抗値を 1kΩ から 470Ω へ変更半導体全般: LTSpice で使える素子に置き換えCapacitor ESR: おおよそ妥当な値を設定Rvm, Rcm: Rvm=電圧計、Rcm=電流計 内部抵抗は仮の値Qload, Iloadgen: 出力端子に繋いだ仮の負荷Model 521C により近いシミュレーションをする場合は、回路を修整して欲しい。Unit #1 から Unit #4 の制御基板を見ていく。Unit #1 は仕様を元に戻した後に撮影した画像だ。字幕 Revert mod 付近に写る皮膜塗装が緑色の抵抗が戻した部品である。20Ω から合成抵抗にて 1.5Ω に変更してある。他の Unit を見るとこの抵抗は 1.6Ω だった。E6, E12, E24 系列に 1.6 は無い。特注部品だと思われる。1.5Ω でも仕様実現できるはず。1.6Ω にした理由はModel 524B の回路 (リンク先は Model 524B の日記)を比例的に小電流化したしたためと思われる。Model 524B は電流検出抵抗に 0.8Ω を使っている(2 個のトランジスタ並列で使用して、各列で 0.8Ω を使っている)。Unit #2 は Unit #1 で調整がしづらい問題を改善したのか半固定抵抗が縦型になっている。部品配置変更と、出力側のダイオードブリッジを大型の物に変更したようだ。Unit #3 は部品グレードが高めだ。Reference 電圧源用途と思われるツエナーダイオードが金属缶封止、温度変化を気にしてか金属版抵抗を使用、帯域制限コンデンサにスチロールコンデンサを使用、ここまでするなら注力する箇所を増やしても良いと思う。恐らく Unit #3 は Unit #1, #2 よりも先に作られた初期型だと思われる。Unit #4 は Unit #3 と大きな差は無さそうだ。Model 521C は上位仕様の Model 524B (リンク先は Model 524B の日記)とよく似た設計だった。次の日記: 基板上の部品配置
2025.10.06
コメント(2)
全4974件 (4974件中 1-50件目)
![]()
![]()