Record recovery stage checks and repeated stalled-path cycles

doc/etcp_multipath_plan.txt

@@ -3,6 +3,54 @@ ETCP: независимая обратная связь каналов и до
 
 Статус
 
+24.10.2026: проверки отказов разделены на RTO, готовность повтора и доставку.
+В этом этапе менялись только тесты/диагностика, логика ETCP сохранена.
+TX учитывается после принятия send транспортом, а не при подготовке пакета.
+Возврат логического DATA в send_q фиксирует окончание ожидания RTO; отдельно
+измеряются опоздание обработки RTO, ожидание готового повтора и доставка сверх
+заданной задержки канала. Проверки этих этапов:20мс,100мс и100мс соответственно.
+Транзит измеряется при первом приёме DATA, если номер/путь совпадают с последней
+принятой отправкой; старую копию не приписываем времени новой попытки.
+RTO_count в логе — число возвратов логического DATA по RTO, не все снятия физических попыток.
+Для быстрых профилей общий предел остаётся100мс. Если сумма RTO отказавших путей
+превышает100мс, общий предел — эта сумма плюс100мс. Бюджет даётся на один обход
+отказавших путей; дополнительные круги не увеличивают разрешённую задержку.
+Максимальный RTO пути наблюдается независимо от измеряемых gap/latency.
+
+Остальные8 профилей отказов проходят. Two-stuck нестабилен: в обычном прогоне
+сообщение322 ждало738.317мс при пределе459.332мс. Разблокировавший фрагмент324
+прошёл пути1->2->1->2->0 (5 принятых попыток); первая отправка произошла всего
+через41мкс после постановки сообщения. Это дополнительный обход двух путей без
+прогресса, а не обязательное ожидание единственного RTO или очередь источника.
+Контроль с занятостью рабочего пути0 ровно1мс воспроизводит ту же цепочку:
+736.623мс latency,534.548мс gap. При выборе2->1 рабочий путь initialized=UP=1,
+окно свободно (1026/9514 байт), pacing_blocked=1. Повтор немедленно уходит в1,
+после его RTO — снова в2, хотя0 уже готов. Готовый повтор ждёт максимум1.109мс,
+обработка RTO опаздывает максимум1.951мс; лишнее время создают повторные RTO.
+
+Отрицательный контроль отдельно задерживает готовый повтор на200мс: проверка
+ready_wait падает независимо от разрешённого бюджета RTO. Самые медленные
+сообщения логируются с номерами сообщения/фрагмента, временем постановки,
+первой отправки и доставки, числом попыток и историей путей (по2 бита, последние16).
+Решения между отказавшими путями буферизуются и печатаются после замера;
+переполнение буфера — ошибка теста. Обычные повторы two-stuck также могут пройти
+с latency около376мс; единичный PASS не закрывает обнаруженный лишний круг.
+Slow-drop/two-stuck/load-drop проходят ASAN/UBSan с detect_leaks=1 без ошибок/утечек.
+Полный check.sh:184/184, proxy9/9, burst1/1, load8/8 PASS,134217728 проверенных байт,
+161с; /tmp/etcp-recovery-stages-full-check.log. Долгая multipath-матрица в check.sh не входит.
+
+До дальнейшего изменения транспорта требуется отдельный разбор исключения
+путей без DATA-прогресса из обычного выбора, ограниченных проб и возврата после
+подтверждённого прогресса. Физический UP не следует подменять DATA-готовностью;
+нужно проверить поздние ACK, отсутствие исправных путей и reset/close.
+Ранних копий до RTO в плане нет. Дуплекс в этом этапе не менялся.
+Логи: /tmp/etcp-recovery-stages-final-<profile>-<1..3>.log/.csv,
+/tmp/etcp-recovery-stages-buffered-two-<1..5>.log, /tmp/etcp-recovery-stages-asan-<profile>.log.
+Контроли: /tmp/etcp-recovery-stages-negative-final.log,
+/tmp/etcp-recovery-stages-busy-control.log; исходники контролей — /tmp/etcp-recovery-*-control.c/.mk.
+
+Предыдущий этап — ожидание альтернативы после RTO:
+
 24.10.2026: уточнено и реализовано правило ретрансмита. При наличии другого
 initialized+UP канала повтор ждёт его cwnd/pacing, даже если прежний уже готов.
 Без таких альтернатив разрешён прежний канал; DOWN последней альтернативы

doc/tasks.md

@@ -5,6 +5,20 @@
 ## Текущие задачи
 
 [ ] **ETCP: полезная утилизация нескольких каналов и доставка при зависании части линков** — общая задача открыта.
+    24.10.2026: тесты отдельно проверяют обработку RTO (опоздание<=20мс), ожидание готового повтора (<=100мс)
+    и доставку сверх заданной задержки канала (<=100мс). TX учитывается после принятия send.
+    Быстрые профили сохраняют общий предел100мс; длинные учитывают по одному RTO отказавших путей плюс100мс.
+    Остальные8 профилей PASS; two-stuck нестабилен: обычный прогон дал738.317мс при пределе459.332мс,
+    история фрагмента324 —1->2->1->2->0. Готовый повтор не застревает: лишнее ожидание создаёт ещё один круг RTO.
+    Контроль с занятостью рабочего пути всего1мс воспроизводит736.623мс latency и534.548мс паузы;
+    точный лог показывает свободное окно рабочего пути и ожидание pacer при выборе2->1.
+    Контроль задержки уже готового повтора на200мс проваливает новую проверку очереди, а не маскируется бюджетом RTO.
+    Slow-drop/two-stuck/load-drop проходят ASAN/UBSan с detect_leaks=1 без ошибок/утечек.
+    Полный check.sh184/184, proxy9/9, burst1/1, load8/8 PASS,134217728 байт,161с; multipath запускается отдельно.
+    Перед изменением транспорта отдельно проработать выбор путей без DATA-прогресса, ограниченные пробы
+    и восстановление, сохраняя физический UP и защиту от поздних ACK. Ранние копии исключены; дуплекс не менялся.
+    Логи: /tmp/etcp-recovery-stages-*.log/.csv; подробности — doc/etcp_multipath_plan.txt.
+    Предыдущий этап:
     24.10.2026: повтор ждёт другого initialized+UP канала, даже когда прежний уже готов.
     При отсутствии таких альтернатив разрешён прежний; DOWN последней альтернативы будит sender.
     Новых состояний/ресурсов/таймеров нет. ACK/control и burst-FILLER не блокируются ожиданием DATA.