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

weko const size_t MAX_PENDING_INCOMING_BACKLOG = 256;

orignal и че?

weko да я просто думаю что слишшшком мало было и потому стрим вис

weko не хватало

weko orignal: а ещё мне кажется RTO неверно считался

weko но пока точно не уверен

orignal возмодно

weko там короче на 1.5 умножалось

weko в ssu2 например тоже 1.8

weko я поставил тоже 1.8

weko 99598579:me ⇒ guGx ⇒ C2ME ⇒ iFIi ⇒ ( 245ms ) expiring, 17179869182.63 GiB

weko 0_0

weko без комментариев...

orignal переполнилось

orignal где то

weko потери даже 0.1% сильно скорость режут

weko что понятно учитывая что через 7 транспортов проходит

weko не знаю у меня вроде вышло стабильно сделать

weko не уверен что вообще нету зависаний

orignal ну посмотрим

weko MAX_PENDING_INCOMING_BACKLOG должен быть минимум в 2 раза больше чем MAX_WINDOW_SIZE, выходит

weko а может и более

weko ну или я туплю уже и несу бред

orignal это же не про то

orignal этот backlog он про входящие соединения для которых нет аукпторов

weko аукпторов?

weko чо это

orignal ацепторов

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

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

weko так а что тогда про буфер "сбора" информации ?

weko если не это

orignal там другой

orignal он безразмерный для стримов

weko а ну тогда не в этом проблема

orignal SendBufferQueue m_SendBuffer;

orignal вот этот для отправки

weko я про получение

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

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

weko буфер транспортов кстати вроде уменьшать как раз не надо. хотя это можно будет проверить, когда будет сделана отправка пакетов постепеннная

weko сделаю разгон быстрее

orignal Tunnel creation success rate: 46

orignal весьма неплохо

weko уже очень долго ничего не висло

orignal я тут с netdb играюсь

weko хорошо

orignal осталось последний шаг слелать

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

weko только вот что

weko мне не понятно откужа потери идут

weko из-за которых тут увеличиться не может скорость

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

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

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

orignal а сразу дипазонами

weko ну правильно

orignal потому любой пропущенный пакет сразу портит всю картину

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

weko у меня режется окно на 20% если хоть один пакет считается пропущенным

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

orignal да это так и должно быть

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

weko зачем кстати если пропущенные пакет умножать RTO на 2?

orignal ну такой код был

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

orignal мне так дед с болгарином сказали

weko да в коде это есть зачем не знаю

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

orignal мне сказали

weko ну короче что ты сказал не объясняет откуда потеря

orignal оно объясняет замедление

orignal а вот потери явно где то баг

orignal с подтверждениями

orignal его нет в ветке когда потерь нет

orignal и если когда формируеются диапазоны

weko NTCP2 может куда больше я думаю

orignal неее

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

orignal там же TCP

weko нет я про скорость

weko NTCP2 точно может больше скорость дать

orignal а что там то можно изменить?

orignal там и так все отптмально

weko ну да

weko может в ACK пакет не влезать всё?

weko или как то баговаться что подтверждение приходит не на всё

orignal а NTCP2 нет никакх ack

weko я про стрим щас

weko стриминг

orignal а стрим это вообще костыль на костыле

weko ну это видно

weko но я главное вроде сделал

weko проверить только надо в основной сети

orignal ну если все сильно лучше давай PR делать

orignal именно там и надо

weko orignal: я бы там много даже на своём уровне плюсов потрагать. просто боюсь всё сломать

orignal ну сломаешь починим

orignal не надо бояться поломать

orignal до релиза еще додго

weko надо просто ветку отдельную

weko orignal: я мало того что могу сломать, могу после этого не понять

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

weko orignal: почему именно так проиходит не знаю,но я вместо пинга 10-100 ms поставил 54-56ms и скорость пошла

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

weko в реальной сети обычно не так

weko видимо TCP от таких скачков пинга плохо

weko 6 MB/s

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

weko и главное - не виснет

weko я думаю помогла замена 1.5 на 1.8

weko ахаххахах))

weko только я сказал, что не виснет

weko так оно зависло

weko 588846123:me ⇒ PM-y ⇒ 2Up8 ⇒ 0IOg ⇒ ( 218ms ) established, 17179869182.72 GiB

weko и опять

weko походу это связано

orignal надо смотреть как там считается

weko ну там просто счётчик нет?

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

orignal хаген что то накосячил

weko а ну может

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

orignal в каком смысле?

orignal не вызывается совсем?

weko да

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

weko всегда

weko а у меня не меняетяс

weko всё сдох стрим

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

orignal чтобы понять вызывается или нет

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

weko тут по коду окно должно меняется при вызове

orignal не может такого быть

weko а оно не меняется

weko я вижу же в панели

orignal так окно не меняется и не вызывается функция это не одно и то же

weko в моём случае одно и тоже

weko потому что код в котором оно меняется у меня сейчас только там

weko и менятся оно при каждом вызове

orignal ну так надо понять почему

orignal что вообще происхдит

weko ну либо цикл слетает либо большое RTO

orignal if (resentPacketsNum > SSU2_MAX_RESEND_PACKETS) break;

orignal например вот здесь

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

weko все отправляются что считаются пропавшими

orignal void SSU2Server::HandleResendTimer (const boost::system::error_code& ecode)

orignal надо начинать отсюда

weko так я то не ssu2 смотри а стриминг

weko смотрю*

orignal а ну понял

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

orignal просто SSU2 я делал недавно в стримы давно

weko нельзя готовую реализацию TCP алгоритмов было использовать? ))

orignal она не такая как стримы

orignal это вопрос не ко мне

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

orignal диспесия ))

orignal это же средкадратичное отколнение от матожидания

orignal или ты о чем то другом?

weko Да об этом

weko Просто когда она большая тогда пики есть

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

Vort полагаю, по такой теме могут быть даже книжки написаны

Vort без чётких тестов что-то самодельное реализовывать рискованно

weko Ну я любитель велосипедов

weko Ну не делать, а придумывать)

weko есть у кого то код на плюсах для определения i2pd/i2pj ?

orignal нету

orignal там надо поле cost у адресов смотреть

weko ща посмотрб смогу ли сфарганить

weko что за херня

weko std::shared_ptr<const i2p::data::RouterInfo> TunnelPool::SelectNextHop (std::shared_ptr<const i2p::data::RouterInfo> prevHop,

weko bool reverse, bool endpoint) const

weko {

weko auto hop = IsExploratory () ? i2p::data::netdb.GetRandomRouter (prevHop, reverse, endpoint):

weko i2p::data::netdb.GetHighBandwidthRandomRouter (prevHop, reverse, endpoint);

weko if (!hop || hop->GetProfile ()->IsBad ())

weko hop = i2p::data::netdb.GetRandomRouter (prevHop, reverse, endpoint);

weko return hop;

weko }

weko почему если случайно попался роутер с плохим профилем, то мы не берём снова нормальный

weko GetHighBandwidthRandomRouter нормальный в этом смысле

orignal потому что это значит что мы хороший не нашли

orignal и берем какой есть

weko тоесть они все плохие?

orignal нет

orignal мы снала пытаемся хороший

orignal если не нашелся то тогда какой попало

weko вообще желательно отдельный индекс иметь

weko в котором будут хорошие роутеры

orignal а если их сосвсем не будет потому что плохой ты?

weko когда индекс слишком маленький тогда брать иногда плохие

weko я говорил уже про эту штуку, типо какой целевой процент от базы используется при построении туннелей

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

weko и чтобы можно было в конфиге задать

weko в идеале профилирование должно рейтинг составлять и чтобы брался заданный процент сверху топа

weko кстати интересно что тогда при атаке на ш2з атакующие повысят стабильность и скорость и после придёт юзеры, ослабив атаку ))

weko придёт*

weko придут*

weko пиздец долно хотя бы один исходящий туннель создавался

weko просто полный пиздей

weko пиздец

weko 300 KB/s вполне себе даёт

weko думаю упор в SSU2

orignal именно там

weko но всё равно иногда скорость сильно провисает

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

weko лол

weko по туннелю идут данные, но он помечается failed и удаляется

weko заебок

orignal значит не проходят тесты

orignal то что они идут не факт что доходят

weko это входящий туннель

weko оно как бы точно доходит

weko ну и всё вот попались полное гавно туннели и скорости нехия

orignal я вроде фиксил это

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

weko orignal: ну я своими глазами в панели видел

orignal надо разбираться

weko мне кажется там вообще очень многое неправильно

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

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

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

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

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

weko ну ладно если бы она была 300 и чтобы всегда была 300

orignal на каждой сообщение post в тред и все

weko а не когда то 300 а когда то 10

weko orignal: вот я это не умею

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

weko 1 пакет за раз

orignal не будет все время медленно?

weko ну типо что постоянные переключения

weko мб

weko ща

weko MIN_WINDOW_SIZE

weko столько

weko на самом деле я не уверен

weko orignal: надо повысить скорость создания своих туннелей. жду тыщу лет пока создадутся

weko хотя бы 1 чтобы работало

weko даже 1 жду кучу времени

tetrimer Это при старте i2pd?

weko да

weko да и во время работы

weko тоже не хватает

tetrimer У нас тоже коллеги замечают, что 2.50 и дальше - медленно набирают туннели.

tetrimer Хотим попробовать экспорт netDB с рабочего экземпляра i2pd

weko хз поможет ли

tetrimer Попробуем.

weko только косвенно повышением tcsr

weko хотя повысится ли - вопрос

tetrimer Я бы ещё при старте сделал уменьшение хопов. Но будет ли такое работать в динамике - вопрос...

weko Tunnel creation success rate: 15% - пиздец

tetrimer Так это вопрос из серии "как посчитать". А вот то, что роутеров не набирает - это проблема.

weko совсем мало?

tetrimer Потому что нет роутеров - нет туннелей, нет туннелей - нет новых роутеров.

tetrimer На свежеустановленном - бывает совсем мало.

weko а терь походу вообще клиентский туннель на порт не повесился

weko стрим не сохдаётся даже

weko Routers: 19808 ))

weko ура создался

tetrimer А в логе при этом no buffer space чего-то там?

weko он тупо не создавался

weko логи хз

weko щас работает

tetrimer Где-то порог отстрела туннелей по качеству слишком высокий

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

weko она не перегружена

weko держу в курсе

weko перегружена это когда у всех скорость в лимит забита

weko вот это загружена

weko ntcp2 only не помог ))

Vort лимит - это произвольное значение, выбранное юзером

weko Vort: ну да

weko и что?

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

weko я вот X поставлю и весь мой порт не забьётся

weko Vort: ну не может

Vort или по каким-то направлениям перегружена, а по каким-то - нет

weko если CPU есть память есть порт не забит то не перегружена

Vort в одну страну канал может быть перегружен, в другую - нет

tetrimer Для начала работы - нам нужна минимальная информация о сети. Где ее брать, если туннели не создаются?

weko Vort: ну значит все роутеры из этой страны считаются перегруженами

Vort опять с выводами спешишь

weko если количество не перегруженных роутеров > 1 значит сеть не перегружена

tetrimer У кого есть список роутеров из этой страны?

tetrimer У флудфилов, я так понимаю...

Vort tetrimer: запуск с нуля - это должен быть редкий сценарий. зачем на него обращать особое внимание?

weko сеть перегружена когда всегда во что-то упираешься

tetrimer Да ну какой "редкий", когда у нас это происходит раз в неделю...

weko Vort: с ресида

weko ой

weko tetrimer: с ресида

weko а туннели создавать надо быстрее это да

Vort tetrimer: из-за долгого оффлайна что ли?

Vort ну и да, ресиды же есть

Vort и какой-то из 300 (вроде) узлов с ресида явно должен работать нормально

weko не 300

weko а 25 вроде

tetrimer В том числе.. Да и просто ставим софт кому-то.

Vort информация о сети случаем не двуххоповыми зондирующими туннелями получается?

Vort 2 хопа более-менее нормально строятся

weko если вообще строятся

weko а не тупят

tetrimer В начале - тупит пир-тест.

weko orignal: короче 100% вывод пока что 128 максимальное окно не хватает. надо 512 минимум

weko а то и 1024

weko потому что я сейчас в основной сети и тут окно 200-250

weko не зависимо от того какой алгоритм

weko ну всё, хороший туннель кончился (

orignal 128 для стимов?

weko да

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

orignal скорость создания тоннелей да надо н

orignal но надо чтобы не банили

weko так тут транзит в основном

tetrimer А чтобы не банили - надо туннели в разные стороны создавать.

weko Чего?

weko чего-чего?

tetrimer Ну, типа, банят джава узлы за частое создание

orignal естестественно через разные

tetrimer А как они получают информацию о частом создании?

orignal но это надо сделать

orignal много запросов идет

orignal ладно починю

tetrimer Много запросов на один узел?

weko ну количество TMB с одного ip

weko например

weko за какое то время

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

tetrimer Потому ч и говорю: надо при старте какой то алгоритм ускоренного набора узлов

weko не проверяя сколько реально надо

orignal да я займусь этим

weko так ну мой вывод что текущая реализация стриминга - полная хуйня

weko :)

tetrimer Судя по работе андроид приложения, у которого укороченные туннели по-умолчанию - надо на старте делать два хопа вместо трех

weko ладно не совсем

tetrimer А потом - увеличивать. Если алгоритм позволяет.

weko так много устройств где ставишь ш2зв?

tetrimer Сносят периодически. :)

weko хто

weko юзвери?

orignal да число хопов можно менять

Vort tetrimer: пир тест баганутый, да

orignal да тут все багнутое

tetrimer Vort: тут ещё вопрос - а нужен ли пир тест тем, кто гарантированно сидит за натом?

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

tetrimer Вот. А как это форсировать?

weko не знаю вроде константа есть

Vort tetrimer: большинство юзеров и слов таких не знает. а те, кто знают, могут ошибаться. проще проверять в общем. да и трафик это мизерный

weko можно просто ускорить но лучше только когда мало в баще

weko базе*

Vort weko: а так вроде и должно быть по коду

weko Vort: в идеале на U должно быть много трафика

weko на хорошем U

tetrimer Трафик - да, время ожидания - вот главный раздражитель.

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

Vort потому что с поломанным пир тестом нормально U узлы не заработают

weko Vort: нужно. ещё нужно починить SSU2, стриминг, сделать профилирование

weko и что из этого приоритетнее - ХЗ

Vort то, что проще протестировать

weko SSU2 просто проверить

weko а профилирование сложнее всего

weko хотя зависит от того что нужно для починки остального

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

weko если например буфер на 25% заполнился

weko в итоге владелец корректирует скорость отправки

weko в итоге потери пакетов нет и нету подлагов из-за этого

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

weko это для исходящего туннеля. а для входящего надо подумать

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

weko orignal: я просто считаю что определять скорость через потери неверно

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

weko для стриминга

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

weko ну вот неверно это

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

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

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

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

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

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

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

weko но с таким алгоритмом этот момент будет позже

weko кстати я понял почему у меня нет проблемы обычно с скоростью построения туннелей

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

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

weko долгие при чём

weko orignal: SSU2 же не пытается восстанавливать порядок I2NP сообщений?

orignal нет и не должно

orignal но порядок фрагментов одного восстаналивает

weko <orignal> нет и не должно

weko да просто убедится

orignal в том и была концепция SSU2

orignal поскольку там не надо гарантировать последовательность то считалось что может работать быстрее NTCP2

weko просто думаю как это всё может влияет

weko влиять*