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

onon orignal, мне кажется, у нас где-то внутри роутера пакеты ломаются или теряются

onon На большой скорости большие пачки пакетов пропадают, клиент choked выставляет

onon И это на прямом линке, на хорошей сети

onon На SSU2

onon Транспорт

orignal а ты на NTCP2 попробуй

Vort точно большие? просто про мелкие потери я знаю, разбирался когда-то

Vort разве что может мелкая потеря приводит к лавинному эффекту

Vort хотя может это и другое что-то

onon choked это если больше 256 пакетов потерялось

orignal в SSU2 там есть лимит на размер очереди непождтвержденных пакетов

onon Ты окно имеешь в виду

onon Так он тогда новые отправлять не будет пока старые не подтвердятся

onon А не дропать их

onon NTCP2 4МБ/с 0 потерь пакетов за 5 минут

orignal ну давай чиниь SSU2

orignal окно у SSU2

orignal там тоже есть

orignal onon ну так ты прримерно понимаешь в чем затык в SSU2?

onon Нет

orignal так добавь логов

orignal размера окна там

onon Я пока стримы ломаю

orignal рестранмиссий

onon Не досуг

onon Как стримы доломаю, может и SSU2 ломать начну

orignal проверил мое посленее изменение?

onon Да, работает

onon m_MsgLocalExpirationTimeout = std::max (I2NP_MESSAGE_LOCAL_EXPIRATION_TIMEOUT_MIN,

onon std::min (I2NP_MESSAGE_LOCAL_EXPIRATION_TIMEOUT_MAX,

onon (unsigned int)(m_RTT * 1000 * I2NP_MESSAGE_LOCAL_EXPIRATION_TIMEOUT_FACTOR)));

onon m_MsgLocalSemiExpirationTimeout = m_MsgLocalExpirationTimeout / 2;

onon Вот эта хуйня их дропает

orignal это не я писал

orignal Vort

onon Поэтому транзита нихера нету

onon Мы их дропаем, они окно сбрасывают.

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

Vort но если хочется что-то поломать, то можно покрутить константы

Vort это защитный механизм, при нормальной работе остальных систем он срабатывать не должен

orignal получается что 4мбс не пролазит

Vort на SSU2 уровне - возможно. только этот лимит тут не при чём

Vort затык вероятно из-за неверно расчитанного количества пакетов "в полёте"

onon Смотри, мы в стриме после старта начинаем разгоняться, увеличивать размер окна. И увеличиваем его за 1 RTT на некую величину. В случае, если мы увеличили окно больше чем нужно, то в узком месте на транспорте будет расти очередь. Но мы об

onon узнать только через 1 RTT по росту задержки.

Vort ну или стримы пихают больше чем надо

onon И всё это время наши "лишние" пакеты должны лежать в буфере транспорта

Vort так там константа от 1.5 до 3 RTT

onon И понемногу "стравливаться"

onon Ну ты же понимаешь, что на транспорте у тебя RTT будет 100мс а на стриме 1000мс

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

onon И всё это время он будет продолжать слать

onon В приципе можно сделать инкркмент окна 1/RTT

onon Но я уверен, вам это не понравится

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

orignal а почему с NTCP2 такой проблемы нет?

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

Vort onon: ты же говорил что дроп куском идёт. надо бы понять, почему

onon Потому что в очереди накопилось больше 256 пакетов

onon И он их разом дропнул

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

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

Vort именно тот сценарий, против которого эта защита и делалась

Vort если пакеты постоянно по-немногу ползут, то по-немногу и дропаться должны

onon Ну значит за 1 RTT набралось больше 256 таких вот единичных дропов

onon За 1 секунду имеется в виду

onon И сервер ещё не успел их переотправить

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

onon И так по три пакета дрейнит всю очередь

onon Короче надо это переделывать

onon Я это всё выключил, и норм скорость стала на SSU2 на прямом линке, как и на NTCP2

onon И choked не вылазит

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

onon WREDом

Vort orignal: да там скорее всего можно решить эту проблему подкруткой констант

Vort но мне не нравится идея разрешать постоянную перегрузку транспортов

Vort "<@onon> WREDом" и будет "<@onon> Ну значит за 1 RTT набралось больше 256 таких вот единичных дропов"

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

onon И очередь больше нужно сделать

Vort ну поставь I2NP_MESSAGE_LOCAL_EXPIRATION_TIMEOUT_FACTOR = 9 вместо 3

Vort но что от этого может поломаться - я уже не помню

onon Уже поставил 100

onon И стало норм

Vort то есть, нужно решить вопрос "насколько допустимо перегружать транспорт". у меня он решён вот тем кодом и вот теми константами

Vort конечно это всё можно менять. но решение "можно перегружать сколько угодно", очевидно, не годится

onon Ну ты защитился так сильно, что через SSU2 транзит почти перестал ходить

Vort открыл сейчас вкладку транспортов и вполне вижу 9-значные числа в разделе SSU2

onon А по скорости что?

onon А не сумма байтов за три дня

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

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

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

Vort о пакетов должно позволяться

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

Vort на сценарий что потребуется в медленный транспорт напихать столько же, сколько может выдержать только большой, я расчёта не делал

Vort onon: стоит ещё проверить, может иметься возможность словить локальную перегрузку. у пакетов есть ondrop обработчики

Vort тогда не придётся целый RTT стрима ждать

onon Так тут вопрос именно про транзит, когда наш SSU2 узел является узким местом

onon Точнее наш линк до следующего роутера

onon Когда у нас начинает копиться очередь

onon Не обязательно в этот момент мы являемся инициатором трафика

Vort "<@onon> И это на прямом линке, на хорошей сети" откуда в таких условиях секундные задержки?

Vort имеешь в виду что все хопы под контролем?

onon Там не было секундных задержек

Vort какой RTT стрима был?

onon 6woqj4si4zc4j6gyie63qcpnenuy7c5nukket53ayoe4wo4a5naa.b32.i2p/chart9.png

onon Вот

onon Зеленый - это RTT

onon Это 5МБ/с

onon От 35 до 270 примерно

onon мс

Vort это три хопа? то есть, 300мс макс - примерно 100мс на хоп?

onon ноль хопов

onon Прямой линк

Vort бля

onon Да, сеть именно так и работает

Vort между двумя узлама трафик гонял получается?

Vort узлами*

onon Да

Vort и сколько там физически пинг? без нагрузки

onon 35 говорю же

onon Если просто пинговать не через i2pd - то 17-20мс

Vort ну то есть ты перегрузил линк в 10 раз

onon Нет

Vort и мне вообще кажется что сеть тут не при чём

onon Я выжал максимальную скорость из i2pd

onon Ну или из своего процессора...

onon Я хз

Vort ты мог упереться в CPU, в при таком упоре i2pd работает крайне неадекватно

Vort а при*

onon Т.е. эти задержки были не на сети, а внутри i2pd

Vort вероятно. так как я похожую херню на локалхосте видел. это надо проверить

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

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

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

Vort если заказали таймер через 10мс, а получили через 300мс, то мы в заднице и надо что-то делать