<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pure/research/experiments/019-idle-links/2026-09-29-epochs-bisect-linux-aarch64.jsonl, branch master</title>
<subtitle>Verified execution runtime unifying state, persistence, and replication.
</subtitle>
<id>http://git.yeowoo.org/pure/atom?h=master</id>
<link rel='self' href='http://git.yeowoo.org/pure/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/'/>
<updated>2026-09-29T12:58:44Z</updated>
<entry>
<title>Say what epochs cost a link, and what the search for it found (099)</title>
<updated>2026-09-29T12:58:44Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-29T12:58:30Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=0bbc12658c63f5f5fce2683798d4ac08b1e26e08'/>
<id>urn:sha1:0bbc12658c63f5f5fce2683798d4ac08b1e26e08</id>
<content type='text'>
Forward secrecy, 098's first task left: keys that leak later open only
epoch 0. M2 after the epoch began and after a restart is as before it
(p50 0.4 ms, p99 0.8 ms, the same CPU, no X25519 on restart). It costs a
p50 of 0.7-1.0 ms more while ten thousand devices first meet and for
about 40 s of accepts after, and a receiver that lost its memo now
stalls 0.8 s and catches up in 7.7 s, not 0.2-0.7: it lost the epochs,
and each sender opens one again. The search also found a packet more a
device from each of M6's path probe and the security checks' challenge,
and a load generator whose own pass over its devices was the floor of
the latency it measured. 098's note that epochs narrow KCI to the first
epoch was wrong; corrected.
</content>
</entry>
</feed>
