Record bandwidth-only correction validation and remaining speed limits

doc/etcp_multipath_plan.txt

@@ -115,7 +115,40 @@ BGP route exchange: 100/100 PASS (A<B:48, A>B:52; последние пять с
 Все замеры: /tmp/etcp-multilink-quality-20261023.csv/.txt.
 Логи повторов: /tmp/etcp-quality-r{2,3}-{profile}.log/.csv; первый — /tmp/etcp-rto-margin-matrix.log/.csv.
 
-Проверка плана исправления дуплекса, 23.10.2026
+Коррекция BW в рабочей реализации, 23.10.2026
+
+По выбору пользователя перенесена только граница BW по приёмной точке пути.
+Пара rx_data_bytes/rx_data_time_us добавляется после entries лишь при count>0:
+ACK имеет размер8+16*count+(count>0?16:0), пустой ACK остаётся8-байтовым.
+Снимок точки хранится в физической попытке, новые очереди/таймеры не нужны.
+После пустого flight база начинается заново. Перестановка ACK не откатывает
+точку, неизвестный/повторный ID её не меняет; переполнения проверяются.
+Формула, единицы и формат: doc/etcp_protocol.txt, etcp_tx.h, etcp_connections.h.
+min_rtt/RTT, политика окна, RTO и дедлайн/пакетирование ACK не менялись;
+busy-флаг и дуплексный коэффициент не добавлены. Обе стороны используют новый формат ACK.
+
+Windows35 сценариев, session, transport, init_liveness и BBR PASS;
+те же пять тестов ASAN/UBSan с detect_leaks=1 PASS, без ошибок и утечек.
+Проверены сжатие ACK (170502/186359 вместо170502/150732), перестановка/дубли,
+недостоверные точки, простой/reset, независимые часы, округление/переполнение,
+границы MTU, усечённые ACK и ограниченный диагностический буфер.
+Полный check.sh:184/184 PASS, proxy9/9, burst1/1 и load8/8 PASS;
+load проверил134217728 байт. Лог: /tmp/etcp-bw-correction-full-check.log.
+Логи sanitizer: /tmp/etcp-bw-asan-{windows,session,bbr,transport,init_liveness}.log.
+
+Отдельный последовательный bidirectional: агрегат2+8Mbit/s RTT20/80мс,
+goodput8.223/8.182Mbit/s, очереди путей A->B22.8/22.7мс, B->A19.9/21.9мс,
+DATA retries=0 в измеряемом интервале. Профиль FAIL:5 прежних порогов скорости,
+включая solo; агрегат не достиг8.5Mbit/s на направление. Пороги не ослаблены.
+bandwidth2+8Mbit/s RTT20/20мс:8.844Mbit/s, очереди24.2/20.7мс, retries=0,
+профиль PASS. Это единичные контрольные прогоны, не гарантия максимальной утилизации.
+RTT20/200мс,8+8Mbit/s:13.453Mbit/s, очереди19.8/24.0мс, retries=0;
+профиль FAIL по3 прежним порогам скорости. Недобор разных RTT остаётся открытым.
+Логи/CSV: /tmp/etcp-bw-duplex-final.log/.csv, /tmp/etcp-bw-bandwidth.log/.csv, /tmp/etcp-bw-rtt.log/.csv.
+Первый диагностический дуплексный прогон совпал со сборкой/другими проверками
+(/tmp/etcp-bw-duplex.log/.csv); для оценки качества используется отдельный повтор выше.
+
+Проверка плана исправления дуплекса до внедрения BW, 23.10.2026
 
 Пакетный трейс нашёл ACK compression при осушении обратной очереди: для DATA
 seq257..413 принято 170502 байта за186359мкс, а max(send_elapsed,ack_elapsed)
@@ -126,8 +159,8 @@ RTT приходит в BBR на каждом ACK (около124мс), прич
 Полный трейс500мс: /tmp/etcp-duplex-packets.log/.csv; история разгона:
 /tmp/etcp-duplex-overload-start-v2.log, /tmp/etcp-duplex-overload-history-v2.csv.
 
-Прототипы остаются только в /tmp/etcp-duplex-native/. Исходники проекта
-не менялись. Реальный wire ACK расширен с8 до24 байт парой rx_bytes:u64
+Прототипы этих опытов находятся в /tmp/etcp-duplex-native/. На момент опытов исходники проекта
+не менялись. В прототипе wire ACK расширен с8 до24 байт парой rx_bytes:u64
 и rx_time_us:u64; это одна согласованная точка физического приёма DATA пути.
 Счётчик включает допустимые физические копии DATA; это не логический till.
 Попытка хранит последнюю известную точку при отправке. Дополнительная граница
@@ -173,12 +206,12 @@ ACK учтены по принятым пакетам: ACK-only — вся UDP-
 При безусловном добавлении16 байт телеметрии ACK расходует0.707..0.743Mbit/s;
 с новой границей BW —0.745..0.763Mbit/s. Накладные расходы реальны и учтены.
 
-План требует уточнения до переноса в основную реализацию:
-1. Сохранить измеренный min_rtt и отдельные send/ACK/receiver интервалы.
+Итоговый план после выбора только BW пользователем:
+1. Выполнено: сохранить измеренный min_rtt и отдельные send/ACK/receiver интервалы.
    Точку счётчик/время передавать только с положительными ACK, которые её
    используют; не раздувать каждый DATA с пустой ACK-секцией. Изменение
    формата выполнить целиком для TX/RX/dump/MTU и тестов.
-2. Испытать объединение ACK: piggyback на готовом DATA — сразу; ACK-only
+2. Отложено, в текущий фикс не входит: испытать объединение ACK. Piggyback на готовом DATA — сразу; ACK-only
    по существующему дедлайну2мс. Запрос границы окна/срочный ответ не задерживать.
    Один таймер должен обслуживать ближайший deadline очередей путей, включая
    повторное планирование после частичного piggyback/раннего пробуждения.
@@ -186,11 +219,11 @@ ACK учтены по принятым пакетам: ACK-only — вся UDP-
 3. Сначала повторить скорости/очереди с корректной оценкой BW и экономной
    упаковкой ACK. Дуплексный коэффициент не вводить как обязательную часть
    фикса без устойчивого выигрыша в дополнительных RTT/BW/асимметричных профилях.
-4. До внедрения проверить reordering/loss/duplicate ACK, поздние попытки,
+4. Выполнено для BW: проверить reordering/loss/duplicate ACK, поздние попытки,
    reset/recreate пути и простой; валидировать пару counter/time. Если новая
    граница не представима в uint32 interval, пропустить оценку BW, а не
-   насыщать интервал с нарушением верхней границы скорости. TTL флага
-   определить для редких DATA/jitter/standby и проверить молчание без ACK.
+   насыщать интервал с нарушением верхней границы скорости. TTL флага не относится
+   к текущей реализации: флаг не добавлялся.
 
 Результаты всех18 запусков: /tmp/etcp-duplex-native/results.json,
 /tmp/etcp-duplex-native/summary.csv, /tmp/etcp-duplex-native/ack_bandwidth.csv.

doc/tasks.md

@@ -34,11 +34,19 @@
     Нативный прототип counter/time в ACK сокращает пики очереди до23.1мс вместо52.9мс, но все скоростные пороги не проходит.
     Коэффициент282/256+3мс и запас10мс при busy-флаге не дали устойчивого выигрыша, пики очереди выросли до35.5/33.7мс.
     В штатном агрегате ACK занимает0.515..0.559Мбит/с на направление (5.15..5.59% полосы), большая часть — ACK-only.
-    Безусловные16 байт новой телеметрии увеличивают расход; нужен опыт с передачей точки только при положительном ACK
-    и объединением ACK в пределах прежнего дедлайна2мс. Дуплексный запас пока не считать подтверждённым исправлением.
+    Реализована только коррекция BW по точке приёма:16 байт добавляются при count>0, пустой ACK остаётся8-байтовым.
+    Перестановка/дубли ACK, независимые часы, простой/reset, переполнения и границы MTU/формата проверены.
+    Windows35 сценариев и ещё4 профильных теста PASS, те же5 тестов ASAN/UBSan без ошибок/утечек;
+    check.sh184/184, proxy9/9, burst1/1, load8/8 PASS (/tmp/etcp-bw-correction-full-check.log).
+    Отдельный дуплекс2+8 RTT20/80:8.223/8.182Мбит/с, пики очереди агрегата22.8мс, retries=0;
+    профиль остаётся FAIL по5 прежним порогам скорости. bandwidth2+8 RTT20/20:8.844Мбит/с, PASS.
+    RTT20/200,8+8:13.453Мбит/с, очередь<=24мс, retries=0, FAIL по3 прежним порогам скорости.
+    Логи: /tmp/etcp-bw-duplex-final.log/.csv, /tmp/etcp-bw-{bandwidth,rtt}.log/.csv, /tmp/etcp-bw-asan-*.log.
+    Объединение ACK в пределах прежнего дедлайна2мс отложено; окно/RTT/RTO и политика ACK не менялись.
+    Дуплексный запас и busy-флаг не добавлялись и не считаются подтверждённым исправлением.
     One-way->duplex->one-way:3/3 PASS; ASAN/UBSan не нашли ошибок/утечек, скоростной профиль остаётся FAIL.
     Подробности/уточнённый план: doc/etcp_multipath_plan.txt; результаты: /tmp/etcp-duplex-native/results.json,
-    /tmp/etcp-duplex-native/summary.csv и ack_bandwidth.csv. Код прототипов в репозиторий не переносился.
+    /tmp/etcp-duplex-native/summary.csv и ack_bandwidth.csv. Политика окна прототипов в репозиторий не переносилась.
     Ранние копии до RTO, здоровье/пробы каналов и STCP backpressure пока не реализованы; пороги тестов сохранены.
     OOM после принятия данных исправлен аварийной сменой эпохи с сохранением физических линков.
     Старый поток отбрасывается без воспроизведения; после согласования владельцы получают REINIT.