コグノスケ

ナトリウムイオン電池

目次: 電池

エレコムからナトリウムイオン電池を使用したモバイルバッテリーが発売されていたので予約しました。

産出国が数か国のリチウムに対し、ナトリウムは海にいくらでもあって資源の供給不安はないことが利点です。一方でナトリウムはリチウムよりイオン半径がでかく、重いためエネルギー密度でリチウムイオン＞ナトリウムイオンになることが欠点です。

エレコムではリチウムイオン電池（Li-ion）、リン酸鉄系のリチウムイオン電池（FePO4）、ナトリウムイオン電池（Na-ion）のモバイルバッテリーを販売していました。その中で電流容量が近そうなバッテリー3つを抜粋してみました。

• Li-ion: DE-C69L-10000BK
• FePO4 : DE-C39-12000BK
• Na-ion: DE-C55L-9000BK

各バッテリーの仕様はこんな感じです。

いずれも10,000mAh前後の製品ですが、電力量が低く、エネルギー密度でもリチウムイオン電池とナトリウムイオン電池では大きな差がついています。ナトリウムイオン電池のモバイルバッテリーは電池電圧が低く、重量がかさむためです。製品重量からエネルギー密度を計算したので、電池の純粋なエネルギー密度ではありませんが、ナトリウムイオン電池の悩ましい点が良くわかると思います。

ナトリウムイオン電池はリチウムイオン電池とエネルギー密度勝負をしても勝てないです。それよりも温度耐性や充電サイクル数でリチウムイオン電池を上回る（らしい）点を活かして、設置場所を広くとれる設備（太陽光発電の蓄電池、電力網のバックアップなど）に役立つ未来はありだと思います。

首都高バトルSteam版、大体クリア

目次: ゲーム

やっと首都高バトル（Steam版）のWondererを全員倒し、ミスターパーフェクト（たぶん70連勝くらいするともらえる）も取りました。まだアーリーアクセス版ですから今後のシナリオ追加などはあるでしょう、けど、現状の明確な目標はもうないのでクリアと言っても過言ではないでしょう。

Wondererを全員倒した

一番手ごわかったのは辻斬りギャンブラーでした。直線が馬鹿みたいに速く、いかなるチューンドカー、ユウウツな天使のカスタムカーですら追いつけないです。493PSのbBってなんなの怖ぁ……。

このゲームは難易度設定が変で、相手がミスってクラッシュするのを待つしか勝つ方法がないやつが何人かいます。全く面白くないので二度と戦いません。ちなみにスクリーンショットでの表示は4敗ですが、レース途中でゲームを強制的に終了させて負け回数にカウントしていないものを含めると10敗以上です。強制終了すると無効試合になるのは首都高バトルの仕様なのかバグなのかわかりませんが、今のところ修正される様子はないです。

辻斬りギャンブラーの車

アドバイスするほど上手ではありませんが、私のやり方は相手のミス＆クラッシュ待ちが基本戦略です。急カーブの手前から勝負を開始して急カーブでCPUが全速力に達するように仕向けて、急カーブ＋急減速＋オーバーテイクを重ねてあげると何回かに1回はアザーカーに突っ込んで勝手に自爆します。相手がモタモタしている間に抜き去ると良いです。私は浜離宮のS字や銀座辺りの急カーブを使っていました。西側のトンネルでも良いかもしれません。

誕生日

42歳になりました。昨年の日記（2024年3月10日の日記参照）を見ると、リモートワークの話をしていました。

最近はリモートワークをやめて出社に回帰する企業も増えました。デンソーのときはリモート:出社=7:3〜5:5くらい、チューリングに転職してからは毎日出社しています。基本的に電車通勤していますが、今いる拠点は車で行ってもOKでありがたいです（特に雨の日は）。

東京に住んでいると全く車を使わないので、バッテリー上がりを頻繁に起こしていましたが、たまに通勤に使えるとあらば以前ほどバッテリーが死にまくることもなくなるでしょう。たぶん……。

wchanとptrace_may_access()

目次: Linux

以前、LinuxのI/O統計情報が読めないプロセス（systemd --user）がある話をしました。/proc/[pid]/ioファイルのreadアクセス権があっても、ptrace_may_access()の判定で拒否されるためにread()時にEPERMエラーになります。読めるかどうかの判別がopen()時にできず、試し読みでread()するしかない面倒な作りです。

今回はさらに判別が面倒な例/proc/[pid]/wchanについてのメモです。wchanはCONFIG_KALLSYMS=yになっていれば機能するはずです。

wchanの挙動

I/O統計情報と同様にwchanも特権の有無で挙動が変わります。動作例を見た方が早いでしょう。

$ LANG=C ps aux | grep 'systemd --user$'
katsuhi+    1535  0.0  0.0  22004 12048 ?        Ss   Mar08   0:00 /usr/lib/systemd/systemd --user

$ cat /proc/1535/wchan ; echo
0

$ sudo cat /proc/1535/wchan ; echo
do_epoll_wait

特権があればdo_epoll_waitが読めますが、特権がないと0が読めます。不思議な動きですね。

コードを確かめる

なぜこんなことが起きるのか？Linuxカーネルのコードも見ておきます。

// fs/proc/base.c

#ifdef CONFIG_KALLSYMS
/*
 * Provides a wchan file via kallsyms in a proper one-value-per-file format.
 * Returns the resolved symbol.  If that fails, simply return the address.
 */
static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
			  struct pid *pid, struct task_struct *task)
{
	unsigned long wchan;
	char symname[KSYM_NAME_LEN];

	if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))    //★★これ★★
		goto print0;

	wchan = get_wchan(task);
	if (wchan && !lookup_symbol_name(wchan, symname)) {
		seq_puts(m, symname);
		return 0;
	}

print0:
	seq_putc(m, '0');
	return 0;
}
#endif /* CONFIG_KALLSYMS */

以前見た/proc/[pid]/ioと同様で、先頭にptrace_may_access()のチェックが存在していて、チェックに引っかかると常に'0'を返す実装になっています。読めるかどうかの判別がopen()でもread()でもできない、内容で判断するしかない新手のパターンです。

何かの事情でwchanを読めるかどうかチェックするとしたら、試しにread()して内容が'0'かどうかを見るwchan専用の処理を書くしかないですね。なかなか面倒な存在です……。