#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

onon paste.i2pd.xyz/?65f550893c687b3e#GTa7tgTbwraY8cuKytN14vUGVjUh6TE4Cgkuubhe3yRq

onon paste.i2pd.xyz/?e13b5a9eb4d2b1f8#BWd4RzTUkTV8H4RBcpa8dmMMqVUWFHFBWMtb8vfa9ZQg

onon Сделал для

onon m_SendTimer.expires_from_now (boost::posix_time::microseconds(1000));

onon Там можно константу сделать и менять пробовать

onon Я на 10000 пробовал, работает немного хуже, но работает

onon Сильно не тестировал, может что пропустил. Завтра, если успею, может ещё погоняю.

onon *** ушел спать ***

orignal так поменяй лучше константу

testenc Vort, это верно что 4000 х 1.7кбит = 68МБайт/с ограничена скорость в i2p даже имея гигабитный канал и гигабитные каналы у следующих нод?

Vort "<weko> фактическая задержка между отправкой данных и из полученем 4-6 секунд" - по-моему, это демонстрация полного фейла congestion control`я

Vort "<onon> Для SSU там херня какая-то сейчас" это ты про мой код? он просто позволяет стримам проявить себя :)

Vort testenc: ну сейчас да, но видишь же, в чате код и других вариантов алгоритмов выкладывался. надо тестировать

Vort "<onon> Сделал для" динамический размер блока что ли? сейчас потестирую

Vort "<weko> как не странно, проблема в SSU2" не факт. алгоритм дропа сообщений в SSU2 срабатывает только когда данных напихано реально больше, чем надо. для NTCP2 тоже надо так сделать, я до NTCP2 не добрался только потому, что при наблюдении за реаль

Vort ным узлом NTCP2 очередь переполнялась намного реже, чем SSU2

Vort не удивлюсь, если ослабив сильнее дропы в SSU2, ты вообще минутные пинги увидишь на стримах :)

Vort при правильной работе congestion control стримов очередь SSU2 переполняться не должна

Vort потестировал последний вариант алгоритма стримов: наконец-то локалхост выдаёт адекватную скорость: 76.7 Mbits/sec

Vort стабильность потока данных на локалхосте довольно неплоха, провалов не вижу, волны если и есть, то незначительные

Vort попробую теперь через 2RRY пустить

Vort через 2RRY и прыжки скорости есть и провалы, но это уже реальная сеть, сложно сказать, почему так происходит. в целом же, скорость неплоха: 14.7 Mbits/sec

Vort попробую сейчас откопать пингалку, проверю, действительно ли новая версия алгоритма лучше контроллирует задержку

Vort опять делал тесты через 2RRY. на 20 отправках в секунду по 10КБ каждая (recv=0.20MB/s), пинг нормальный - avg=102.9

Vort а вот если поднять размер отправки до 50КБ (recv=0.99MB/s), то начинается херня: и провалы по 10 секунд (avg=NaN) и пинги по 2 секунды (round-trip time (ms): avg=1474.5, min=1428.1, max=1556.1)

Vort лог для 10 КБ: paste.i2pd.xyz/?d708a822c6e41361#CEqSRD3VeoUyQuNRQHdWReERbdVsYB4pRyeuy9riSU3u

Vort лог для 50 КБ: paste.i2pd.xyz/?b8b73dcf5655a543#AsEAwpC6gwPvDrBECoh9kuwxVAgUEqyms4uca9BSQPDf

Vort orignal: по моему мнению, с последней версией алгоритма нужно сделать три вещи: 1. вернуть константу на место. 2. проверить на явные косяки. 3. вливать в основную ветку

Vort исправление регрессии с локалхостовыми тестами, на мой взгляд, очень важно

Vort что касается самого по себе congestion control - как я понимаю, там ещё много работы. но если он хоть изредка ловит разрастание задержки - то это уже намного лучше, чем ничего

Vort файл с хедерами, кстати, не соответствует cpp коду. но там две переменные всего добавить надо, как я понимаю

orignal последняя версия это какая?

orignal то что onon скинул?

Vort да

orignal я еще н смотрел

Vort 10 часов назад

orignal что он там поменял существенного?

Vort я так понял, сделал таки группировку пакетов

orignal и всегда миллисекунда?

Vort и теперь 1мс у таймера не лимитирует скорость

orignal сегодня сам гляну и зальем

Vort ну да, но надо туда константу воткнуть

orignal само собой

Vort и хедеры починить

orignal магические числа в коде это моветон

onon Да, с хидерами косяк, торопился, забыл добавить когда переписывал. Пару переменных пропустил.

onon paste.i2pd.xyz/?bceb076760b205c5#7YKC5qkxrfJx59ssMesjsF8azWBnukGPDshZNhfgz2Xx

onon > магические числа в коде это моветон

onon Там половина кода из магических чисел

orignal что не отменяет того что это моветон

onon Потом сами поправите, где можно без магии обойтись

onon Я сделал 20% работы, которые дают 80% результата

onon А дальше мучайтесь сами =)

orignal сделаем

orignal сегодня залью

onon Насчет того, чтобы сразу не делать окно 1024, подумай. Может постепенно лучше увеличивать.

onon Хотя, сколько там окно не делай, если туннель тянет 100 кБ/с, то больше не станет.

onon У меня ещё есть часов 5-6, будут вопросы - я тут.

orignal а когда ориентировочно вергешься?

onon Даже примерно не знаю месяц-два

Vort "<onon> Хотя, сколько там окно не делай, если туннель тянет 100 кБ/с, то больше не станет." поддерживаю. сеть достаточно нагружена, чтобы сгладить переходные процессы

orignal ну дед предлагает запрашивать скорость при построении тоннеля

orignal слать сколько тебе нужно

orignal а узел решает сможет он обеспечить или нет

Vort меня не столько окно беспокоит, сколько всплески пинга, пропущенные алгоритмом, но это таки оставшиеся проценты работы - подстройка

onon А я буду запрашивать, а пользоваться не буду

onon Vort: меня не столько окно беспокоит, сколько всплески пинга, пропущенные алгоритмом, но это таки оставшиеся проценты работы - подстройка

onon Это не пропущенные, это источник обратной связи - всплески пинга.

orignal ну и не пользуйся

Vort я так понимаю, в 90% случаев юзеру нужна скорость побольше

onon Хочешь без пинга - делай аналог bbr

orignal узел не должен резерировать

orignal он скажет может ли он обеспечить сейчас или нет

onon Тогда какой в этом смысл?

onon Нагрузка же динамическая

orignal такой что роутер может быть готов пропускать тоннель

orignal но не готов высоконагруженный

onon Это может быть полезно только для exploratory

Vort "<onon> Это не пропущенные, это источник обратной связи - всплески пинга." какое примерно время реакции на сигнал всплеска должно быть?

onon или чего-то похожего, наверное

Vort "<onon> Это может быть полезно только для exploratory" - те 10%, о которых я думал, да

onon > Vort: "<onon> Это не пропущенные, это источник обратной связи - всплески пинга." какое примерно время реакции на сигнал всплеска должно быть?

onon ПРимерно 1 RTT

orignal идея же в том что если я собрался гнать видео я и запрашиваю больше

Vort юзерская программа даже не знает, какая ей скорость будет нужна

orignal а если ирк я вообще не запрашиваю

Vort "<onon> ПРимерно 1 RTT" - ну а по тем логам, что я скидывал, всплески пинга юзерских данных были по 10 секунд, при том, что реально там пинг - 100мс. то есть, в 100 раз больше, чем надо

Vort короч это баги, и с ними надо аккуратно разбираться

onon Ну если та у тебя был пинг 10 секунд, то и реагироваля защита через 10 секунд

Vort orignal: ну вот стоит у юзера SOCKS и гонит он через него что попало. нереально тут запросить конкретную скорость

orignal тут нет

Vort onon: реально был 100мс, на предыдущем логе видно. ну да не буду спорить, это просто разбирать надо

orignal а если у тебя сайт с видиопотоком тут надо запрашивать

onon > Vort: onon: реально был 100мс, на предыдущем логе видно. ну да не буду спорить, это просто разбирать надо

onon Можешь попробовать чувствительность покрутить. Там delay сделан на разности сильно сглаженного RTT (Slow_RTT) и слабо сглаженного (RTT).

onon Если RTT_EWMA_ALPHA сделаешь больше - будет грубее, меньше - более чувствительная.

Titlacahuan в жабе эсть опций оптимизировать за bulk vs. latency но она ничего не делает

Vort может не срабатывает триггер, да. но может и попытки поменять туннель сбрасывают оценку. хотя тут был всего один туннель, так что не знаю, может не в этом дело

onon Я подбирал экспериментальным путём. Когда более чувствительная - работает лучше, но бывают туннели, которые могут работать быстро, но RTT там скачет, и постоянно срабатывает защита.

onon Я подбирал, чтобы в среднем работало нормально.

Vort может, два сглаживания надо

Vort для медленного нарастания и для быстрого

onon Да, в изначальной версии у меня три RTT было, разной сглаженности, но там сложный комбайн получился, я решил упростить.

Titlacahuan в принципе должно быть Additive Increase Multiplicative Decrease

weko [11:26:30] <orignal> ну дед предлагает запрашивать скорость при построении тоннеля

weko [11:26:38] <orignal> слать сколько тебе нужно

weko [11:26:54] <orignal> а узел решает сможет он обеспечить или нет

weko Уже предлагал. Не будет определения скорости по дропам, что гораздо лучше. Такую штуку надо делать

Titlacahuan за размера окна

Vort Titlacahuan: возможно. но вначале надо разобраться с триггером

Titlacahuan чего называеш триггер?

onon Сделай в яве окно 1024, и потестируй свой алгоритм

Vort Titlacahuan: условие при котором алгоритм начинает сбрасывать скорость

Vort а как именно сбрасывает - это уже другой вопрос

Titlacahuan аах, за этом эсть множество изследований

Titlacahuan в жава пользуем Westwood+

onon Titlacahuan - это болгарин что ли?

Titlacahuan я я

onon Который деда обидел?

Titlacahuan сам я

weko Может тупо сделать ограничение на скорость туннеля, а надо больше - используешь больше туннелей? Лучше распределение, меньше возможностей тайминг атак

onon Так уже сделали ограничение, можно в настройках выставить.

weko onon: я имею ввиду глобальное по сети

onon Мне не нравится такая идея

Titlacahuan Vort: en.wikipedia.org/wiki/TCP_Westwood

weko onon: распределение по туннелям всё равно нужно, для стабильности. Никогда не знаешь, когда туннель сдохнет

Titlacahuan работает много лучше чем Reno/Vegas которого пользовали во этом

weko Для датаграмм можно простой вариант ввести - просто брать два туннеля, и каждый второй пакет слать в один из них

weko То есть чередовать их

weko С датаграммами такая проблема была - много маленьких пакетов очень плохо, ведь под каждый в туннеле уходит по килобайту почти. Например, у игры 60 обновлений в секунду, то это ракет каждые 16мс, то есть 60 КБ/с, вместо возможных 6, например (если пакеты по 100 байт). Для

weko клиента это мб и не критично, а вот серверу, который шлёт апдейте на несколько клиентов - уже такое себе.

Vort weko: в ygg пробовали гнать данные как попало. получилось плохо

Vort в Snowflake тоже не вышло

Vort в Tor сделали просто резерв - и это вроде сработало. но в i2p и так резерв есть уже

weko Vort: почему как попало? Туннели то рабочие

weko Ну, пока один не сдохнет

Vort weko: ну ты же имеешь в виду часть пакетов в один туннель, часть - в другой?

weko Vort: да, чередовать

weko И ты пропустил сообщение:

weko [11:59:30] <weko> С датаграммами такая проблема была - много маленьких пакетов очень плохо, ведь под каждый в туннеле уходит по килобайту почти. Например, у игры 60 обновлений в секунду, то это ракет каждые 16мс, то есть 60 КБ/с, вместо возможных 6, например (если пакеты по 100

weko байт). Для клиента это мб и не критично, а вот серверу, который шлёт апдейте на несколько клиентов - уже такое себе.

Vort так вот это не просто сделать нормально. для стримов

weko Vort: для стримов уже всё сложнее, да

weko Для стримов надо полностью дублировать

weko И то скорости ж у них разные

weko Там всё сложно будет

Vort weko: а что надо делать - так балансировку нагрузки. но это _не_ ограничение скорости, это её перераспределение

Vort может кто-то гнать 5 мегов в сек - пусть гонит. но он же не один - остальным юзерам тоже часть канала нужна

Vort а когда будет один - то нет проблем

Vort это явно сложная и запутанная тема

weko Vort: ну это вопрос RED глобального, который дропает когда скорость на роутере превышает заданную

Vort сейчас бы проблемы попроще порешать

Vort не всегда есть "заданная" скорость

weko Vort: всегда есть

weko Ну кроме X

Vort но при этом возможности сети не бесконечны всегда

weko Но X это другое дело, там будет лимит порта выражаться в неспособности транспортов

Vort я как раз говорю о случаях, когда юзер не хочет морочиться с лимитами, а просто указывает "берите сколько хотите (из того, что можно взять)"

Vort а ещё есть такая особенность, как перегрузка направления

Vort одна страна может быть перегружена, остальные страны - недогружены

Vort и как-то это всё надо учитывать

weko Vort: у нас нету по geoip никакого определения, так что страны тут не при чём

Vort я имею в виду, что сетевой канал - он сам по себе неравномерный

weko i2p это 0.00000000001% от трафика всей сети. Думаешь мы можем на уровне стран что-то перегружать?

Vort если локально у юзера ещё есть свободная часть канала, это не значит, что нигде нету перегрузки

weko Сомнительно

weko Вот только у юзера можем

Vort перегрузку может давать не i2p, а какие-то внешние процессы

weko Ну, снижается скорость транспортов

Vort похоже, я хреново поясняю. может, когда-то получится получше

weko При чём больше у тех, у кого скорость уже большая

weko Хотя, нет...

weko В случае упора на лимит канала, он и так будет распределяться, как я думаю

Titlacahuan 600-700kb/s тяну с албата ))

orignal muwire?

Titlacahuan да, думаю обе 1 хоп

orignal а ты не разбирался по что скорость упирается?

Titlacahuan не изучал подробно

orignal так это важно

orignal явно же можно выжать больше

Titlacahuan согласен, библиотеку стримов можно много улучшить

Titlacahuan жаварская

Titlacahuan жаварскою*

orignal нет я про I2CP в i2pd толкую

orignal там явно все не оптимально сделано

Titlacahuan не замечаю проблемов но и не искал

orignal так медленно же

Titlacahuan кто так говорит?

orignal <Titlacahuan> 600-700kb/s тяну с албата ))

orignal это разве много?

Titlacahuan если у него 1 хоп тогда общо 4 хопа

Titlacahuan между нам 2 маршрутизатора с неизвестным ограниченнй

orignal у нас через стримы качает быстрее

onon Ну что там, вопросов не появилось? А то мне пора уже собираться.

orignal я только пришел

orignal пока нет счас проверю

orignal ну удачи тебя

orignal и надеемся увидеть тебя снова

orignal заливаю новые стримы

orignal опробуем их сразу на реальных узлах

Vort сборку хоть проверил?

orignal и запустил

orignal и локально погонял

Vort ок

orignal опять же если что откатим

fffff а какая разница с тем, что сейчас на последнем коммите

orignal как коммит назвать?

orignal resonable send timer ?

orignal вот залью увидишь

Vort Streaming congestion control improvements. Patch by onon.

orignal ага

orignal залил

Vort orignal: "Garlic: Can't handle ECIES-X25519-AEAD-Ratchet message" - это из-за дублей тегов лезет, да? я ответил юзеру на гитхабе, а потом засомневался

orignal там несколько причин

orignal может еще сессия сдохнуть

orignal короче пришло сообщение на сессию которая сдохла

Vort он спросил, надо ли делать issue, я сказал, что не надо

orignal не надо это обычное дело

Vort окей

orignal я на днях там кое что будут менять связанное с акками