From 635e1726e6ccec4e8df6d853980a49055017f00f Mon Sep 17 00:00:00 2001 From: evgeny Date: Thu, 29 Oct 2026 21:37:40 +0100 Subject: [PATCH] Document BLE readiness fixes and remaining HCI queue delay --- doc/ble_etcp.txt | 52 ++++++++++++++++++++++++++++++++++++++++++- doc/ble_transport.txt | 9 +++++--- 2 files changed, 57 insertions(+), 4 deletions(-) diff --git a/doc/ble_etcp.txt b/doc/ble_etcp.txt index 77271f4b..7947a426 100644 --- a/doc/ble_etcp.txt +++ b/doc/ble_etcp.txt @@ -1,5 +1,13 @@ BLE GATT → ETCP (chatgui desktop + Android) +Текущее состояние диагностики задержек (29.10.2026): +Write Without Response/Notify, HIGH и PHY2M включены. Исправлены готовность +BlueZ по ServicesResolved, использование старого ManufacturerData, входящий +HIGH Android и потолок DATA RTO=1s. Версия объявления повышена до 2, чтобы +не подключаться к старому DATA Write/Indicate сервису. Полная нагрузка обеих +аппаратных ролей пока не подтверждена: остаётся очередь между локальным +completion и HCI TX. Успех короткой пробы не означает устранения этой очереди. + Общий код: tools/cgathui_common/ble_etcp.c/h. Платформенные backend остаются в lib/ble и android_ble.c; Qt не участвует в протоколе. UTUN binary этот модуль не собирает. При активном UTUN-сервисе общего instance @@ -292,7 +300,8 @@ HCI можно снимать через sudo btmon -w FILE; обычному п - ETCP усиливает перегрузку: INIT вначале повторяется примерно каждые 50ms с padding; DATA RTO ограничен 1s даже при уже измеренном KA RTT=5..6s. В результате повтор может попасть в очередь раньше физической отправки оригинала. - Алгоритмы INIT/RTO в этом исправлении не менялись. + На этапе исправления incoming HIGH алгоритмы INIT/RTO ещё не менялись; + последующее исправление RTO описано ниже. Отдельно найден мешающий discovery: D-Bus sender :1.70, PID3047 kdeconnectd, каждые 60s устанавливает Transport=bredr. BlueZ объединяет его с нашим Transport=le, @@ -310,6 +319,11 @@ HCI можно снимать через sudo btmon -w FILE; обычному п с доступным кешем и ServicesResolved=false падал до исправления, теперь проходит; после сигнала resolve используется актуальный MTU517 вместо прежнего MTU23. В аппаратной пробе видны оба snapshot: connected=1/resolved=0, затем resolved=1. +- GetManagedObjects используется только как metadata snapshot: закешированное + ManufacturerData больше не обновляет discovery/last_seen. Иначе старый RPA + телефона мог выдаваться за актуальный endpoint. Новые объявления поступают + только из live InterfacesAdded/PropertiesChanged. Регрессионный тест со старым + ManufacturerData в snapshot падал до исправления и проходит после него. - Android после первой входящей CCC открывает BluetoothGatt handle к тому же ACL исключительно для requestConnectionPriority(HIGH). У BluetoothGattServer нет соответствующего публичного метода. Новый handle не выполняет discovery/DATA, @@ -354,3 +368,39 @@ UTUN_TEST_DEBUG=1 включает отпечатки кадров также в теста проходят. Пробы восстанавливают GUI, Android-политику и временное состояние KDE Connect. Сборку APK и запуск instrumentation нужно выполнять последовательно: одна проба во время установки завершилась Process crashed и не учитывается. + +Изоляция старого протокола и RTO при RTT больше секунды +------------------------------------------------------ +Сосед 1588291579282de3 публиковал DATA RX=Write/TX=Indicate. Android пытался +подключиться к нему примерно каждые 6s и обнаруживал несовместимые свойства. +Новый wire-profile требует объявления VC/version=2; версия 1 отклоняется +на discovery, до connectGatt. JNI передаёт scan prefix из общего C codec, +Kotlin не хранит отдельную версию. Нужны новые сборки на обоих пирах. +В /tmp/ble-ready-priority-v2-* нет этих подключений: 128/128 echo за10.623s, +суммарно36149B/s, TX queue до0.554s. Длинные повторения остались нестабильны: +/tmp/ble-ready-desktop-load-v2-* 49/512, /tmp/ble-ready-android-central-v2-* 439/512. + +В desktop-load-v2 при KA_RTT_us=2025400 повтор DATA назначался через1000000us; +далее наблюдался RTT2..6s с тем же потолком. Попытки удалялись раньше ACK, +повторы увеличивали очередь и мешали получить действующие DATA/BBR samples. +etcp_tx_rto_us теперь сохраняет ceil(1.2*max(DATA_RTT,KA_RTT)+1.5*jitter+3000us), +минимум10ms и начальное1s без RTT; ограничение сверху — представимость uint32. +Переполнение формулы считается в uint64 и логируется WARN при насыщении. +test_etcp_windows проходит все63 сценария, включая RTT2s/ACK1.5s без повтора, +таймер7.8672s и предельные значения. Формат DATA/ACK и модель BBR не менялись. + +Аппаратная проба после исправления: /tmp/ble-ready-rto-desktop-v2-*. +MTU517, HIGH принят, PHY2M. За71.328s подтверждено183/512 echo, complete=0, +суммарно7697B/s; это НЕ успешный нагрузочный проход. Сопоставлены534 TX кадра: +local completion→HCI до4.583s; у503 RX кадров HCI→callback0.7..2.5ms. +До первого INIT_RESPONSE отправлены24 INIT (вначале каждые~50ms), после готовности +линия продолжает передавать кадры. Исправление RTO не ограничивает очередь ОС. +Начальный RTO без RTT всё ещё1s, и в этой пробе он сработал до первого измерения. +Нужен отдельный выбор ограничения стартовых INIT/нижней TX-очереди; изменение +одного таймера не считается подтверждённым устранением всех задержек BLE. + +При полном check обнаружена некорректная фикстура test_etcp_server_lifecycle: +синтетический линк MTU=0 не мог отправлять keepalive, но тест ожидал роста счётчика. +После аудита ошибок счётчик увеличивается только при принятии пакета транспортом. +Фикстура теперь явно задаёт результат отправки через codec без сетевого I/O; +добавлена проверка, что busy/error сохраняют счётчик, а успешная отправка увеличивает. diff --git a/doc/ble_transport.txt b/doc/ble_transport.txt index 9e27a36b..be1924d5 100644 --- a/doc/ble_transport.txt +++ b/doc/ble_transport.txt @@ -5,7 +5,7 @@ BLE транспорт VibeChat (lib/ble) Независимая от Qt библиотека предоставляет manufacturer-броадкасты и адресные двусторонние GATT-сессии. Один локальный GATT-сервис обслуживает до 16 соединений. Броадкаст — повторяемое ОС объявление, а не гарантированно доставляемая датаграмма. -Общий codec ble_identity.h: VC (2 байта), версия 1 (1), node_id BE64 (8), +Общий codec ble_identity.h: VC (2 байта), версия 2 (1), node_id BE64 (8), имя UTF-8 (0..13). Имя сокращается по границе символа. Всего 11..24 байта. Приглашения и автоматический выбор соседей реализованы в tools/cgathui_common (doc/ble_etcp.txt); транспорт не запускает JOIN/ETCP. Node ID передаётся в HELLO для сопоставления сессий; подлинность он не доказывает. @@ -70,8 +70,11 @@ UUID RX: f61a9021-4abc-45ac-98e1-761df4c13811 (Write Without Response) UUID TX: f61a9022-4abc-45ac-98e1-761df4c13811 (Notify) UUID INVITE: f61a9023-4abc-45ac-98e1-761df4c13811 (Write + Indicate) RX/TX названы относительно сервера; API одинаков для обеих ролей. -UUID определяют эту версию. Это отдельный протокол от Android BLE test v2; -автоматическую совместимость с tools/ble-test-android он не заявляет. +Версия объявления 2 означает DATA Write Without Response/Notify; объявления +версии 1 отклоняются до GATT-подключения. Desktop и Android должны использовать +новую версию вместе. Scan prefix Android приходит из C codec через JNI start, +номер версии в Kotlin не дублируется. Это отдельный протокол от BLE_EXAMPLE +и tools/ble-test-android; автоматическая совместимость с ними не заявляется. Все многобайтные целые big-endian, без выравнивания C-структур. HELLO: [type=1:1][source_node:8][target_node:8], Central -> Peripheral.