diff --git a/doc/etcp_multipath_plan.txt b/doc/etcp_multipath_plan.txt index 39ce342b..c9ae3bce 100644 --- a/doc/etcp_multipath_plan.txt +++ b/doc/etcp_multipath_plan.txt @@ -115,6 +115,88 @@ BGP route exchange: 100/100 PASS (AB: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 + +Пакетный трейс нашёл ACK compression при осушении обратной очереди: для DATA +seq257..413 принято 170502 байта за186359мкс, а max(send_elapsed,ack_elapsed) +составил150732мкс. BBR получил1.131MB/s вместо фактических0.915MB/s. +В одном устойчивом участке DATA-pacing A=1.104MB/s при BWlim=8Mbit/s; +очередь A->B держится около40мс и задерживает ACK обратных DATA. +RTT приходит в BBR на каждом ACK (около124мс), причина не в устаревшем RTT. +Полный трейс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 +и rx_time_us:u64; это одна согласованная точка физического приёма DATA пути. +Счётчик включает допустимые физические копии DATA; это не логический till. +Попытка хранит последнюю известную точку при отправке. Дополнительная граница +rate sample: interval >= ceil(delivered * delta_rx_time / delta_rx_bytes). +Это сохраняет прежние границы send/ACK и не увеличивает оценку полосы. +В отличие от первого опыта с восстановлением времени из16-битного timestamp, +согласованная пара счётчик/время не использует агрессивную инвалидацию samples +при обратном ходе восстановленного timestamp. Первый опыт ухудшал результат +и не предлагается для внедрения. + +В header проверен флаг DATA-backlog + недавней передачи своего пути. +В окне применяется отдельное T_effective=k*min_rtt+delta; min_rtt не меняется. +Для опыта TTL=20мс, проверяется при расчёте политики на ACK. Это ещё не полный +контракт затухания при молчании: свежесть нужно проверять и при выборе DATA, +чтобы не ждать следующего ACK для снятия дополнительного запаса. + +Пять вариантов, по три последовательных запуска штатного bidirectional: +по3с прогрев +4с измерение, solo каждого канала и агрегат2+8Mbit/s RTT20/80мс. +Ниже min..max goodput A->B / B->A агрегата и максимальная очередь всех повторов: + штатный wire: 7.930..8.610 / 8.309..8.503Mbit/s; 52.9мс; + ACK+16 байт, без новой границы:8.113..8.189 / 8.032..8.320Mbit/s; 53.7мс; + новая граница BW: 8.095..8.236 / 8.154..8.396Mbit/s; 23.1мс; + граница + k=282/256, delta=3мс:8.179..8.404 / 8.142..8.171Mbit/s; 35.5мс; + граница + k=1, delta=10мс: 8.146..8.234 / 8.133..8.142Mbit/s; 33.7мс. +В измеряемых интервалах DATA retries=0. Все15 запусков не проходят весь +исходный скоростной профиль; пороги не менялись. Увеличение окна не дало +устойчивого выигрыша и увеличило очереди: выбирать коэффициент пока рано. + +Ещё3 опыта one-way -> duplex -> one-way на том же соединении PASS: +флаг/поправка не активны у отправителя в односторонних измеряемых фазах, +включаются при встречной загрузке и отключаются после её завершения. +Полная доставка, порядок, состояние сессии, попытки/очереди и память проверены. +ASAN/UBSan с detect_leaks=1: phases PASS; bidirectional FAIL по скоростным +порогам, отчётов sanitizer/утечек и нарушения полной доставки нет. + +ACK учтены по принятым пакетам: ACK-only — вся UDP-кодограмма с шифрованием +и служебными полями; piggyback — только ACK-секция внутри DATA, без повторного +начисления общих заголовков DATA. Единицы BWlim — UDP-байты без IP/UDP headers. +Для штатного агрегата ACK=0.515..0.559Mbit/s на направление, 5.15..5.59% +суммарного BWlim и5.50..5.93% фактического UDP-трафика. В среднем ACK-only: +0.445..0.455Mbit/s, ACK внутри DATA:0.088..0.090Mbit/s. +По отдельным каналам ACK занимают0.121..0.131 из2Mbit/s и0.384..0.431 из8Mbit/s. +При безусловном добавлении16 байт телеметрии ACK расходует0.707..0.743Mbit/s; +с новой границей BW —0.745..0.763Mbit/s. Накладные расходы реальны и учтены. + +План требует уточнения до переноса в основную реализацию: +1. Сохранить измеренный min_rtt и отдельные send/ACK/receiver интервалы. + Точку счётчик/время передавать только с положительными ACK, которые её + используют; не раздувать каждый DATA с пустой ACK-секцией. Изменение + формата выполнить целиком для TX/RX/dump/MTU и тестов. +2. Испытать объединение ACK: piggyback на готовом DATA — сразу; ACK-only + по существующему дедлайну2мс. Запрос границы окна/срочный ответ не задерживать. + Один таймер должен обслуживать ближайший deadline очередей путей, включая + повторное планирование после частичного piggyback/раннего пробуждения. + Сейчас посторонний wake sender может отправить ACK-only до этого срока. +3. Сначала повторить скорости/очереди с корректной оценкой BW и экономной + упаковкой ACK. Дуплексный коэффициент не вводить как обязательную часть + фикса без устойчивого выигрыша в дополнительных RTT/BW/асимметричных профилях. +4. До внедрения проверить reordering/loss/duplicate ACK, поздние попытки, + reset/recreate пути и простой; валидировать пару counter/time. Если новая + граница не представима в uint32 interval, пропустить оценку BW, а не + насыщать интервал с нарушением верхней границы скорости. TTL флага + определить для редких DATA/jitter/standby и проверить молчание без ACK. + +Результаты всех18 запусков: /tmp/etcp-duplex-native/results.json, +/tmp/etcp-duplex-native/summary.csv, /tmp/etcp-duplex-native/ack_bandwidth.csv. +Сборка: /tmp/etcp-duplex-native/experiment.mk; код/логи сохранены рядом. +Sanitizer: /tmp/etcp-duplex-native-asan/{bidirectional,phases}.log. + OOM следующей ступени приёма исправлен аварийным перезапуском сессии. До сохранения RX DATA в recv_q отказ остаётся обычной потерей без ACK. После принятия данных OOM в packer/unpacker или TX inflight запускает новую diff --git a/doc/tasks.md b/doc/tasks.md index a7086490..edc45bf6 100644 --- a/doc/tasks.md +++ b/doc/tasks.md @@ -29,6 +29,16 @@ 2+8+2 RTT20/80/200 — 10.566..10.749 из12; 2+8 одновременно в обе стороны — 8.080..8.379 из10 на направление. DATA-повторов в измеряемых исправных интервалах нет. Подробные результаты: /tmp/etcp-multilink-quality-20261023.csv/.txt. BGP-падение из-за INIT/remote_keepalive исправлено; отдельная задача ниже содержит итог проверки. + Дуплекс проверен18 последовательными опытами в /tmp/etcp-duplex-native/, исходники проекта не менялись. + ACK compression завышает BW:170502 байта приняты за186.36мс, sender sample использует150.73мс. + Нативный прототип 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мс. Дуплексный запас пока не считать подтверждённым исправлением. + 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. Код прототипов в репозиторий не переносился. Ранние копии до RTO, здоровье/пробы каналов и STCP backpressure пока не реализованы; пороги тестов сохранены. OOM после принятия данных исправлен аварийной сменой эпохи с сохранением физических линков. Старый поток отбрасывается без воспроизведения; после согласования владельцы получают REINIT.