From d0f122f4d85c6dd6970b2b371da76c964f2ce826 Mon Sep 17 00:00:00 2001 From: evgeny Date: Fri, 23 Oct 2026 00:49:02 +0200 Subject: [PATCH] Record verified RTT probe fixes and remaining multipath failures --- doc/tasks.md | 27 +++++++++++++++++++-------- src/transport_layer/etcp_bbr.h | 4 ++-- 2 files changed, 21 insertions(+), 10 deletions(-) diff --git a/doc/tasks.md b/doc/tasks.md index 8f43669e..61289b04 100644 --- a/doc/tasks.md +++ b/doc/tasks.md @@ -30,18 +30,29 @@ /tmp/etcp-channels-asan-final-results.log, /tmp/test_*-asan-final.log. После исправлений добавить смену профилей на ходу, повторяющиеся отказы и смешанный UDP/STCP со stalled TCP write. Полная матрица дольше 90s общего runner и запускается отдельной целью; нарушения завершают её с ошибкой. - Текущая диагностика: /tmp/etcp-recovery-rtt-diagnostic.log/.csv. RTT 20/200мс даёт около 10.1–10.5 из 16 Мбит/с. - В одиночном длинном канале PROBE_RTT снижает cwnd до 4*MTU=5120 вместо max(4*MSS, 0.5*BDP) из BBRv3; - транспорт повышает его обратно до 8192. При inflight=6582 модель всё ещё ждёт осушения ниже 5120. - Перед дальнейшим исправлением согласовать минимальное эффективное окно BBR/транспорта и единицу MSS: - сейчас BBR получает link->mtu (для STCP 65535), хотя DATA-фрагменты normalizer существенно меньше. - Затем согласовать обратную связь: ACK выбирает путь по inflight/RR, скорость оценивается по фактическому времени + Окно PROBE_RTT и DATA MSS согласованы 23.10.2026 (см. завершённую подзадачу ниже). + Одиночный канал RTT=200мс/BWlim=8Мбит/с теперь проходит: полезная скорость 6.99Мбит/с, очередь <=133.1мс. + Далее согласовать обратную связь: ACK выбирает путь по inflight/RR, скорость оценивается по фактическому времени возврата ACK, а RTT модели берётся из отдельного timestamp-обмена исходного линка. Это разные интервалы. При повторах ACK не идентифицирует попытку: запись хранит только last_link, старый ACK может быть приписан новому пути. Нужен явный контракт учёта попыток до изменения выбора пути/повторов; простой запрет прошлого линка его не заменяет. После этого исправлять здоровье линка, независимые сроки повторов и доставку при DROP/HOLD по существующим тестам. - Финальные профили: equal PASS (14.37 из 16 Мбит/с), bandwidth по скорости PASS (9.34 из 10), но очередь 47.7мс >40мс; - rtt FAIL. Пороги очереди и утилизации не ослаблены. Логи: /tmp/etcp-recovery-{equal,bandwidth,rtt}-final.log. + Профили после исправления окна: equal PASS (14.75 из 16 Мбит/с), bandwidth по скорости PASS (9.11 из 10), + но очередь 47.9мс >40мс. RTT 20/200мс: 10.08 из 16 Мбит/с, быстрый путь недогружен; rtt FAIL. + Пороги очереди и утилизации не ослаблены. Логи: /tmp/etcp-probe-{equal,bandwidth,rtt}.log/.csv. + Диагностика bandwidth с состояниями модели: /tmp/etcp-probe-bandwidth-diagnostic.log. + +[+] **ETCP/BBR: единое окно DATA и корректное осушение PROBE_RTT** — исправлено 23.10.2026: + BBR использует MSS=normalizer->frag_size, а не wire-MTU/размер STCP-кадра. Начальное окно UDP/STCP равно 4*MSS; + MTU пересчитывается после включения нового линка в список. init_cwnd инициализируется четырьмя фрагментами. + Транспорт применяет положительное окно с верхним ограничением bbr_max_cwnd, не поднимая его до 8192. + INFLIGHT_LIM_MIN=8192 остаётся нижней допустимой границей настройки максимального окна; нулевое окно отклоняется с логом. + PROBE_RTT осушает до max(4*MSS, 0.5*BDP), ждёт >=200мс и раунд ACK, затем восстанавливает предыдущее окно. + Отправленные при осушении DATA помечаются app_limited. Ограничения после потерь больше не уменьшают окно ниже 4*MSS. + BBR 15/15, отправитель 16 сценариев; ETCP session/transport, STCP traffic и NCD PASS. + Те же шесть тестов ASAN/UBSan с detect_leaks=1: 6/6 PASS, ошибок и утечек не обнаружено. + Логи: /tmp/etcp-probe-test_*.log, /tmp/etcp-probe-asan-results.log, /tmp/etcp-probe-asan-test_*.log; + исходные нарушения: /tmp/etcp-probe-contract-{bbr,windows}-before.log, /tmp/etcp-probe-lossfloor-before.log. [+] **ETCP/BBR: байтовые единицы, delivery clock и независимость ACK от локального DATA-pacer** — исправлено 23.10.2026: Устранено повторное умножение на MSS при расчёте pacing/BDP: доставка 1MB/s давала 570240000B/s при MSS=576, diff --git a/src/transport_layer/etcp_bbr.h b/src/transport_layer/etcp_bbr.h index 2118fdbc..f1dca0a7 100644 --- a/src/transport_layer/etcp_bbr.h +++ b/src/transport_layer/etcp_bbr.h @@ -53,7 +53,7 @@ struct bbr_rate_sample { uint32_t prior_delivered; // счётчик delivered при отправке подтверждённого пакета, modulo 2^32 uint32_t tx_in_flight; // байты в пути при отправке int lost; // потерянные байты с предыдущего ACK - int is_app_limited; // при отправке не было ожидающих данных приложения + int is_app_limited; // при отправке не было ожидающих данных приложения либо шёл PROBE_RTT }; typedef void (*bbr_cwnd_update_fn)(void* ctx, uint32_t new_cwnd); @@ -115,7 +115,7 @@ struct bbr { void* cwnd_update_ctx; }; -// Инициализировать выделенную модель: STARTUP, начальное окно 4 DATA-фрагмента, неизвестные RTT/полоса. +// Перед первым init обнулить структуру; init сохраняет now_tb/link_id, задаёт STARTUP и начальное окно 4 DATA-фрагмента. void bbr_init(struct bbr* bbr); /* Обработать ACK rs и обновить входные/выходные cwnd_out (байты DATA) и pacing_rate_out (B/s). * mss>0 — frag_size normalizer; inflight_bytes — текущий занятый DATA-flight после ACK;