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

Vort ага, опять горб на графике нарисовали: paste.i2pd.xyz/?8068e3809b7e72d5#5ux2szCnpYXtaykhVE3efWMoECbbEbwXeuZzeKW7WtCn

orignal а я как раз в тот момент рестартовал

kiriewski orignal github.com/PurpleI2P/i2pd-android/pull/66

kiriewski Может сделать для конфига основную секцию? там где general options так и перенести их в [general]?

orignal подождем R4SAS-а

orignal я ему счкажу

kiriewski Ещё сделано Tile, это "шторка". Но при нажатии на i2pd значок такое же поведение, как при нажимании на i2pd в приложениях

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

onon Лось, давай я попробую ещё раз объяснить в чём проблема с длинными очередями. Представим ситуацию: через транспорт равномерно шлют данные десять узлов.

onon И тут приходит одиннадцатый с кривым CC или просто злой, и начинает топтать туда данные, и занимает всю очередь. Пакеты остальных пользователей встают в конец очереди и дропаются через некоторое время.

onon Соответственно, они не получают ни одного аска, и что делают? Правильно, переотправляют данные снова, усугубляя ситуацию.

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

orignal ну а ты предлагаешь назначать приоритет

onon Я скидывал вчера рабочий код RED, который протестировал.

orignal в твоей схеме одна неправильность

onon Приоритет можно потом добавить для своих пакетов.

orignal новый тоннель то пойдет другим маршрутом

orignal скин снова

onon paste.i2pd.xyz/?38f7cafc24357b79#C8wTzrWcPiw9S2auQwvgCxwosbsDdi6rhXLWxJ9KG5Tk

orignal ну и в чем там основная мысль?

onon Как дед говорил, чем больше заполнена очередь, тем выше вероятность, что мы не вставим пакет в очередь, а дропнем.

onon И на стриме начинает относительно равномерно расти пакетлосс пи перегрузках

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

onon При 50% - около 1% при 100% - 100%

onon При 75% - 50%

onon Примерно так

onon Т.е. после 50% вероятность дропа растет линейно

orignal ну понял

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

onon Убеди ворта

orignal в чем?

orignal там можно же и по времени

orignal а не по размеру

onon Опять 25

orignal так принцип тот же

orignal если начало очереди сидит давно то дропать

onon Объясни

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

onon И какова в таком случае вероятность пролезания через очередь пакетов от "добросовестных" десяти отправителей?

orignal точно такая же как в твоей схеме

onon А для чего тогда нужен таймаут?

orignal таймаут чего?

onon Жизни пакета в очереди

orignal долго просидел выкидываем

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

onon Надо подумать, вот так сразу не скажу.

onon И пакеты, которые уже в очереди, тоже дропаем через 2 сек?

orignal как до них очередь доходит проверяем не протух ли

onon Т.е. если у нас транспорт завис на 2 сек, дропаем всю очередь?

orignal нет не всю

orignal а только то что превышает 2 секунды

orignal возможно есть более свежие

onon Чем-то мне всё равно эта "ВременнАя" очередь не нравится. Я понимаю какую проблему она пытается решить, но пока лучшего решения предложить не могу.

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

onon Но RED всё равно нужно добавить

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