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

orignal ну все теперь все могут использовать C++17 без всяиких #ifdef

orignal и С++20 плд #ifdef где #else для C++17

onon Вот ужо теперь заживём!

orignal ну надо было со всем этим легаси навести порядок

orignal потому что на работе у нас уже давно 17

onon Угу

orignal собираемся уже переходить на 20

orignal в ближайшее время

onon Уже в этот релиз?

orignal i2pd да

orignal я про работу

orignal вот переставлю на работе машину на 22-ой минт

onon А, я понял

orignal с i2pd было решено уже давно как только поддержка сентос 7 закончится

orignal выпилить и openssl 1.0.2 и 11-ый

orignal я вот думаю может сразу 23 ий включить?

Vort пока U узлы просаживают рейт, не надо им никаких приоритетов в туннелях

Vort лучше начать с разгрузки низкоскоростных узлов

Vort условно говоря, перенести часть нагрузки с N узлов на X узлы

orignal я думаю перестать считать N высокоскостными и соотвественно не использовать в клиентских тоннелях

Vort даже если и так, среди O P X нагрузку тоже стоит распределять равномернее

orignal ну так о том и речь что над делать поноценный приоритет а не как счас

Vort речь была про U узлы, но с ними сейчас проблемы. между O / P / X перебалансировать - проблем быть не должно. по крайней мере, я о них не знаю

orignal а какие счас проблемы с U?

orignal вроде довольно неплохо работают

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

orignal ну так пусть проседает кого это ебет по большому счету

orignal затраты на построение тоннелей счас нулевые

Vort по-хорошему, надо бы делать эксперименты с различными модификациями i2pd, дающими приоритет U узлам и дающими приоритет R узлам - и смотреть на показатели работы

orignal это не времена эль-гамаля

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

WebClient98 hi

orignal onon есть вопрос по стимам

onon Да

orignal касается вот этог куска

orignal if (flags & PACKET_FLAG_DELAY_REQUESTED)

orignal {

orignal if (!m_IsAckSendScheduled)

orignal {

orignal uint16_t delayRequested = bufbe16toh (optionData);

orignal дело в том что согласно спекам если delayRequest нулевой то следует отсылать акк немедленно

orignal а у нас это не делается

orignal я хочу это починить но боюсь конфликта с твоей логикой

onon Это при каких условиях возникает

onon PACKET_FLAG_DELAY_REQUESTED

orignal когда та сторона присылает такой запрос

orignal это отправитель ставит

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

onon Не напомнишь, для чего это сделано?

onon PACKET_FLAG_DELAY_REQUESTED

onon А, это вроде отвечать на каждый полученный пакет

onon Не копить аки

orignal нет это запрашивать аки

orignal что значит сделано?

orignal это часть протокола

onon Это отправляющая сторона запрашивает?

onon Условный сервер

orignal любая из сторон может

orignal для каких то свои целей

onon Вроде запрашивает ответ не через 1/10 RTT а в выбранном интервале от 1 до RTT

orignal я уже не помню

orignal меня интересует случай когда 0

orignal чтобы использовать как пинг когда надо

onon if (delayRequested > 0 && delayRequested < m_RTT)

onon Больше чем 0 должен быть

orignal ну так неправильно это

orignal потому что в протоколе может быть и 0

onon Ну исправляй тогда

onon На ограничение входящей скорости повлиять не должно

onon Но потестировать после изменений, конечно стот

onon стоит

onon Но отправлять акк на каждый пакет - это, конечно же, дикий оверхед

onon zzz вернулся, ура

orignal почему на каждый?

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

orignal такой флаг должен приходить редко

onon Ну так может же на каждый запрашиватьб

orignal ну значит отвечать

onon Ну да

orignal ну так что делать то?

onon Я же говорю, переделывай как гадо

orignal просто вызывать SendQuickAck или у тебя как то там логика есть?

orignal договорились

onon Это может повлиять только на ограничение входящей скорости

onon Потом просто проверить. работает ли

orignal тут цель сделать пинги

Vort вроде ж на уровне сессии должны быть пинги, зачем ещё?

orignal сессия не может ничего посылать

orignal она может только к сообешниею блок прицепить

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

orignal а само сообщение все равно стрим пошлет

Vort при запросе ack`а

orignal нет

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

Vort тогда не понятно, как ты живость сессии проверяешь ack`ами

Vort если ответ может и не приходить

orignal предполагается что протоколы все равно отвечают

orignal что стримы что датаграмы

orignal стримы отвечают акками

orignal а для датаграм это делается принудительно

onon Учитывай, что если ограничение входящей скорости включено, и ты вызываешь акк, а он не попадает в пейс, то он сделает вид, что ничего не получал, и не ответит

Vort orignal: то есть, это что-то типа "ленивого" пинга? когда-то придёт, скорее всего, но не обязательно?

orignal onon но все равно же что то пошлет

orignal ну и я тоже буду делать перепосылку

onon Ну да, в следующий пейс

orignal Vort ну считается что да

onon Т.е. чуть позже

orignal предполагается что что то все равно ходит

orignal если мы отправим то что то придет в ответ

orignal onon ну это понятно

Vort понятно, значит для расчёта RTT сессии не годятся. жаль

orignal а вот с delay = 0 обязан сразу

orignal так я тебе сразу это сказал

orignal годится только для проверки живости

orignal onon что то с последними измненеимяи стало медленнее чем было

onon При каких условиях

orignal видео гонять если

orignal останавливает и подгружает

onon Через сколько хопов

orignal то же monkey.mp4 с animal.i2p

orignal 1 с каждой стороны

orignal просто в 2.53.1 оно нормально без остановок шло

orignal посмотрим сам

onon Сделай PREV_SPEED_KEEP_TIME_COEFF = 1; будет почти то же самое, что и до этого

orignal animal.i2p/monkeys.mp4

orignal счас

onon Но дело в том, что это сильнее перегружает промежуточные узлы

orignal это на какой стороне надо?

onon Поэтому для ширнармасс я оставил минимальное значение

onon На сервере

orignal а если поставить 0.5 что будет?

orignal так давай сделаем параметром

onon Потому что если все так будут делать сеть может не выдержать

orignal в конфиге тоннеля

orignal пусть по дефолту будет минимум а кому надо мощный тот пусть увеличивает

onon Вообще для этого алгоритма 1 - это "нормальное" значение

orignal так а если 0.5?

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

onon Поэтому я искусственно замедлил

onon Это влияет на скорость "разгона"

onon У меня на сервисах 0.5 и стоит

onon А ещё окно минимальное 5

orignal а почему не хочешь параметром сделать?

onon Можно сделать, я просто не знаю как это назвать

onon Придумай, сделай

orignal highload пойдет?

onon Не совсем понятно

orignal в тоннеле понятно

orignal счас спрошу у джавистов

onon Вроде высокая нагрузка на промежуточные узлы

onon Давай попробую объяснить, что делает этот параметр.

orignal да я понимю что

orignal у них есть

onon Ок

orignal название спрощу

onon Нужно ещё иметь в виду, что постоянная перегрузка туннелей может наоборот ухудшить ситуацию

onon На прямом линке с единицей действительно выжимает больше

onon А вот на длинных туннелях это наоборот замедляет, почкольку приходится ждать нормализации RTT

onon У явы есть параметр i2p.streaming.congestionAvoidanceGrowthRateFactor

onon По смыслу похож, но реализация другая

orignal я с тем параметром хочу стороить только через P и X

onon Ну если твои P & X перегружены, он всё равно больше чем есть не выжмет

onon А если там есть ява, то loss будет тормозить

onon Как один из примеров работы этого параметра: если через один промежуточный узел проходит два разных туннеля со всеми одинаковыми параметрами кроме PREV_SPEED_KEEP_TIME_COEFF, то тот, у которого PREV_SPEED_KEEP_TIME_COEFF больше - тот и выиграет полосу.

onon Но если все поставят максимальное значение, то будет плохо

onon Условно можно использовать для приоритезации трафика, наверное

orignal ну вот я и говорю параметр

orignal bulk как говоорит дрозд

onon bulk это скорее для bbr, если кто-то его сделает

orignal ну так скажи мне то как быть?

onon вроде как режим с минимальными задержками, если я правильно понял

orignal lowlatency

orignal тогда

orignal и что с ним? 5 и 1 ставить?

onon Я уже запутался, что ты хочешь сделать

onon Вынести этот параметр в tunnels.conf или что-то другое

orignal я это и хочу

orignal но хочу всего один

onon Сделать условный "переключатель"

orignal lowlaterncy=true ставим 5 и 1 а иначе 1 и 0.1

onon Тогда наоборот получится

orignal как сделать чтобы было как 2.53.1?

onon Если поставишь 1 то latency сильнее прыгать будет

onon И чаще перегружать

onon Так он и сейчас так как там

orignal нет

orignal счас много хуже

orignal точнее надо не как в 2.53.1 а после твоих первых коммитов

onon А в 2.53.1 был сброс окна при смене туннеля?

orignal не знаю

onon Я думаю это влияет

orignal короче скажи что мне поставить и я проверю

onon Но мне кажется правильным сбрасывать окно если новый маршрут

orignal да

orignal так будет так если 5 и 1 поставить?

onon Понимаешь, тут много факторов.

onon Если туннель слабый, что ни ставь - не поможет

orignal мне надо только чтобы как тогда

onon С единицей он просто будет более агрессиным

onon Ну вот ставь единицу

orignal а окно 5?

orignal думаю bulk кстати нормально

onon Ты меня в сомнения вгоняешь

onon Нехорошо так делать

orignal в какие?

orignal почему?

onon Если только для себя - можно ставить что хочешь

onon А если так все будут делать

orignal это же только на нагруженных серверах

orignal а зачем это всем?

onon Тут вопрос не про твои мощности, а про мощности промежуточных узлов

onon Ты их будешь перегружать а не себя

orignal а тогда нехуй пубдиковать P или X

orignal а назвался груздем полезай в кузов

onon Если он X и он сейчас не нагружен, то он выдаст максимальную скорость с любым значением параметра хоть 0,1 хоть 1

onon А вот если вас на этом узле двое

onon И нужно делить, то тот, кто более агрессивный - тот получит больше

orignal ну так почему лагает тогда?

onon Значит перегружены узлы

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

orignal естественно

orignal ну а тогда то как работало?

onon Ява например сильно перегружает своим алгоритмом без пейсинга

orignal понятно что я могу просто взять тот коммит

onon Тогда он по-умолчанию был агрессивным

onon С условной единицей

orignal ну вот если я поставлю 5 и 1 то будет он?

onon Не совсем

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

onon Тогда тебе нужно ещё сброс окна при смене туннеля отключить

orignal ?

onon Потому что меняются туннели довольно часто

orignal а нельзя сброс заменить уполовиниванием?

onon Он на INITIAL_WINDOW_SIZE = 10; сбрасывает

onon Можешь его побольше сделать

onon до 32 например

onon Но это прям очень неспортивно

orignal а если у нас текущее не дошло то не менять?

Vort раньше алгоритм игнорировал смены туннелей, а теперь начал сбрасывать параметры? )

onon Что не дошло?

onon Да

onon Раньше он подстраивался "на лету"

orignal если у нас окно например 15

Vort я тоже на этот забавный эффект натыкался

orignal так а что если мы будет уполовинивать но и если меньше то INITIAL

Vort делать вид, что ничего не поменялось, оказывалось эффективнее, чем как-то пытаться обрабатывать смену туннеля

orignal так как смотрите на уполвинивание?

onon Уполовинивание в каком случае

onon Я не совсем понял из твоиз объяснений

orignal при смене тоннеля

Vort чтобы смена туннеля приводила к уменьшению окна в 2 раза?

onon Это нелогично

Vort теоретически, имеет смысл. а там уже тесты...

onon Мы не знаем, что там за туннель

orignal не сбарасываем в INITIAL а ставим половину текущего окна

orignal если меньше INITIAL то INITIAL

onon Алгоритм, вроде должен быть универсальным

Vort можем догадаться

Vort "примерно такой же, как и раньше, может, чуть (в 2 раза) хуже"

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

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

onon Так тут не про код, а про алгоритм

onon Как обрабатывать ту или иную ситуацию

onon Можно ещё loss отключить, будет быстрее

onon Но дед будет недоволен

orignal ну так сделать уполовинивание?

orignal я попробую

orignal и кэффицент 0.4 поставить по умолчанию

onon Мне это всё не нравится, нужно подумать

orignal ну я думаю хуже не станет

orignal тем более до релиза время есть

onon Если ты хочешь сделать очень быстро для всех - ничего не выйдет

onon Только для "себя" за счёт других

orignal для все и не надо

orignal только для нескольких узлов

orignal в какой строчке это менять?

onon Про сброс окна при смене туннеля?

orignal да

orignal вот тут? m_WindowDropTargetSize = INITIAL_WINDOW_SIZE;

onon 1432

orignal у нас версии разные

orignal if (m_WindowSize > INITIAL_WINDOW_SIZE)

orignal {

orignal m_WindowDropTargetSize = INITIAL_WINDOW_SIZE;

orignal m_IsWinDropped = true;

orignal }

orignal вот в этом месте?

onon Да

orignal m_WindowDropTargetSize = m_WindowSize/2?

onon Если у тебя сейчас окно 15 и ты уполовинишь, получится 7,5

onon Меньше чем INITIAL_WINDOW_SIZE

orignal это понятно что там std::max

orignal я не понимаю что такое m_WindowDropTargetSize

onon Пробуй

orignal я правильно написал?

orignal или надо m_WindowDropTargetSize = m_WindowDropTargetSize /2?

onon m_WindowDropTargetSize - это нижний порог, до которого мы должны сбросить окно, прежде чем снова начать разгоняться

onon > m_WindowDropTargetSize = m_WindowSize/2?

onon так

orignal спс

orignal счас попробую

onon Да, я понял, почему прошлая версия была быстрее

orignal float m_WindowSize, m_LastWindowDropSize, m_WindowDropTargetSize;

orignal почему float?

orignal и почему?

onon Потому что алогритм такой

onon Поэтому float

onon Прошлая версия просто сильнее перегружала туннели, поэтому они чаще менялись, и "слабые" отсеивались.

onon Оставались только те, которые могут держать такой уровень перегрузки

orignal ну попробуем

onon А эта версия правильнее работает с туннелями, меньше их перегружает, и поэтому реже перескакивает

orignal так почему нужен float?

onon И работает "с тем что есть"

orignal у тебя же окно в пакетах

onon Там расчёт окна требует

orignal где?

orignal не верю что там нужен float

onon m_WindowSize += 1 - (1 / ((m_LastWindowDropSize + PREV_SPEED_KEEP_TIME_COEFF) / m_WindowSize));

onon Здесь

orignal и для чего тут float?

orignal приведи его к float только в формуле

onon Потому что с каждой итерацией m_WindowSize изменяется на сотые и тысячные доли

orignal а ну понял

onon А он рассчитывается на каждый пакет

orignal нормально тогда

orignal я бы правда сделал его с множителем например 100

onon Ты уже говорил, что переделаешь на инты

onon Я бы посмотрел

orignal чуть позже

onon Кстати этот коэффициент можно делать и меньше 0,1 но тогда float не хватает

orignal мне float глаз режет

orignal я пока 0.35 поставио

onon Как будет угодно

onon Можешь даже 3,5 поставить

orignal а ну да

orignal счас

orignal а тебя написано 0.1-1

onon Ну с 3,5 тоже работать будет

onon Только неправильно

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

onon И будет разгоняться слишком быстро

orignal так не надо

orignal закоммитил

orignal поглядим

orignal вот теперь стало хорошо

onon Это тебе просто быстрый туннель попался

orignal возможно

orignal это ты там качаешь?

orignal я то я чей то стрим вижу

onon =)

onon Как и было до. 50-60 кБ/с

onon Сломал

orignal ну я не мерял видел что не рвется

orignal что сломал?

onon failed

onon Сломалась закачка

orignal так давай чинить

onon У меня в тестах почему-то никогда такое не вылазит

onon Чтобы failed

onon Всё время просто зависает

onon Может вебсервера настройки

onon Хз

orignal может

orignal а у меня как раз ничего не зависает счас

orignal server {

orignal listen 127.0.0.1:4065;

orignal server_name localhost;

onon Можно, кстати, в консоль выводить текущую скорость отдачи

orignal а как?

orignal вот это все настройки сервера

onon через m_PacingTime и STREAMING_MTU

onon Ворт делал

orignal ну так пока оставить этот вариант? или еще что то подкруить?

onon Ну я пока ещё "отдыхаю", думал после ещё оптимизировать работу на низких скоростях

onon Или уже нужно начинать заканчивать

onon Там есть неэффективность, когда сбрасывает окно сильно

orignal ну надо примелимую скорость выдать

onon Потом медленно разгоняется

onon Ну блин, больше чем есть не выжмешь

onon Можно конечно сделать немного быстрее, но будут огромные задержки

orignal ну поиграться еще с парамтерами

onon Да, с параметрами поиграться можно, но это +5 ну может 10% может добавить

onon Что ещё можно оптимизировать...

onon Можно RTO при смене туннелей снизить до 5 пробовать

onon Можно криптографию пытаться ускорять

onon Потому что у меня например на прямом линке выжимает максимум 5 МБ/с

orignal этого достаточно

orignal больше ты вряд ли выжмешь

onon Ну а так туннель будет работать со скоростью самого медленного узла

onon Можно loss отключить

orignal это где?

onon Тогда через яву будет быстрее работать

orignal попробую ка я N убрать из тоннелей

onon 1274 // ProcessWindowDrop ();

onon Игнорировать потери пакетов

onon Не сбрасывать окно

orignal тьфу ты

orignal опеучтка же

orignal нет нормально все

orignal пардон

orignal я придумал

orignal а если роутеры хорошо работающего тоннеля поменчать в профилировщике?

onon Главное чтобы это не стало вектором для атаки

orignal а как например оно может стать?

orignal это же наш собтсвенный трафик и мы замеряем как он ходит

onon Я запускаю быстрые хорошие узлы, и они с большей вероятностью выстроятся в цепочку. А там уже дело техники

orignal решил я таки N выпилить из клинтских тоннелей

onon Это вид пассивной атаки нацеленный не на конкретную жертву а на случайную

orignal мы тоже не дураки мы берем им по одному в тоннель до тех пор пока не будет большой пул