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

onon А, сообщения же в два пакета рассовываются да?

onon Погрепай свои логи на предмет наличия "exceeds 500"

orignal а зачем?

onon На нагруженном узле видно, что это происходит довольно часто.

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

orignal ну и что с этим делать?

onon Я пока не знаю

onon Вдруг мой поток сознания натолкнёт тебя на умную мысль.

onon И ты сразу всё починишь.

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

Vort "<onon> На нагруженном узле видно, что это происходит довольно часто." сколько раз в час?

Vort "<~orignal> ну так понятно что канал на той стороне и проц там не спрвляетсчя" про это я уже писал. я не прав?

Vort <Vort> сейчас считается, что большое количество сообщений в очереди - это признак перегрузки узла. но есть ещё один сценарий - высокоскоростная связь с высоким пингом - для неё большое количество пакетов "в полёте" - естественное состоя

Vort ние

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

Vort 2. если дропнуть сессию, то разве после её пересоздания проц и сеть не будут точно так же не справляться?

onon1 Vort: сколько раз в час?

onon1 Я насчитал за 24 часа 1697, т.е. ~70 в час, при этом: из них 20 это NTCP2, остальное SSU2. Если с NTCP2 это единичные или парные случаи, то с SSU2 это бывают довольно длинные серии.

onon1 На эти 1697 случаев, всего 27 уникальных хостов.

Vort многовато, согласен

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

Vort надо будет проверить

onon1 Я тут вообще вычитал, что UDP сильно больше жрёт процессор, чем TCP

Vort ну об этом давно в этом чате говорим

Vort ничего тут не поделаешь

Vort лишь бы не было глюков

Vort продолжил тестирование стримов и на вот такой глюк попал: Destination: Remote LeaseSet expired / Streaming: LeaseSet ... expired / Streaming: Remote LeaseSet not found / Streaming: Remote lease is not available, sSID=... / Streaming: LeaseSet ... not found

Vort перед этим было полно "Streaming: Another remote lease has been selected for stream with rSID=..."

Vort довольно неплохо такой сценарий вопроизводится, кстати

Vort тест через три узла, на SSU2 и 2 мегабайтах/сек в оба направления (TCP [стрим] пинг по сути)

onon1 Да, по стримам есть проблема, в случае, если клиент не смог отправить серверу свой новый лизсет, а сервер перестроил входящие туннели, клиент так и пытается отправить свой лизсет в эти старые туннели. Бесконечно.

onon1 Хотя надо бы через какое-то время перезапрость у флудфила, или отвальтся с ошибкой.

Vort как думаешь - может ли эта проблема вылазить из-за "Another remote lease has been selected" ?

Vort может, там гонка в таком случае или что-то в этом роде

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

Vort SSU2 начинает дропать что ли?

onon1 Ну, у него с исходящими случилась временная проблема, не смог

onon1 А потом перестроились туннели, и он пытается, но не туда.

Vort только вот туннели я строю через локальный узел

Vort возможно он в перегрузку по трафику уходит

onon1 А Another remote lease has been selected это он пытается выбрать другой входящий туннель сервера из пула. Если я пправильно понял

Vort и отклоняет новые туннели

onon1 А там перестроились уже туннели

onon1 Погрепай логи на предмет отвала транспортов из-за переполнения очереди.

Vort да я уже увидел перегруз по трафику

Vort E флаг грубо говоря

Vort транзит же неверно считается, да? ты говорил об этом

onon1 Это если выходной и входящий концы туннеля на одном узле.

Vort так у меня и настроено

onon1 Он два раза этот трафик считает

Vort Transit: 11197.52 KiB/s получается

Vort вот этой штукой, кстати, тесты делаю сейчас: github.com/wxiaoguang/echoping

Vort только пришлось её починить под новый компилятор и под винду

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

Guest24445 а вот ориньяля я спросил какой приоритетный софт он ответил чтото навроде "мессенжеры , чаты, но не соцсети"

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

Guest24445 чтоб очень динамично соцсеть жила и хитровымудрено, както около того

Vort что юзерам надо - то и делать будут, при чём тут именно i2pd?

Vort сделал отдельный третий узел - ошибок с LeaseSet expired больше не вижу

Vort но вот зависания стрима есть

Vort и кажется мне, что "Streaming: Another remote lease has been selected" таки виноват

Vort может, проблема проявляется, когда обе стороны одновременно выбирают "другой" лизсет?

onon Он же пытается выбрать другой лизсет, если не получил подтверждения о получении сообщения от другой стороны.

onon Значит она не успела отправить, а это потому, что у неё криво считается RTT и RTO

onon Я уже писал об этом.

Vort это понятно. но так как quantity = 1 - то выбирается всё та же пара

Vort вопрос, почему это приводит к зависанию секунд на 8

onon m_NumResendAttempts++;

onon m_RTO *= 2;

onon Вероятно поэтому

onon Но я не уверен

Vort одно из проявлений проблемы: Streaming: Missing messages on sSID=...: from 119361 to 119361

Vort начались сообщения [09/Mar/2024:13:37:30 +0200]

Vort закончились [09/Mar/2024:13:37:39 +0200]

Vort Streaming: Missing messages on sSID=...: from 119361 to 136441

Vort вопрос в том, как можно не перепослать одно потерянное сообщение и продолжать делать отпарвки (17080 сообщений)

onon У меня тот же вопрос, но я пока ответа не нашел.

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

Vort то есть, похоже, потеряли потерю

onon Оправитель в любом случае, не получив подтверждения, должен переотправлять

onon Или вывалиться с ошибкой

Vort понятно. значит, case 2: m_RTO = INITIAL_RTO; влияет

Vort но есть же и nack`и? я плохо разбирался ещё в этом, правда

onon наск должен был отправить клиент, потеряв сообщение 119361

onon И получив наск, отправитель, переотправляет сообщение

Vort потеряли nack что ли? )

onon Вполне возможно

onon Так как его доставка не контролируется

Vort и ждём 8 сек INITIAL_RTO...

onon Вроде того.

onon Я уже предлагал слать аски на аски

onon Всмысле на пакет с асками

onon Но если мы по таймауту перепосылали, клиент потом должен получить либо пачку дубликатов, либо нерасшифровываемых сообщений, если тегов нет уже.

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

Guest24445 рела до кода

Vort Guest24445: i2pd не должен влиять напрямую на экосистему. его задача - предоставление инструментов для построения экосистемы

Vort а само построение - это дело юзеров

Vort для i2pd важно предоставить надёжность и, по возможности, скорость

Vort onon: в общем, у меня подозрение, что стримы могут плохо воспринимать потери сообщений. надо будет какой-нибудь if (rand()%100==0) drop() воткнуть в код узла и посмотреть, какие скорости получится выжать из стримов

Vort проверить на разных процентах потерь - допустим, 0.1%, 1%, 5%

Vort SSU2 (UDP) дропает, Java дропает - а может ли стрим это адекватно "переварить" ?

orignal сообщения в очереди это признак перегрузки линков

Vort orignal: разве большой поток данных при большом пинге не будет давать очередь?

Vort допустим, он не займёт всю полосу. ну а пинг - просто из-за географии

Vort это нельзя назвать перегрузкой - обычный режим работы

onon1 Мне кажется, перегрузки линков == будет давать очередь

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

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

orignal будет но вряд ли очередь будет сильно большой

onon1 Не понятно, если пинг большой, RTT будет большой

Vort допустим, 2 мегабайта/сек при пинге в 100мс. какой размер очереди будет?

orignal 2 мегабайта в секунаду это 2 килобайта в миллисекунда

orignal значит размер очереди 200 килобайт

Vort ну вот, это уже близко к лимитам

Vort при том, что 2 мегабайта/сек и 100мс - это вполне реальные значения

orignal то есть мы отправили 200 килобайт и при пинге в 100 миллисекунд они на пути к адресату

Vort допустим, у такого линка 100 мегабит/сек. он и 11 мегабайт/сек может выдать. это нагрузка ~20%

Vort до перегрузки далеко

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

Guest24445 <Vort> Guest24445: i2pd не должен влиять напрямую на экосистему. - вы ошибаетесь. скажем то что опции в текстовике а не сериализуются при изменениях в файл - это плохо для всяких популярных приложений. к этому и зреет тот патч

Guest24445 и да. это дискуссионная тема, а не догма - сериализация с записью в файл

Guest24445 тут главное удовлетворить всех основных кодеров проекта

Guest24445 и не испортить и2пд

Guest24445 я гипнозис

onon1 Vort, сделай пока хотя бы дроп сообщений при переполнении очереди на транспортах.

onon1 Потому что это одна из причин банов роутеров, а это уменьшает связность.

onon1 А если флудфил всех начнёт банить...

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

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

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

Vort мне сам по себе лимит не нравится

Vort он ведь для чего? чтобы старьё не набивалось?

orignal чтобы все ресурсы не отожрало

Vort ну это довольно легко решить

orignal на самом деле это единственная причина

Vort сделать, допустим, лимит по времени - на 20 секунд. за 20 сек туда в принципе много не набьётся. для 100 мегабитной сети - это 11*20 = 220 мегабайт

orignal 20 секунд чего?

orignal сообщания в очереди?

Vort макс. время лежания сообщения в очереди

orignal а почему именно 20?

onon1 20 это дофига

Vort а дальше - или сессию дропать или сообщение - это ещё думать надо

onon1 1сек на у зел может

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

Vort orignal: я смотрю по пингам туннелей - там часто бывает 5 сек. значит, на пару туннелей - 10 сек. ну и запас небольшой

Vort плюс иногда же лежат сообщения ещё до установки сессии

orignal может как то по пингу пира считать?

Vort то есть, если устанавливается долго - это тоже надо как-то учесть

orignal мы же его измеряем

Vort onon1: сеть намного тормознее, к сожалению. ответы по 10 сек - обычное явление

onon1 Если у тебя 4+4 хопа и на каждом будут висеть по 20 сек - нафиг такое надо.

Vort а, не подумал, что это на каждый хоп

Vort ну тогда можно и 5 сек поставить

onon1 5 тоже дофига

Vort onon1: так сообщения же могут и без сессии лежать в очереди, вроде бы

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

onon1 Так если они там лежат дольше, скорее всего они уже никому не нужны

onon1 Заново переотправить нужно

Vort onon1: это слишком масштабные изменения

Vort сейчас надо не доломать то, что и так глючит

orignal без сесии там другая очередь

Vort а, ну тогда проще

orignal она в Peer в транспортах

Vort тогда и 2 секунды лимита может хватит

Vort 2 секунды нет движения в очереди - дропать сессию

onon1 А про 220 мегабайт ты так не шути, у некоторых вся оперативка 512 мб

Vort onon1: а зачем им тогда 100мегабитная сеть? :)

orignal у меня там где баунсер 512

orignal там 10 гиг я думаю сеть

orignal впс же

Vort ок. но всё равно разобрались, что так долго ждать не надо

orignal да идея дропать по времни хорошая

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

Vort хотя тут два условия можно сделать

Vort нет движения N секунд - дропать сессию. самое старое сообщение в очереди больше M секунд там висит - дропать сообщения

Vort нет движения при наличии пакетов в очереди* конечно же

orignal именно так

relaybot 13mittwerkz: orignal ты серьезно пользуешься почтой от яндекса?

orignal да

orignal только yandex.com

orignal она у меня со времен когда он еще не скурвился

Vort чем они провинились?

Vort про mail.ru гадости слышал, а про yandex пропустил, наверно

orignal все хуйлу сливают

Vort понятно

orignal но .com это маленько другая там другая юрисдикция

onon2 Это получается, у нас один UDP буфер на все наши тысячи SSU2 коннектов?

Vort да

orignal да

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

orignal там где раздают мультикаст там разные физиечские интерфейсы

orignal у нас например с 4-х карт выдается

onon2 Задача усложняется...

Vort так подкрутили же размер

Vort можно ещё докрутить если что

Vort я кстати готовлю эксперимент с просрочкой очереди. ожидаю фейла, а там будет видно )

orignal чем она усложняется?

orignal если ты упираешься в сетевую карту тут ничего не поможет

onon2 Да я тут думаю, как SSU2 поправить, просто больше факторов в виде других SSU2 соединений будут друг на друга влиять.

onon2 Как тут сделать правильно Flow control и Congestion control

onon2 С пасингом вообще беда получается.

Vort попробую тестовую версию на основной узел поставить. на тестовом узле очередь даже до половины лимита не добирается

Vort хех, попадают уже в лог полу-полные очереди. даже с 4 сообщениями в очереди такое бывает )

Vort так как одно из сообщений больше секунды в очереди проболталось

orignal а что поменял то?

Vort определил полупустую очередь не через количество сообщений, а через просрочку

Vort github.com/Vort/i2pd/commit/2d06c0cbe6162d7dcc1dc4f685af3e9e60ed1160

Vort убрал пока что дроп сессии, вполне возможно, он не нужен вообще

Vort полупросрочка - 1 секунда

Vort дроп сообщений при 2 секундном возрасте

Vort меня беспокоят разве что ситуации с VPN`ами и говняным WiFi - чтобы не начали вообще все пакеты дропаться в таких случаях )

Vort ну, теоретически, это можно исправить подкручиванием константы

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

Vort пока что вижу, что лагающие узлы большой очереди и не набирают: за 40 минут аптайма для полупросрочки в 1 сек видел размер очереди максимум в 31 сообщение

Vort смотрю дальше

onon Наверное убирать лимит очереди не совсем хорошо. Если до какого-то узла плохой канал, а для остальных 1000 хороший, и эти 1000 одновременно захотят что-то отправить на тот узел...

onon Получается в худшем случае, (весь наш bw минус bw до медленного узла) умноженный на 2 сек - это будет наш буфер.

Vort это ситуация атаки, и не простой, а хитрой. а результат - выжранные 22 мегабайта RAM (на 100 мегабитном канале)

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

Vort onon: предлагаю потестировать коммит

onon А на что смотреть, и чем нагружать?

onon Если я сервер, у меня тысячи коннектов, и я всем шлю поток, у меня рвется соединение. все тысячи очередей начинают наполняться пакетами, генерируемым мной самим? И сколько я так за две секунды могу сгенерировать?

onon Похоже что так же не много, но я точно не знаю.

Vort 99 сообщений у меня пока что был максимум

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

onon 99 это semiFull?

Vort это по сути от 1 до 2 сек просрочки

Vort на 1 сек начинает писать в лог

Vort на 2 сек дропать

onon Ну я смог дожать до 630

onon Наверное можно больше.

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

Vort onon: это с перегруженным CPU или нет?

onon А я как-то не посмотрел, сейчас перепроверю.

Vort и какая общая скорость (нагрузки) примерно была?

Vort onon: и ещё важный вопрос - выдержали ли такой тест стримы?

onon 1,5-2 мб/с больше почему-то не выжимает, много перепосылок

Vort если ты дожал до 2 секундного лага и пошли дропы, то интересно, что по этому поводу подумали стримы )

onon Но стримы работают, и нагрузка распределяется между ними относительно равномерно.

onon ЦПУ подскакивает до 80-90

onon в среднем 60-70

Vort это именно то ядро, где SSU2 сидит, или общая нагрузка?

onon Два ядра

Vort а какой пинг у туннелей был на начало теста (примерно)?

onon 7

onon во время - 70

Vort откуда ж тогда 1 секунда лага в транспорте берётся. что-то не учтено

onon В один поток тащит гораздо лучше

onon почти в два раза

onon Могу на "рабочий" узел накатить под реальную нагрузку, но это будет долгосрочное тестирование, хотя бы сутки.

onon1 Если у нас UDP буфер заполнен, а мы пытаемся туда пачку пакетов вставить, что будет?

orignal пакеты будут дропаться

onon А мы можем как-то маркировать I2NP сообщения из разных источников?

orignal напаример?

onon Вроде эти - наши с такого-то стрима, а вот эти - транзитные

orignal да это можно

orignal точнее даже сейчас

orignal у наших from будет nullptr

onon А с разных транзитов разные можно сделать?

onon Чтобы один поток был с одним ID

onon Это я над балансировщиком думаю чтобы канал равномернее утилизировать

onon И никого из транзитов сильно не обидеть

orignal тот же from

orignal но всегда

orignal *не

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

orignal не проблема

onon Это хорошо.

onon Их нужно будет равномерно в буфер UDP пихать, поровну из каждого источника.

onon Отдавая приоритет своим пакетам, естественно.

orignal дед говорил у них есть балансироващик типа такого

orignal по типу сообщений