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

orignal лол

weko я может доделаю выложу чтобы сам смотрел логи там и прочую лабудень

weko получается i2pd как рпг. можно две ветки выбрать - быть интродьюсером или давать больше скорости

weko точнее выбрать можно только одну из двух

orignal придется

orignal я вот разбирают с already requested

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

orignal вот отсюда и проблема

orignal починю

weko просто повышение окна в случае ssu2 не помогает

weko orignal: максимум что я смог - 400-500 KB/s из ssu2 выжать

weko const int MIN_WINDOW_SIZE = 32;

weko const int MAX_WINDOW_SIZE = 512;

weko const size_t SSU2_MIN_WINDOW_SIZE = 64; // in packets

weko const size_t SSU2_MAX_WINDOW_SIZE = 128; // in packets

weko вот параметры

orignal я же тебе сказал надо с акками там разбаираться

weko я просто кинул результат что вышло

weko больше если ставить нестально

weko хотя и промелькали на секунд 20 1.2 MB/s

weko хотел попробовать SSU, но понял что хер там я это сделаю

weko потому что фикса то нету там

weko а может и параметра

weko <weko> ну всё теперь оффициально: ш2зв МОГЁТ. осталось только сделать чтобы было реалистично

weko <weko> тут почти 1 MB/s

weko <weko> на 3+3 хопах

weko <weko> с пингов 100 везде

weko 1 MB/s почти ровно

weko но это на NTCP2

weko а, ну круто. после 500 мегов сдох стрим

weko ну тоесть его заглючило

weko не ясно почему

weko <weko> 3+3, 1024 window, 2 mb/s

weko вообще бывает и 2.6

weko завтра буду смотреть что влияет на window

weko охх 2.9 выжало

orignal смотри лучше к чему приводит потеря пакетов

weko хорошо щас 0.1 поставлю

weko я может щас велосипед изобратаю, но мне в любом случае интересно.

weko каждый раз отправляя пакет проверяем. если процент проваленных среди последних const пакетов < const, то window + 1. если же текущий пакет оказался то window - 1

weko хотя нахуй эти велосипеды

weko не интересно всё таки)

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

weko в SSU2 то?

orignal ну да

orignal тогда Ack блок прилетает какой он длины

weko думаешь его длины не хватает тупо?

orignal я думаю там бага

weko диапозоны не используются и потом фейл

weko потому

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

orignal я же говорю я думаю я лишнего подтверждаю

weko да полезно

weko на потерях 0.1% стабильно ведёт себя ntcp2

weko можно подождать разгон но тут уже 1.8

weko 1% потеря пакетов. медленне, но всё равно неплохо - 1.5

weko может ещё разгонится

weko добавил разброс +-15ms по пингу. ещё хуже, но в рамках приличия

weko 1.3 где то

weko <weko> more hard conditions: 50+-25ms ping, 1% packet loss. 1.4 MB/s

weko <weko> 55+-45. 1 MB/s

weko в реальной сети обычно лучше должно быть вообще

weko в реальной сети по для одного сокета +- одинаковый пинг

weko насчёт потерь без понятия

orignal завтра посмотрю насчет той проблемы с netdb

weko Угу

` orignal, соре за пинг. Болгарин (zlatinb) что-то сейчас делает в ш2з?

SuDo H~

orignal нет

weko orignal: окно должно подстраиваться как можно более большое, но при этом чтобы не было больше какого-то количества потерь?

orignal да примерно

orignal так

weko Ну именно процента потерь

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

weko Потому что когда много потерь замедляется, когда окно меньше замедляемся

orignal о чем я и говорил

orignal цель его подобрать

weko сейчас просто очевидно меньше чем надо ставиться

weko ведь если его насильно увеличить то скорость увеличивается

orignal разумеется там алгоримт не самый лучший

orignal а первое что в голову пришло

weko а мы сидим на скорость жалуемся

orignal ну мне некогда

orignal этим заниматься

orignal надо бабки зарабатывать ))

weko if (m_WindowSize < WINDOW_SIZE)

weko m_WindowSize++; // slow start

weko if (m_WindowSize < WINDOW_SIZE)

weko m_WindowSize++; // slow start

weko интересно

orignal ты почитай эти аггоитмы для TCP

orignal это все оттуда

weko чего читать если я могу код посмотреть

orignal так у меня код дурацкий

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

weko ну сначала попробую исправить уменьшение

weko оно кстати происходит в HandleResendTimer

weko что вообще не отвечает названию функции

weko тут вообще пиздец какойто

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

orignal по таймеру смотрим если ответа не пришло то перепосылка

weko так тут другие действия ещё

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

weko const int WINDOW_SIZE = 6; // in messages

weko это надо назвать SLOW_START_WINDOW_SIZE

orignal а x3

weko m_WindowSize -= std::round(packets.size() * 1.5);

weko вместо деления на 2

orignal попробуй

orignal но проверяй на 0

weko а что тут проверять

orignal и не *1.2

weko if (m_WindowSize < MIN_WINDOW_SIZE) m_WindowSize = MIN_WINDOW_SIZE;

weko это уже было

orignal а деление на 2 сделай через >>1

weko я от балды взял пока что

orignal не надо опеаций с плаваюзей точкой я к этому

weko понял, ну пока тест просто

weko очень медленно окно растёт

weko / linear growth

weko слишком медленно линейно растёт

weko есть подозрение что зависает оно из-за смены туннеля одновременной

weko кажется понятно почему стрим виснет

weko / TODO: send reset

weko ))

weko вот когда 6 достигает идёт вот это

weko m_Status = eStreamStatusReset;

weko Close ();

weko а в Close это

weko case eStreamStatusReset:

weko // TODO: send reset

weko Terminate ();

weko вторая сторона то не знает что мы закрываемся

weko с закрытием тут путанно

weko if (m_Status == eStreamStatusClosed)

weko Terminate ();

weko else if (m_Status == eStreamStatusClosing)

weko Close (); // check is all outgoing messages have been sent and we can send close

weko а это зачем в ProcessAck ?

weko if (m_Status == eStreamStatusClosing && m_SendBuffer.IsEmpty ())

weko SendClose ();

weko в SendBuffer. а нахуя если уже Closing то уже отправлено

weko case eStreamStatusClosing:

weko if (m_SentPackets.empty () && m_SendBuffer.IsEmpty ()) // nothing to send

weko {

weko m_Status = eStreamStatusClosed;

weko SendClose();

weko }

weko вот в Close ()

weko короче на эту кашу с закрытием у меня подозрение

orignal с закрытием это костыли

orignal я сколько не пытался чинить снановится хуже

weko порядок надо навести

weko не просто чинить а переписать

orignal надо

orignal но мне лень

mauzer всё что нужно знать про современные принципы программирования.

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

orignal дай мне команду из 10 человек работающих постоянно

orignal и все проблемы будут решены

orignal вопрос то ж в этом

weko возможно я понял кое какую проблему

weko рельный RTO в 2 раза меньше

orignal нашел проблему с netdb

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

weko HandleResendTimer срабатывает раз в RTO ms. в в нём мы смотрим все пакеты что привысили RTO. итого какой то пакет, который привысил RTO ровно после того, как сработала функция, будет ждать следущего срабатывания функции

orignal ну сделай с дельтой

orignal делов то

weko в итоге реальное время перепосылки пакета не RTO а в среднем 1.5 RTO

weko orignal: просто чаще надо чтобы функция работала

weko я сделал в 10 раз чаще

orignal ну сделай

weko ща посмотрим как отработает

weko orignal: а где тот буфер, который используется, когда транспорт забит

orignal в Transports.h в Peer

weko оно ?

weko const int MAX_NUM_DELAYED_MESSAGES = 150;

orignal и в NTCP2.h и в SSU2Session.h есть

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

weko ну это смысл разве есть?

weko ну если пока ждёт то на готовое не влияет

orignal ну пришло сообщение пока соединяемся они копятся

orignal на существуеющее нет но там свои очереди

weko на каждом транспорте своя очередь?

weko ну в том смысле что в каждом из 2

weko SSU2_MAX_OUTGOING_QUEUE_SIZE

weko оно?

orignal в каждой сессии

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

orignal да

weko NTCP2_MAX_OUTGOING_QUEUE_SIZE

weko и вот тут

orignal именно

orignal надо будет в TransportSession.h вынести

weko моя теория что 500 это дохуя

weko что это мешает алгоритму определения окна

orignal чем оно мешает?

weko тем что оно копится в буфере, сессия думает что пакеты успевают проходить а по факту они копятся

orignal не думает

orignal на окно оно никак не влияет

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

weko целевого значения

weko ну и потери пакетов это соответсвенно сильный лаг

weko что плохо

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

weko сделал буферы 5

orignal не думаю что поможет со скорость

weko со скоростью нет

weko алгоритму поможет

weko и не будет лагов

weko ну по крайней мере по этой причине

weko надо чтобы если транспорт не справляется то сообщение честно дропалось сразу

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

orignal если просто спайк?

Vort ещё же про баг с оценкой RTT помните? )

Vort про то, что хаотичными изменениями в этом месте (congestion control) можно запросто сделать хуже - я уверен

weko ну вот предидущий вариант который у меня был явно лучше

Vort явно? представляешь хоть сколько вообще разнообразных сценариев работы сети существует?

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

weko вариантов то может быть и много

weko но основной один

orignal потому я и забил

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

weko Vort: с окном ситуация вполне ясная

weko больше потерь - меньше окно. меньше потерь - больше окно

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

orignal можно

orignal но некому

weko orignal: а я чем занимаюсь?

weko Vort: если выкинуть все не нужные моменты то можно

orignal ну вот да

orignal я говорю что мне некогда

weko я ещё кое что понял

weko ещё одну проблему

weko щас

weko отправка новой порции данных идёт сразу же как только очищается пакет из окна?

weko orignal:

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

weko вот а очищается окна только когда приходит ACK при чём пачкой

weko из окна*

weko соответсвенно и отправляется пачкой

weko если эта пачка не вмещается в буфер транспорта, то всё что не влезло дропается

orignal почему? по одному

orignal пришел Ack допустим 5 пакетов

orignal 5 сообщений и отправится

orignal если они есть

weko одновременно

orignal да

orignal а что такого?

weko вот а если пришёл ack 100

weko на 100 сообщений

weko мы отправляем 100 сообщений следующих

orignal именно так

weko но в буфер забит 470/500. итого 70 пакетов дропаются

orignal он чтобы пришел ack на 100 враз

orignal мы должны были отправить 100 раньше

orignal почему дропается?

weko и мы узнаем что пакет дропнулся только через RTT ms

orignal отправили 100

weko orignal: потому что в буфер не влезает

orignal в буфере осталось 370

weko в буфер транспорта

weko нет именно транспорта

weko который на 500

orignal я не понимаю логики

orignal причем тут Ack?

weko потому что мы отправляет ровно тогда, когда Ack приходит

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

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

weko отправляем*

weko да

weko ну когда нагрузка максимальная окно всегда забито

orignal если у тебя придит быстрее чем ты отравляешь то все пиздец

orignal не справляется линк

weko ща давай распишу полностью сразу

orignal че тут поделаешь только в профайл писать что линк говно

weko нет тут проблема не в линке

weko он то тут как раз нормальный

weko надо только чтобы он полностью использовался

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

weko плохо не копить в очереди

weko хотя это тоже

weko я щас распишу

weko линк умеет 1 MB/s

weko постепенно увеличивая окно мы достигаем момента, когда именно столько и шлётся.

weko но так как мы точно не знаем какая скорость, мы постепенно увеличиваем окно

weko в итоге мы начинаем слать больше, чем вывозит транспорт и сообщения копятся в буфере транспорта

weko в итоге в какой то момент приходит ACK, предположим, на 100 сообщений. но буфер транспорта вместит ещё всего только 10 сообщений

weko но мы шлём всё одновременно, не зная, что буфер забит, в итоге влезает 10, остальные 90 дропаются.

weko потом, когда эти 90 пакетов не приходит, нам приходит ACK говорящий о больших потерях, мы сильно режем окно из-за этого.

weko и так по циклу

weko при чём может повезти что дропнется 99 из них, а может 1. и лаг будет разного уровня

weko что я и наблюдал

weko я считаю проблема здесь то, что мы всё одновременно отправляем

weko orignal: раз в сколько отпраляется ACK?

orignal на каждое

weko на каждое сообщение?

orignal а как Ack придет на 100 если в буфер лезет только 10 я этого не понимаю

orignal ну да пришло мы отправляем Ack

orignal на самом нет

weko orignal: потому что до этого в буфер влезло всё

orignal мы выбираем из применого буфера всю пачку и на них один

orignal так вряд ли придет сращу на 100э

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

weko orignal: при высокой скорости передачи будет больше

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

weko ну у нас окно большое

weko 500-1000

weko потому что скорость большая и большой пинг

orignal реально оно сколько? вряд ли 512

weko наврал

weko вроде где-то 200

weko ну в идеале должно быть 250, но оно не успевало дорасти

weko но это учти что одно сообщения стриминга это 4 I2NP сообщения

weko хотя это точно не знаю

weko MTU 1730

weko но const size_t MAX_PACKET_SIZE = 4096;

orignal 4096 не обрщай внимние

orignal там из-за фрагментов

weko короче моё мнение что проблема в том что сообщения после ACK одновременно шлются

weko в итоге импульсы получаются

weko вместо равномерной отправки

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

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

weko формула window * rtt / 2,

weko ой блять

weko не то

weko window / rtt / 2

weko это количество ms

weko делить на 2 не надо

weko мы должны отправить window сообщений за RTT времени

weko да

weko тогда просто qindow / RTT

weko windows*

weko ,kznm

weko блять

weko понятно короче

orignal ну можно да

weko m_RTT = routingPath->rtt;

weko а не лучше вычитать таймстампы?

orignal это же в стримине уже

orignal тут лругой смысл

weko а ну тогда окей

orignal что RTT для всех соединений одинаков

weko понял

weko а зачем это при отправке пакета? при чём в SendPackets нету этого

weko m_IsAckSendScheduled = false;

weko m_AckSendTimer.cancel ();

weko и при том SendPacket использует SendPackets

weko auto ackTimeout = m_RTT/10

weko о нашёл

weko давай я практически проверю

weko orignal: повышу частоту отправки ACK и посмотрим как это повлияет

weko надеюсь я правильно понял где это задаётся

weko if (ackTimeout > m_AckDelay) ackTimeout = m_AckDelay;

weko говорит о том, что верно

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

orignal какую багу нашел

orignal пиздец просто

orignal второй запрос роутера неправильно шифровался

orignal ничего вроде страшного но тем не менее

weko orignal: ну короче да скорость дело в этом

weko я повысил частоту отправки ACK и скорость повысилась

weko при том что буферы 5

weko ща ещё быстрее сделаю

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

orignal в конфиге

weko он задаёт максимум

weko повышу обратно буфер, но оставлю частоту отправки. должно получится стабильно большая скорость

weko одна проблема из другой вылезает

weko понятно почему не исправлено

weko но теперь вроде понятно что нужно

orignal вот с netdb там вообще жесть

weko охотно верю )

orignal скоро закоммичу охуеешь от изменений ))

orignal залил

orignal до существа вопрос еще не добрался )))

weko я всё сижу тестирую

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

orignal следующие запросы всегда ломились через тоннели зачем то

orignal причем без шифрования

orignal в общем мрак

weko а я в замешательстве пока что

weko что-то я упускаю

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

weko нет ощущение что какой внешний фактор

weko который не ш2з