diff --git a/doc/etcp_multipath_plan.txt b/doc/etcp_multipath_plan.txt index 67eab97c..bf4fc425 100644 --- a/doc/etcp_multipath_plan.txt +++ b/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--<1..3>.log/.csv, +/tmp/etcp-recovery-stages-buffered-two-<1..5>.log, /tmp/etcp-recovery-stages-asan-.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 последней альтернативы diff --git a/doc/tasks.md b/doc/tasks.md index bf06bec0..be8d3ef0 100644 --- a/doc/tasks.md +++ b/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.