Measure the drains again with the outbox as a list (096)

Between two pure-serve nodes, 16 KiB records drain at 33,600 a second
(23,000 before), the links spending 58 us a record (76), under quinn's 60
while the receiver also stores each one. 1,013 bytes: 406,000 a second
(347,000). Saving sends one by one: 5,000 of 16 KiB in 0.91 s (84.8).

1 files changed, 30 insertions, 17 deletions

diff --git a/docs/research/096-per-delivery-cpu.md b/docs/research/096-per-delivery-cpu.md
index 3a0fecb..e038a7c 100644
--- a/docs/research/096-per-delivery-cpu.md
+++ b/docs/research/096-per-delivery-cpu.md
@@ -19,7 +19,8 @@
   - 1 KiB와 16 KiB 기록에서는 Pure가 quinn보다 25 % 적게 쓰고, 초당 30 % 넘게 더 보낸다.
   - 모든 측정에서 넘겨받은 기록은 순서대로 한 번씩, 보낸 바이트 그대로였다. 손실과 재정렬 아래에서도 그렇다.
 - 아직 모르는 것: 손실과 재정렬 아래의 효율, 병목에서의 공정성(M6).
-- 새로 찾은 문제: 보내는 앱의 outbox가 저장할 때마다 통째로 다시 쓰인다. 쌓인 보내기가 많으면 저장이 그만큼 커진다.
+- 새로 찾아 고친 문제: 보내는 앱의 outbox가 저장할 때마다 통째로 다시 쓰였다. 목록으로 옮기니 16 KiB 보내기 5천 건을
+  저장하는 데 84.8초이던 것이 0.91초가 됐다.
 - 사용 경험의 차이: 같은 Pi가 같은 CPU로 더 많은 기기의 기록을 받는다. 무엇보다 기록마다 저장됐다는 확인이 붙는다. quinn
   쪽에는 그것이 없다.
 
@@ -85,25 +86,37 @@ pure-serve 두 대를 잇고, 보내는 앱에 주문 2만 건을 쌓은 뒤 받
 - 큰 기록에서 Pure가 적게 쓰는 까닭은 확인하지 않았다. 둘 다 GSO와 GRO를 쓴다.
 
 **pure-serve 끝단 사이.** 설계의 M5 그대로다. 보내는 앱에 주문 2만 건을 쌓고, 받는 노드를 띄워 풀었다. 받는 앱이 주문마다
-이벤트를 적용하고, 묶음마다 저장한다(tmpfs). 세 라운드의 중앙값이다(16 KiB는 두 라운드다. 셋째 라운드는 앞 라운드의
-저장소가 tmpfs를 채워 멈췄다).
+이벤트를 적용하고, 묶음마다 저장한다(tmpfs). 세 라운드의 중앙값이다. outbox를 목록으로 바꾼 뒤(835c18e)에 쟀다([원시
+결과](../../research/experiments/019-idle-links/2026-09-29-drain-outbox-linux-aarch64.jsonl)).
 
-| 기록 | 초당 | 보내는 쪽(링크 스레드) | 받는 쪽(리스너 스레드) | quinn(전송만) |
+| 기록 | 초당(quinn) | 보내는 쪽(링크 스레드) | 받는 쪽(리스너 스레드) | quinn 클라이언트 + 서비스(전송만) |
 |---:|---:|---:|---:|---:|
-| 61 B | 108만 | 0.47(0.27) µs | 1.10(0.33) µs | 0.43 µs |
-| 1,013 B | 35만 | 2.71(2.22) µs | 4.16(2.18) µs | 3.93 µs |
-| 16,013 B | 2.3만 | 43.1(40.6) µs | 59.4(35.7) µs | 61.3 µs |
-
-- 받는 쪽의 나머지는 앱의 적용과 저장이다. quinn 쪽에는 없는 일이라 견주지 않는다.
-- 링크 스레드만 봐도 기록당 CPU가 전송만 쟀을 때보다 크다(1 KiB에 4.4 µs 대 2.9 µs). 다시 보내기 때문은 아니다. 1 KiB에서 풀기
-  중 다시 보낸 것은 받는 노드가 꺼져 있을 때의 몇 개뿐이었다. 받는 앱이 묶음(약 100건)을 저장할 때마다 STORED가 가고, 그때마다
-  링크가 깨어 작은 단위로 일한다. 전송만 잴 때는 받는 쪽이 넘겨받는 즉시 저장된 것으로 친다.
-- 채우는 동안 보내는 앱의 저장이 느려졌다. outbox(덜어 내지 않은 보내기)가 저장 때마다 links 값에 통째로 다시 쓰인다. 쌓인
-  양에 비례하는 저장이다. 16 KiB 2만 건이면 저장 한 번이 수백 MB에 이른다. 094의 들은 번호와 같은 모양의 문제다.
+| 61 B | 111만(643만) | 0.63(0.25) µs | 1.01(0.29) µs | 0.24 + 0.17 = 0.41 µs |
+| 1,013 B | 41만(50만) | 2.63(2.08) µs | 3.66(2.09) µs | 2.07 + 1.93 = 4.00 µs |
+| 16,013 B | 3.4만(3.3만) | 30.5(29.0) µs | 45.3(29.1) µs | 30.8 + 29.3 = 60.1 µs |
+
+- 받는 쪽의 나머지는 앱의 적용과 저장이다. quinn 쪽에는 없는 일이다. 그런데도 16 KiB에서는 Pure가 저장까지 하며 quinn보다
+  초당 더 많이 받는다.
+- 링크 스레드만 봐도 기록당 CPU가 전송만 쟀을 때보다 크다(1 KiB에 4.2 µs 대 2.9 µs). 다시 보내기 때문은 아니다. 풀기 중 다시
+  보낸 것은 받는 노드가 꺼져 있을 때의 몇 개뿐이었다. 받는 앱이 묶음을 저장할 때마다 STORED가 가고, 그때마다 링크가 깨어 작은
+  단위로 일한다. 전송만 잴 때는 받는 쪽이 넘겨받는 즉시 저장된 것으로 친다.
+- outbox를 목록으로 바꾸기 전에는 링크 스레드가 16 KiB 기록 하나에 76 µs를 썼고 초당 2.3만 건이었다
+  ([그때의 결과](../../research/experiments/019-idle-links/2026-09-29-drain-linux-aarch64.jsonl)). 보내는 앱이 덜어 낼
+  때마다 남은 outbox 전체를 다시 저장했기 때문이다.
+
+**outbox의 저장.** 채우는 동안 보내는 앱의 저장이 느렸다. outbox(덜어 내지 않은 보내기)가 저장 때마다 links 값에 통째로 다시
+쓰였다. 094의 들은 번호와 같은 모양의 문제다. 들은 번호처럼 런타임 목록 "0sent"로 옮겼다(835c18e). 저장은 바뀐 것(새 보내기,
+덜어 낸 것)만 로그에 쓴다. 목록에 이진 바이트 칸을 더했다.
+
+| 보내기를 하나씩 저장 | 전 | 후 |
+|---|---:|---:|
+| 16 KiB 5천 건 | 84.8초, 저장소 400 MB | 0.91초, 144 MB |
+| 61 B 2만 건 | 8.4초 | 2.9초 |
 
 ## 판정
 
-- **1 KiB와 16 KiB: 통과.** 전송이 기록 하나에 쓰는 CPU가 quinn보다 25 % 적다. 초당 보내는 수는 30 % 넘게 많다.
+- **1 KiB와 16 KiB: 통과.** 전송이 기록 하나에 쓰는 CPU가 quinn보다 25 % 적다. 초당 보내는 수는 30 % 넘게 많다. 끝단
+  사이에서도 16 KiB는 받는 쪽이 저장까지 하며 quinn만큼 받는다.
 - **61 B: 가드레일 선 위.** quinn의 1.06–1.12배다. 남은 차이는 패킷마다 싣는 스트림 이름과 RECORDS 머리다. 이것을 줄이면
   넘는다. 연결 없는 모델에서는 패킷마다 자기가 누구의 어느 스트림인지 말해야 하므로, 이름 대신 짧은 이름표를 쓰는 방법을 따로
   설계해야 한다.
@@ -112,8 +125,8 @@ pure-serve 두 대를 잇고, 보내는 앱에 주문 2만 건을 쌓은 뒤 받
 
 ## 한계와 다음
 
-- **outbox의 저장.** 보내는 앱의 outbox가 저장 때마다 통째로 쓰인다. 들은 번호처럼 목록으로 바꿔, 저장이 바뀐 것만 로그에
-  쓰게 한다. 목록에는 이진 바이트 칸이 먼저 필요하다(지금은 텍스트 칸이 UTF-8만 받는다). 다음 일이다.
+- **덜어 내기의 훑기.** outbox는 보낸 순서라 여러 출력의 보내기가 섞인다. 한 출력의 받는 쪽이 오래 멀면, 다른 출력을
+  덜어 낼 때마다 앞의 보내기를 훑고 지나간다. 출력이 하나면 문제없다.
 - **하나씩 넣으며 보내기.** 기록을 하나씩 넣는 스레드와 링크 스레드가 잠금을 다퉈, 기록당 1.5 µs가 든다. pure-serve는 저장
   한 번의 보내기를 묶어 넣으므로 덜하다. 묶어 넣는 API를 둔다.
 - **조각의 크기.** 큰 기록은 1000 B 조각으로 나뉜다. 가장 긴 이름에도 맞게 잡은 값이라 패킷마다 100 B 남짓이 빈다. 조각의