Record the bound of taking tail growth and compaction off commits (081)

Measured with a build that grows its tail by 64 MiB once and never
compacts: durable posts +5-8% (64 connections), p99 about halved; the
slow syncs that remain come from the device.

1 files changed, 5 insertions, 3 deletions

diff --git a/docs/research/081-tail-records.md b/docs/research/081-tail-records.md
index fdb6833..57264ce 100644
--- a/docs/research/081-tail-records.md
+++ b/docs/research/081-tail-records.md
@@ -97,8 +97,10 @@
 
 ## 다음 결정
 
-- **꼬리 늘리기와 압축을 커밋 밖으로.** 동기화 시간의 3분의 1이 드문 느린 동기화다. 0을 써 넣는 일과 압축을 저장이
-  없는 틈이나 다른 스레드에서 하면 그만큼 줄 것이다. 다만 0을 새로 쓴 쪽이 아직 내구성이 없는데 커밋이 그 위에 쓰면 안
-  되므로, 늘린 꼬리를 먼저 동기화하는 순서가 필요하다.
+- **꼬리 늘리기와 압축을 커밋 밖으로.** 동기화 시간의 3분의 1이 드문 느린 동기화다. 상한을 재 봤다. 시작할 때 꼬리를
+  64 MiB 늘려 두고 압축을 끈 빌드는 5초 동안 꼬리를 늘리지도 압축하지도 않는다. POST 64연결이 23.1–23.8k에서
+  24.3–25.8k/s(+5–8%), p99가 10–14 ms에서 5.4–6.4 ms가 됐다. 4 ms를 넘는 동기화는 그래도 81–129번 남는다(장치의 잡음).
+  처리량보다 꼬리 지연의 몫이다. 0을 써 넣는 일과 압축을 저장이 없는 틈이나 다른 스레드에서 하려면, 0을 새로 쓴 쪽이
+  아직 내구성이 없는데 커밋이 그 위에 쓰지 않도록 늘린 꼬리를 먼저 동기화하는 순서가 필요하다.
 - **저장과 적용의 겹치기**는 열린 부하(답을 기다리지 않고 요청이 오는 경우)에서 다시 잰다. 닫힌 루프에서는 위의 까닭으로
   얻을 것이 없다.