~AreEnn
~R4SAS
~acetone
~orignal
~villain
&N00B
DUHOVKIN_
Guest7184
Most2
Nausicaa
Nikat
Ruskoye_911
Vort
Xeha
anon3
b3t4f4c3
daemon
fidoid
hypn--direct
hypn-direct-nb
karamba_i2p
nemiga
not_bob_afk
plap
poriori
profetikla
qend
segfault
soos
teeth
tensor
tetrimer_
tux
uis
un
unlike
user
vade
whothefuckami_
Vort
ага, опять горб на графике нарисовали: paste.i2pd.xyz/?8068e3809b7e72d5#5ux2szCnpYXtaykhVE3efWMoECbbEbwXeuZzeKW7WtCn
orignal
а я как раз в тот момент рестартовал
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
скин снова
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
грубо говоря если линкс подвис то дропаем случайно