ノード番号を2バイトに広げてみた(壊した版がCIでだけ緑)

今週のメモ。前回の64台の続きっぽい話。

■番号が1バイトだった
p-kernel の端末(ノード)は、お互いを番号で呼んでいる。この番号が電文の中で1バイトしかなくて、数えられるのは255台まで。1台でも残れば死なない、を言うなら台数は多いほうがいいので、広げないといけない。

面倒なのは古い版が混ざること。端末は参加する人が持ち寄るものなので、全員を一斉に入れ替えることはできない。古い版は2バイトの番号を読めない。

夜間開発(夜に自動で動く Claude)と決めた形は、番号が小さい相手どうしは今までの電文のまま、255を超える番号が絡むときだけ電文の後ろに2バイトの「尾」を付ける、というもの。尾が読めるかどうかは、仲間の生き死にを確かめるやりとりの中の1ビットで知らせる。古い版は尾を知らないので、読まずに切り捨てる。

今週、255番を超える「広いノード」が起動して群れに入れるようになった。

■混ぜて試す
確かめる試験は X3。古い版のバイナリ、新しい版で番号が小さいノード、260番と300番の広いノードを1つの群れにする。そこに snow と fire という知識を教えて、全員に届くかを見る。

最後まで残った欠けは fire@260 と fire@300。広いノードが「それ知りたい」と聞いても、聞いた人の番号が1バイトに入らないので答えが返ってこなかった。「知りたい」の電文にも尾を付けたら、11-07 に X3 が初めて全部 PASS。

■壊した版が CI でだけ緑
そのあと GitHub の CI が赤になって、GitHub 側へ進める処理(promote)が止まった。

赤くなったのは、尾をわざと外した版(陰性)の所。fire が届かずに赤になるはずの版が、CI でだけ2回続けて fire を届けて緑になった。手元で同じ形を4回走らせると、4回とも狙いどおり赤。

夜間開発の読み(まだ確かめきれていない)だと、番号が小さい新しいノードが答えを群れ全体に流していて、尾が無くても別の道で 260 と 300 に届くことがあるらしい。試験が見ている道は1本じゃなかった。

陰性の判定は、毎回同じ結果になる自己試験に替えた。生きた群れの試験は判定せずに走らせて、どの道で届いたかを印字するだけ。※合格のほうの fire も「尾が効いた証拠」としては弱い、とメモに残してある。

■返事が無かったので進んだ件
夜間開発の決まりで、技術的な分かれ道は AI が自分で決める。自分に聞くものは期限を付けて聞いて、返事が無ければおすすめで進む。

今週はこれが1件動いた。方舟(人の記録を残しておく場所)のログには、詰め直すと消えるブロックがある不具合があって、それを直すとベアメタル版のカーネルの機械語が変わる。機械語が変わるときは「わざと変えた」と記録して自分に聞くことにしているんだけど、期限の24時間を自分が見ないまま過ぎた。夜間開発は試験を取り直してから入れていた。

方舟はほかにも、64セクタに10件書いたら満杯で書けなくなっていたのを、満杯の手前で自動で詰め直すようにした。

■使いすぎ
先週は週の使用量の枠が93%で終わった。上限は90%にしてある。11-07 の21時過ぎからは門が起動を止めていた。10分ごとの見張りが「タイマーが動いたのに記録が無い」と騒いだけど、止めていたのは門なので誤警報。

■脳はちょっと後退
群れで脳を育てる実験(B5)で、先週まで「1台で育てるより良い」と言っていた分の大半は、比べる相手の1台が覚えすぎて成績を落としていたせいだった。どれも一番良かった所で止めて比べ直すと、差はかなり小さくなる。FLTrust 型の合体(自分の更新を基準に、仲間をどれだけ信用するか決める)は判定 FAIL。まだ数KBの文の上の話。

■次
11/30 に出すデモが 11-02 から止まってる。残り3週間。
CI の1ジョブが107分で、枠の120分に近い。陰性を別ジョブに分けて、93分くらいになる見込み。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI(Claude)と一緒に書いています。

コメントを書く