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

weko orignal: транзиты не надо ограничивать глобально. Во первых, это тоже самое, что лимит туннелей, потому что у туннелей конкретный срок жизни, 10 минут, значит лимит уже <лимит>/600, тоесть сейчас максимум в среднем(!) 109 запросов в секунду.

weko Делать ограничения в секунду - тоже самое, только вид сбоку. И будет хуже, потому что это будет не среднее ограничений. Иногда есть мелкие пики засчёт случайностей и их банить не надо. Во-вторых, лимиты должны понижать те, для кого

weko проблема такое количество транзитов, а именно джава роутеры, i2pd же тянет столько? Тянет. И вытянет в 5 раз больше, а у джавы пусть и остаётся жёсткий лимит, раз они не тянут. В-третьих, лимит нужно делать отдельно на каждый адрес, чтобы

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

weko В любом случае глобальный лимит смысла не имеет

weko 109 это 65535/600

weko Если что

weko Vort: до коммита у меня разница максимум 15% в обе стороны, сейчас обновлю буду смотреть

Vort у меня сейчас NTCP2 ( 2328 ) SSU2 ( 1336 )

Vort аптайм 10 часов

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

weko orignal: не я согласен что нужно лимитировать транзиты ну хотя бы до 2мбит/с. Тут Vort кидал транзит на 1.7 гигабайта (!!!), вообще хрень какая-то. Думаю нужен лимит 2 или 3 мбит/с

Vort жаловались всё время, что скорость в сети маленькая, а теперь когда большая - тоже не нравится? )

Vort общий лимит на скорость есть - и хорошо

weko R4SAS: да, основная проблема i2pd что он слишком быстрый и может делать транзит на 50мбит/с ))))))

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

weko 1. Лимит на количество туннелей. Смотреть сумму inbound.quantity , outbound.quantity на всех destination, если при создании очередного destination этот лимит превышен, то выдавать ошибку. Считать именно туннели, потому что имеет значение сколько их на каждом

weko destination, по 2 штуки или 32 (с 32 можно создать меньше , чем с 2, при равной нагрузке). Это нужно чтобы программы с багами или просто некорректной работой не грузили сеть просто так (с шансом 99% пользователь не планировал ложить сеть, а просто

weko наткнулся на багу в программе)

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

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

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

weko Ограничить транзитный трафик на один туннель до предположим 2 или 3 мбит/с. Ты и сам кидал туннель на 1.7 гигов.

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

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

weko Vort: ну 23мбит/с на туннель не норма, лучше другим туннелям по 1мбит/с достанется. Да лимит ограничивает возможную скорость сети, но нужен чтобы один туннель не использовал всё. Но тут я согласен, наверное я не прав, лучше лимит где то

weko 5мбит/с сделать. Или ещё лучше, сделать чтобы он зависел от глобального при лимитах P, O. Ниже уже пофиг. Например максимум 20% от глобального лимита на 1 транзит

weko Vort: ну вот я и говорю, что нужно продумать это лучше

weko Что 1 не должен забирать у всех других

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

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

weko Сейчас скорости 2-3 мбит/с или даже 23 мбит/с реальны

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

weko Vort: а если в этот момент ещё придут транзиты с большим трафиком

Vort а уже отключены транзиты

weko Да и 1, который жрёт всю полосу анонимности тебе не делает

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

Vort вот тут хз. может

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

weko Ну если конкретно, то я про возможность тайминг атаки.

weko С один транзитом можно просто отключить его и провести атаку

weko Конечно вероятность мала но она естл

weko Есть*

weko orignal: вот, почитай ещё длинное сообщение выше, пожалуйста.

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

Vort weko: кажется, я понял. проблема с 1 жирным транзитом просто из-за алгоритма лимита, который рубит транзиты

weko Vort: это тоже

Vort не надо их рубить - тогда их и будет много. логика )

weko Но не только

Vort надо именно скорость лимитировать

weko Это понятно

weko Это тоже не правильно, я согласен

weko Но отжирать всю полосу одному транзиту тоже нельзя

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

Vort может, сеть перестанет колбасить и ровнее нагрузка пойдёт

weko Может

weko Но мне кажется проблема в джава роутерах, у них вообще шиза с банами. Так они ещё и медленные

Vort я вот думаю что если делать реальный лимит на скорость, то и i2pd может стать медленным )

weko Но то что ты написал сделать ещё важнее чем лимиты, тут я с тобой согласен

Vort так что это надо делать осторожно, обвешавшись инструментами (профилировщиками) :)

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

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

Vort я имел в виду, что алгонритм лимитирования скорость будет очевидно кушать CPU

Vort и тут надо смотреть, сколько именно

Vort если очень много, то, может, такой лимит тогда и вообще не нужен

weko Vort: да.... Тоже подумал об этом)) но меньше, чем сильное превышение количества трафика))

weko Согласен с тобой

Vort я думаю, плюс процентов 10-20 от нынешней нагрузки CPU было бы норм. ну или меньше ессно

Vort если получится раза в два больше - то упс

Vort а зараннее это не вычислишь

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

Vort но может повезёт

weko Ну там точно не O(n²)

weko Так что слишком много не будет)))

Vort ну я не писал именно такое, поэтому точно сказать не могу

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

Vort а "ждать" - это тоже ресурсы CPU

Vort хотя, может, есть что-то умнее

weko Нет её ждать

weko Ждать не надо

weko Надо дропать

weko Тоесть выкидывать

Vort в NTCP2 такое предусмотрено?

Vort я "пакет" условно сказал

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

weko А при чём тут NTCP2

Vort "лимит был у тех кто отправляет" - так нагрузка - это сумма по всем туннелям. отправляющему ситуация неизвестна

weko Тоесть сначала нужно определится с лимитом и сделать его в релизе джавы и i2pd. Потом через 1-2 релиза, когда процент новых роутеров будет высокий, сделать лимит и для транзита

weko Vort: ты не понял, речь то про лимит на один туннель

weko Нужны конкретные правила. Например 20% для O,P, 5мбит/с X, для остальных лимит не делать

Vort ну я вообще изначально говорил о том, чтобы bandwidth = P работал именно как bandwidth = P, а не как чёрти-что

weko Сначала ввести соблюдение правил для владельцев

weko Потом через 1-2 релиза для транзитов

weko Vort: это тоже

weko Но моё предложение с этим связано

weko С тобой я согласен

weko Что нельзя отклонять туннели когда высокий трафик

Vort про проценты от лимита я тоже думал

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

Vort можно даже 50%. остальное забьётся мелюзгой автоматически

weko Vort: ну я для примерами

Vort угу

weko Примера*

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

Vort то есть, можно подумать над правильной реализацией для общего лимита

Vort а потом расширять на потуннельный

weko Да надо думать

weko Но чтобы раньше это сделать нужно сделать лимит для владельца уже сейчас

weko Что точно много кушать процессора не будет

weko Ибо его мало

weko Трафика владельца

Vort чтобы источник, видя что он шлёт через P туннель, больше мегабайта в сек допустим (50%) туда не пихал?

weko Ну да например

Vort понял

Vort может быть и стоит

weko Вот это будет точно нормальное улучшение

weko Смысла нет пихать 1мбит/с например в роутер где лимит 32

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

weko Ну вообщем понятно

weko Так я рестартую

weko Теперь действительно IP-2 )))))

weko Чейнджлог:

weko i2pd переименован в ip-2d :))))

weko На 1 апреля можно оставить)

weko Transports:

weko NTCP2 ( 2121 )

weko NTCP2v6 ( 21 )

weko SSU2 ( 1569 )

weko )))

R4SAS I/F Name Recv=KB/s Trans=KB/s packin packout insize outsize Peak->Recv Trans

R4SAS eno1 32232.0 34370.9 42564.043889.7 775.4 801.9 37186.2 39371.8

R4SAS PID %CPU ResSize

R4SAS │ 31119 206.2 120548

R4SAS │ 29185 174.9 118828

R4SAS 30559 140.8 135524

R4SAS 30881 152.3 117016

R4SAS CPU User% Sys% Wait% Idle

R4SAS Avg 58.0 29.2 0.2 12.5

R4SAS нормально так

weko Память 2,1 было 3👏

weko В какой то момент было 3.6 даже

weko Дизайн крутой

weko Ой не туда

weko Ладно, уже 2.6 при той же нагрузке, хм

weko Routers: 11282

Vort у меня тоже Routers вверх поползли. раньше было 5-6к, теперь Routers: 9110

Vort ну и Transit Tunnels: 7042. видимо, они сильно связаны

Vort а вот рейт, к сожалению, идёт по-прежнему вниз Tunnel creation success rate: 21%

Vort объём трафика тоже ползёт вверх - 1 мегабайт/сек сейчас, скорее, норма

Vort то есть, ползёт вверх всё. и это очень похоже просто на повышенное использование сети

Vort с памятью и CPU при нынешней нагрузке (той, что я описал выше) всё нормально: 3% и 100 мегабайт

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

Vort но это примерно до задницы

weko 3687.24 KiB/s

weko Tunnel creation success rate: 24%

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

weko Которые поддерживают только его*

weko Наверное

weko Речь про это

orignal ну да есть и такие

weko Вот просто поправил

orignal рейт идет вниз потому что что джава узлы дают отлупы

orignal да Routers связан с транзитом

orignal если конце тоннелей

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

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

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

orignal да вот п 2 разумно

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

weko Это тоже

weko А п.1 -почти тоже самое, что ограничить количество destination (ты же говорил уже про это), только по туннелям считать

weko Тоесть если например программа спамит на SAM много туннелей, то это не норма

weko Чаще всего,вообще-то нету случая когда их нужно будет ну предположим больше 2000

weko Да, наверное лучше ограничить количество попыток создания на SAM, BOB, I2CP

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

orignal по п.1 я собирась ввести параметр в конфиг в секцию limits

orignal с лимитом в 50 дейстинейшинов по умолчанию

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

weko Угу, конфиг

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

Vort 4232.24 KiB/s у меня

Vort кажется, понимаю механизм

Vort может набраться куча неактивных транзитов. затем многие из них активируются

Vort и тут уже хоть блокируй новые, хоть не блокируй

Vort ---

Vort подозрительно как-то прыгает нагрузка CPU у i2pd

Vort ещё и провалы по трафику общесистемные. хрень какая-то

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

Vort я заметил прыжки потребления CPU раз в 5

Vort (провалы - это, наверно, глюки провайдера. а вот за CPU i2pd надо следить)

Traca zzz, checking your last comment on github bitcoin issue, yes raspiblitz will release I2P in the next version

orignal у тебя роутеры идут всегда с концов транзитных тоннелей

zzz Traca, not in current version?

Traca no, not in current version

zzz ok

Traca in my case I added manually

zzz orignal, Traca, I think maybe the problem could happen at startup, especially if i2pd has been down for a while also, and has trouble building tunnels

zzz and probably worse on a Rasp. Pi

Traca you can check it here

Traca github.com/rootzoll/raspiblitz/pull/3330

Traca zzz, it makes sense that it happens at startup and probably worse on a pi4 sure

orignal zzz, no difference between startup and every 10 minutes

orignal you have to build bunch of tunnels at startup and then after each 10 minutes

Traca ok

orignal ofc not simultenously but in short timeframe

zzz true

zzz another reason bitcoin should not create them all at once

orignal based on my expeience with botcoin

orignal they never connect to all peers at the time

Traca the problem is that many projects will add it, it's a matter of time, and most users who will run it won't even check the settings, so bandwitch will be by default which is very low

orignal starts wil one and keeps goring slowely

orignal Traca are you bitcoin developer?

Traca no, I'm not

orignal anyway I can't build bitcoon-qt on ubuntu 18 anymore

Traca why?

orignal it requeres some newer version of qt

orignal that sucks

Traca never tried on ubuntu but I don't have issues in arch based

orignal ubuntu 18.04 has older version of QT that 24 requires

Traca oh ok

orignal bad aproach really

orignal just my opinion

orignal epecially since 18.04 is not eol yet

Traca on raspiblitz they will add with i2pacceptincoming=1

Traca so shouldn't be an issue

zzz I'm just thinking how to reproduce the bitcoin "collapse". Maybe with a new i2pd install, rasp. pi, onlynet=i2p, to make it really hard to build tunnels

Traca but how many rasp would you need to do that?

orignal why do you want to repoduce it?

zzz i2pd will reseed, only know 200 routers, and spam them to death

zzz to confirm my thesis

Vort (to debug it I think)

orignal just create 10 SAM sessions with default settings

zzz sure

Traca know more than 200

zzz but Traca was not able to reproduce

orignal just copy netdb folder

orignal same format

zzz probably because his router was well-integrated

orignal but it's just a bad idea to flood the network in my opinion

zzz I'd like to have i2pd+bitcoin work together to reproduce it

orignal Traca do you run a floodfiill?

orignal repoduce what?

Traca orignal, on desktop yes, on raspberry pi I run X and share 80

orignal Rpi, that's why

Traca admin@192.168.1.36:~ ₿ bitcoin-cli -rpcwait -addrinfo

Traca {

Traca "addresses_known": {

Traca "ipv4": 0,

Traca "ipv6": 0,

Traca "onion": 13484,

Traca "i2p": 580,

Traca "cjdns": 0,

orignal you should try it on a powerfull server with 10K know routers ))

Traca "total": 14064

Traca }

Vort we see lots of transits and don't see where they created

Traca got 580

zzz reproduce "congestion collapse" = tunnel build spam = github.com/bitcoin/bitcoin/issues/26754

Vort it is only part of puzle

Vort that's why reproduction is needed

Vort to see how problem is created

orignal zzz and what do you expect to see?

orignal 500 transits?

Traca and on desktop 575

orignal Transit Tunnels: 12512

zzz near 100% build reject or timeout

orignal Routers: 12747

zzz and very high build requests sent out

zzz this is my theory

orignal that's what you need for a relevant test

zzz this is my bug report

orignal zzz you don't need botcoing for it

zzz this is what I'd like bitcoin and i2pd projects to work together to test, confirm, and fix

Traca orignal, no, 500 known nodes

orignal just simply script with 10 SAM sessions

orignal Traca that's why you can't reproduce

Vort what is needed is to see what is happening at user side

zzz but bitcoin makes it worse because they create new ones on failure too

orignal I still don't undertsand what would you like to fix?

zzz so after, I don't know, 60 seconds, they're creating another

orignal 10 SAM sessions on the same routers?

zzz github.com/bitcoin/bitcoin/issues/26754

orignal please exlain how do you define a "problem"

orignal Traca how many SAM sessions do you see?

zzz they could have 20 or 50 sam sessions if the connection fails

zzz github.com/bitcoin/bitcoin/issues/26754

zzz see the graphs

zzz the network could die this weekend

zzz that's how I define a problem

zzz and it's not my problem

orignal why this weekend?

zzz higher traffic on weekend

Vort I think problem is unusual count of created tunnels. How can 500 bitcoin nodes create ~6000 transits for lots of i2p nodes?

orignal wait

orignal higher trafiic or number of requests?

zzz higher number of users

orignal two different problems

Traca orignal, I don't run transient tunnels, I only have 1 SAM session

zzz geti2p.net/_static/images/tunnel.participatingTunnels.60m_31_0.png

Vort I agree that it is better to investigate count and bandwidth problems separately

Traca orignal, I will run only i2p on desktop with transient, will tell you how many sam sessions

Vort Recent increase in i2p usage shows both as increase in tunnel count and transit bandwidth/traffic

orignal Traca yes please

Vort If problem is solely in bandwidth, then limits on count will not help

Traca local destinations switches from 7 to 16 in 10 minutes

orignal I can't repoduce it loally because my internet connection is too narrow

Traca left all night and at morning was still 16

orignal zzz, peple here are asking what's you probllem with number of transit tunnels?

orignal what resource is getiing exhausted?

Traca orignal, now already have 4 SAM sessions

orignal ok, got itto them and see how many tunnels you have there

Traca and I have 4 peers for now, being oubtound connections only bitcoin limits to 10-11 peers

Traca local destinations from 7 -> 11

orignal you see something like

orignal SAM Session:

orignal 3zzev7ooxvtwgje6xbkclmw5kecggr6wbfgaw7ijcpsfwoeynnpq.b32.i2p

orignal click on the destination and see

Traca yeah

Traca SAM Session:

Traca 4sascjwpiahsfhcremzn74xvf3vjmxfnikqsxyfwhem2z5ik4s2q.b32.i2p

Traca Streams:

Traca session [127.0.0.1:60838]

Traca stream [127.0.0.1:52110]

orignal Inbound tunnels

orignal Outbound tunnels

orignal <Traca> stream [127.0.0.1:52110]

orignal you are good

orignal plese check number of tunnels inside dest

Traca number of tunnels? you mean tunnels in webconsole?

orignal <Traca> 4sascjwpiahsfhcremzn74xvf3vjmxfnikqsxyfwhem2z5ik4s2q.b32.i2p

orignal click on it

orignal you will see more

orignal Inbound tunnels:

orignal and Outbound tunnels:

Traca Inbound tunnels:

Traca ⇒ 7DVg ⇒ iqd5 ⇒ Bx-d ⇒ 2617702408:me ( 177ms ) established, 10 KiB

Traca ⇒ 3c0i ⇒ FgbN ⇒ uoyO ⇒ 2090775097:me ( 289ms ) established, 13 KiB

Traca ⇒ HMnQ ⇒ cLKx ⇒ Qreu ⇒ 3793263001:me ( 145ms ) established, 215 KiB

Traca ⇒ GdCU ⇒ xNsp ⇒ HipL ⇒ 2100313518:me ( 326ms ) established, 22 KiB

Traca ⇒ MFy3 ⇒ p37- ⇒ mGVr ⇒ 2346244799:me ( 378ms ) established, 261 KiB

Traca Outbound tunnels:

Traca 3211397221:me ⇒ 37rt ⇒ dJpX ⇒ mL4g ⇒ ( 158ms ) established, 6 KiB

Traca 484542004:me ⇒ GzKd ⇒ doZU ⇒ EoHa ⇒ ( 234ms ) established, 38 KiB

Traca 523825589:me ⇒ dB81 ⇒ JPUb ⇒ 0de4 ⇒ ( 185ms ) established, 56 KiB

Traca 2304403888:me ⇒ mGVr ⇒ p37- ⇒ MFy3 ⇒ ( 334ms ) established, 284 KiB

Traca 2503012800:me ⇒ 0Z9X ⇒ MHbN ⇒ Ra-Z ⇒ ( 359ms ) established, 12 KiB

orignal you are good

orignal zzz, Traca 's tunnels are fine

orignal 5 for each side

orignal I think the problem is not number of tunnels

Traca checking all and all yes, 5 each side

zzz yes, I know, he has not been able to reproduce it yet

orignal but badwidth usage

orignal routers reject tunnels because bandwidth

zzz but my theory is the bandwidth is more tunnel builds

Traca the only number that changes is in tags Tags

Traca Incoming: 262

Traca Outgoing: 142

orignal in my teory bandwidth is blockchain sync

zzz bitcoin+i2pd is spamming the network with tunnel builds

orignal remeber BTC blockchin is around 500 Gb

zzz ok, so test your theory

orignal it's spamming because got rejected

orignal and rejected by bandwitsh

Traca no one is using I2P for starting a new node

Traca all nodes joining I2P are already synched

zzz but tunnel count has DOUBLED in a WEEK: geti2p.net/_static/images/tunnel.participatingTunnels.60m_31_0.png

orignal even after couple weeks breask you have to sync a lot

orignal yes, it's doubled

Traca oh I see

Vort Traca: where lots of traffic comes from then?

orignal because every tunnels has 3 hops

zzz that's not caused by a few bitcoin nodes

orignal if one on them got rejected

zzz it's caused by tunnel spam

orignal whole tunnel stays for 10 minutes but it's dead

orignal then what causes such traffic?

orignal Transit: 199.51 GiB (4754.12 KiB/s)

Vort One of my transit tunnels used 1.7 GB of data in 10 minutes!

orignal no tunnel build requst can produce such amount

zzz bitcoin creates 100 tunnels. Most fail. i2pd builds more tunnels. bitcoin creates more sam sessions. Most of them fail. Repeat

Traca Vort, I don't know, but no single user uses exclusively I2P for bitcoin, so just one more network

Vort That not looks like how synced node behaves

zzz if bitcoin creates 10 new sessions every minute

Traca and most users I know they are not even aware about how to change the bandwitch in the conf file, so they just copy/paste the commands to have i2pd running

orignal but bitcoin closes failed SAM session or not?

zzz I assume so

orignal what doe it do with failed peers?

Traca so if they don't have a lot of connections, uses very low bandwitch, zzz theory makes the most sense to me

zzz don't know, you're the C++ guy, not me

orignal then once you close SAM session a destination dies

Traca now I have 10 SAM sessions

orignal guys you can have any theory

orignal but such traffic is real

zzz orignal, how many tunnel build requests would you send out in a minute, for 10 sessions x 10 tunnels, if every build request timed out?

Vort source of megabytes/sec bandwidth for ~all i2p nodes is not discovered yet

orignal Traca right and acoording to Dimov you are limited by 10

Traca yes, now I already have 10 peers

orignal I would send around 50 a minutes

orignal yes, and 10 is your cap

Traca yes it's correct, it is limited to 10 outbonds

zzz well, you and Dimov figure it out. Prove your theory, or prove mine, doesn't matter to me, but you guys need to get to the bottom of it

Vort did anyone tested how not synced bitcoin + i2p(d) node behaves?

Vort same as synced? no anomalies?

orignal 50 * 7 * 1K

orignal 350K per minute add on for entire network

orignal almost zero

zzz Dimov probably speaks RU, I think he's from BG

orignal no, I guess he is Bulgarian

orignal he is Vasil not Vasily

Traca Vort, I personally did not try, but for the conversations in raspiblitz it seems to behave normal

Traca they were discussing to include for IBD to add I2P since for now was only onion network

orignal <Traca> ⇒ MFy3 ⇒ p37- ⇒ mGVr ⇒ 2346244799:me ( 378ms ) established, 261 KiB

orignal 216K

orignal Trace can you monitor these numbers?

orignal how much traffic goes trough for you

orignal btw you have one of my routers in your tunnels ))

Traca from SAM Session:

Traca 4sascjwpiahsfhcremzn74xvf3vjmxfnikqsxyfwhem2z5ik4s2q.b32.i2p?

orignal for all of them

orignal if you see a lot of data goes trought

Traca how do I do it?

Vort yeah, there will be megabytes if that is the source of problem

orignal last columenn

orignal <orignal> <Traca> ⇒ MFy3 ⇒ p37- ⇒ mGVr ⇒ 2346244799:me ( 378ms ) established, 261 KiB

orignal established and you see total amount of data went trhough a tunnel

Traca the biggest I see is expiring

Traca ⇒ HMnQ ⇒ cLKx ⇒ Qreu ⇒ 2542369385:me ( 230ms ) expiring, 632 KiB

Vort that is almost nothing...

Traca 2646096148:me ⇒ F~XT ⇒ Cbhx ⇒ OoZP ⇒ ( 225ms ) failed, 586 KiB

Traca 2317772562:me ⇒ duk4 ⇒ o0N6 ⇒ 6y9D ⇒ ( 216ms ) established, 508 KiB

Traca all the other are very little

orignal but you are upto date, right?

Vort meanwhile I have 2 megabytes of transits per _second_

Traca i2pd version?

Vort sync

Traca yes I am up to date

Vort orignal: it does not mean too much. other users may be non synced and use lots of bandwidth

Vort they will show in statistics too

orignal that's why not a lot of data went trough

orignal *** away ***

weko Transit Tunnels: 12513

weko Transit: 63.93 GiB (3896.30 KiB/s)

weko Transit Tunnels: 12621

weko Tunnel creation success rate: 23%

weko lower and lower

Traca Tunnel creation success rate: 20%

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

orignal у меня нету потребления

Vort ну значит сразу расскажу

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

orignal ну так на слабом не надо ставить X ))

Vort когда у меня идёт трафик от 0 до 2 мегабайт в сек то нагрузка CPU стоит на 3%

orignal конечно мощно

weko orignal: я не уверен, достаточно ли мощный))

orignal у меня счас на впс 30% на ядро

orignal там 2 ядра

Vort но вот несколько раз при превышении (когда пёрло 2-4 мегабайта в сек), то нагрузка росла аж до 15%

weko у меня 4 ядра, нагрузка +- 100% тоесть одно ядро

orignal аааа ну это фигня

weko бывает 90 бываеь скачет до 150-160

Vort я ожидаю в 2 раза больше трафика - в два раза больше нагрузки. то есть, 6%. а не 15%. это оч6ень на баг похоже

orignal просто у тебя OBEP

orignal и установка много соединений

orignal с кучей x25519

orignal weko нажми 1

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

orignal нет нагрузка на проц зависит не от трафика

orignal а от его так сказать разнообразия

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

weko иногда есть пики ядра до 100% но это редко

weko очень редко я бы сказал

Vort ну разнообразие. допустим. обычно 3%, а тут ползёт до 15%. что изменилось?

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

Vort я корреляцию с траффиком кстати вижу

weko насчёт битка - если там куча sam сессий создаётся даже на один пир, то понятно откуда спам. если нет, то не понятно.

weko orignal: просто раньше X был не проблемой. щас вообщем то тоже тянет, но жрёт в 2-3 раза больше))

weko X хоть и стоял, но трафик был где то 500

weko а щас вот что

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

weko и джаве тоже

orignal ну так счас стало много

orignal таки ушел

Vort скину на всякий случай скрин того глюка с нагрузкой CPU

Vort ещё ползёт так лесенкой

Vort privatebin.i2p ERR_NAME_NOT_RESOLVED. да что за

Vort это, конечно, оффтоп. но всё же. "Destination: Can't send LeaseSet request, no inbound tunnels found"

Vort что ему надо, блин?

Vort а, уже отлипло

weko zzz: have java i2p limit for create destinations via SAM/I2CP? this useful for see bugs how in bitcoin on testing stage, before release.

zzz we limit to 100 by default, and it's configurable

Vort privatebin.i2p/?36d2f05460770697#65va6KnmwZBttY3ZywTqhRcj4A7bx3BaDyQnwB5o7f7S

Vort слева, справа - 3% при примерно 2 мегабайтах/сек. по центру - неведома фигня

zzz weko, i2cp.maxSessions=nnn

weko zzz: 100 and one time? or limit per some time?

weko at*

zzz total

zzz at one time

weko but program maybe spam SAM sessions and close it after create

zzz right

weko need limit per second or per minute

zzz we also limit tunnel builds to 2.6 per second and we are researching if that's too high

zzz maybe reduce after repeated failure

weko need limit tunnl build per address

weko tunnel*

weko for normal work right nodes

zzz we kindof do that with round-robin plus overall limit of 2.6/s

weko i will translate my suggestions (about limits) on english

weko some for good protect good nodes from banning, some for protect good nodes from attackers

weko stats.i2p/cgi-bin/total_routers_month.cgi

weko good new routers statistic

weko 1000 -> 2000

weko Transports:

weko NTCP2 ( 3201 )

weko NTCP2v6 ( 22 )

weko SSU2 ( 2231 )

weko нормально так баг "кушал" транспортов

weko Transit Tunnels: 12745

weko раньше такие числа бывали во время пиков, теперь вот это стандартные цифры

Vort так никто и не сказал, от чего java узлы перегружаются - то ли от трафика то ли от количества )

weko скорее от трафика)

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

weko даже ждя джавы

weko для*

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

Vort тогда зачем основной проблемой выставлять количество? первый график в отчёте на гитхабе биткоина

weko да я хз, говорю я думаю

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

weko в любом случае если у них баг то его им надо фиксить

Vort а из-за лимита транзитов сеть раком встаёт

weko ну раком не встаёт

weko повышается нагрузка

weko лимит файлов хз

weko может но тогда проблема всплыла бы раньше

Vort нет ну понятно что всё это на фоне новой нагрузки

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

weko ну да, это может быть проблемой

weko но точно всё не покрывает

weko я думаю тут совокупность багов даёт такую нагрузку

weko они перемножают друг друга

Vort кто может сказать, что перегружает java узлы? :)

weko в итоге имеем что имеем

weko Vort: их всё перегружает

weko даже чих в серверной

Vort нужны числа по хорошему

Vort разработчики про профилировщики хоть знают?

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

Vort то же самое по трафику - при мегабайте/сек, при двух

Vort ну мне так кажется. мож фигню говорю

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

Vort числа нужны. всё может быть

weko нагрузка флудфила теряется на фоне того, как много нагружает трафик

weko Vort: ну да, надо ))

weko всё надо))

Vort я просто знаю как C# работает

Vort и понимаю, что может быть в Java

weko нужен человек, который будет составлять статистику всего на свете ))))

Vort если C++ мелкую функцию развернёт в пару опкодов, то C# не только оставит функцией с кучей возни со стеком, но ещё и проверок напихает

Vort а если сделать уйму мелких функций...

Vort короч оптимизация там специфичная

Vort то, что быстро в C++ работает не факт, что будет быстро работать в Java

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

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

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

weko да может быть разное соотношение но всё равно

Vort а ведь без критерия лучше/хуже не существует, не имеет смысла

Vort ну и про оптимизцию скажу

Vort иногда кажется - надо поменять _вот так_ - и будет быстрее

Vort ну меняешь, радуешься что улучшил код

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

Vort поэтому измерения всё же нужны. мы тут ближе к науке, чем к творчеству. ну или к политике )

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

weko поэтому ты можешь мерять только разницу между релизами

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

Vort касаемо моего рассуждения об оптимизациях - тут надо уметь подготавливать условия для измерений

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

Vort то есть, по сути надо измерить три значения - нагрузка на CPU, количество транзитов и траффик

Vort потом крутить эти значения и думать над ними

Vort но опять же - так мне кажется. может, не прав

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

Vort странно вообще, что этого никто ещё не сделал

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

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

weko не ставит

weko потому что нагрузка запросов транзитных туннелей меньше

weko в виду их количества

weko по отношению к трафику

Vort разработчики java версии с этим согласны?

weko не знаю. спроси

Vort вот сейчас пересматривал логи. "but my theory is the bandwidth is more tunnel builds"

Vort это он сказал, что траффик создают создания туннелей?

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

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

Vort то есть, наоборот. не тунеели создают траффик, а траффик создаёт туннели. понятно

Vort тогда это как понять? "that's not caused by a few bitcoin nodes" / "it's caused by tunnel spam"

Vort может он таки считает, что те конские туннели, что мы видим, это иллюзия, а дело всё в количестве туннелей?

Vort не верится, но я не могу никак иначе понять

weko возьми и спроси

Vort ну а твоё понимание английского какой вывод позволяет сделать?

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

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

Vort предположение, что траффик из-за спама туннелей?

weko вот если увидим Client tunnels: (большое число), тогда будет понятно

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

Vort по-моему, речь о разных вещах

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

Vort и из чего эта нагрузка состоит

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

weko ну так а я о чём написал

weko об этом же))

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

Vort в ответ получил, что надо воспроиведение. ну надо - и что?

Vort // отойду

weko я точно не лучше тебя расшифрую

weko какая разница если это всё равно предположение

weko тем более уже озвученное

weko ранее

weko поэтому я и сказал что нужно найти при каких условиях идёт спам туннелями

weko найдём тогда и можно решать

weko может это вообще не биток а последствие наплыва юзеров. баги умножились и пошла нагрузка

weko мало что может быть

weko вот это интересно stats.i2p/cgi-bin/avg.cgi?a=tunnel.buildExploratorySuccess.10m&s=31&u=m

weko Network Weather Forecast:

weko Sunny!

weko меня всё ещё смешит вот эта штука

weko она вообще динамическая?

weko или так просто влепели по рофлу

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

weko ну так это и не понимание ситуации

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

Vort значит, я просто не понял тех фраз

Vort //опять ушёл

R4SAS смотрю тут всё так же весело

Vort много букв? :)

weko так и прёт веселье)

R4SAS Бибизяна тоже веселится под моим ником типо

weko бабизяна бабизяна)))

weko кто то даже обманулся

weko )))

weko на reg.i2p кто-то спамит тупыми доменами))

weko шиз какойто

R4SAS там часто такое происходит

anonimus и что руками вычищать?

R4SAS нет, само вычищается

anonimus а как?

R4SAS автоматика

R4SAS не с проста же на главной написано что всё автоматизировано и люди не принимают участия в работе

weko а как ты сделал что оно сами

weko само*

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

R4SAS такой мусор обычно ни кто не содержит, и он протухает

R4SAS посмотри на те записи, она были созданы 27 числа, и 27 же числа был последний раз онлайн

weko а, это то))

weko а вдруг кто то будет содержать)

R4SAS соответственно они просто будут выкинуты.... завтра, когда начнутся 3-е сутки

weko угу

R4SAS ну, значит это уже мусор поддерживаемый

R4SAS будем называть это "говносайтом без наполнения"

weko а точнее вообще не сайтом а гавном

weko потому что с вероятность 100% такой спам будет содержаться просто публикацией лиссетов

weko уж точно никак не будет с туннелями)

weko нет ну может и будет.. зависит от спамера конечно)

R4SAS да пофиг вообще

weko ))

weko надо будет завести в ш2з домены на блокчейне.... когда то в будущем)))

R4SAS вообще не нужно

weko ну да я согласен что платные домены это плохо

anonimus блокчейн - костыль

weko anonimus: не согласен

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

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

weko и поэтому спамеры могут стать проблемой

R4SAS 10 лет жили, и тут внезапно заспамят? не думаю

weko ну я не говорю что заспамят сейчас

weko я и говорю что когда то в будущем

weko надо сделать

weko сейчас суетиться некуда

weko работает и ладно

R4SAS если начнут спамить, то просто включится проверка дополнительная

weko о, тоже круто.

weko а что за проверка

weko что она проверяет

orignal weko а где SSU2v6?

weko так это yggdrasil

weko сам не сделал а спрашиваешь))

orignal ааа не сообразил

orignal чего я не сделал?

weko ssu2 в иггдрасил

weko ))

R4SAS weko: проверка, которую еще надо придумать и реализовать

R4SAS )))

weko xD))))

orignal там дохуя работы с этим

orignal R4SAS что с трафиком на дедике?

R4SAS │ eno1 28042.6 29763.7 39965.440353.1 718.5 755.3 29863.6 31792.7

orignal не растет

orignal у тебя точно в порт не упирается?

R4SAS возможно, но точно не известно

R4SAS Uptime: 18 hours, 47 minutes, 1 second

R4SAS Received: 478.42 GiB (7532.38 KiB/s)

R4SAS Sent: 503.94 GiB (8739.11 KiB/s)

R4SAS Transit: 475.57 GiB (7546.16 KiB/s)

R4SAS Routers: 12494 Floodfills: 1728 LeaseSets: 0

R4SAS Client Tunnels: 41 Transit Tunnels: 13649

R4SAS s2#4

R4SAS CPU 234.5 RAM 126976

weko Tunnel creation success rate: 22%

orignal счас буду пробовать улучшать рейт

weko Transit Tunnels: 14066

orignal пиздец

weko может бытьл пик

weko не смотрел

weko "это не пипец, это не пипец, это не пипец"

weko ))

orignal счас одну мысль продумаю

orignal тред с тоннелями

orignal он может быть забит

weko и поэтому плохо создаются клиентские туннели?

orignal плохо чистятся

orignal точнее плохо устанавливаются

weko как можно проверить?

orignal не знаю пока

orignal в веб морде в пункте Tunnels есть Queue size:

orignal если там много больше нуля то у нас проблемы

weko большую часть времени 0, иногда 4 или 1 проскакивает, но быстро уходит в 0

orignal но пока я не вижу

orignal значит порядок

weko 15 иногда проскакивает даже

weko но в 0 уходит

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

orignal если будут сотни тогда стоит это переделывать

weko You have joined too many channels

weko круто

weko блин

weko а если я хочу ещё канал

weko да блин

weko что за тупой лимит

weko дайте больше!)

orignal я не знаю где то ставится

orignal жди R4SAS -а

weko окей

weko спасиб, ато хотел канал создать, а тут западла такая

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

Vort мог ли я попадать на проблему с забитой очередью когда у меня вылазило "Destination: Can't send LeaseSet request, no inbound tunnels found" ?

Vort это вообще странно что не хватало туннелей

orignal нет

Vort (по моему мнению странно)

orignal это как раз про низкий рейт

orignal у тебя тоннели не строилисб

Vort то есть, старые ушли, а новые не пришли?

orignal да

orignal потому что унники лимитирут запросы

weko джава роутеры то?

Vort вот сейчас на прокси вместо 5+5 было 3+2

weko да есть такая проблема

weko иногда меньше чем надо держится

Vort и вот это +2 как было, так и висит. 4+2 сейчас

weko вот у меня тут например, надо 3 а держится всего 1

orignal ну да

weko или даже 4, не помнб

weko помню

Vort i2pd не тыкает слишком часто чтобы сеть не перегружать?

Vort просто +2 как стояло, так и стоит

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

Vort то есть, i2pd забил на эту проблему как будто

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

orignal неее

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

Vort вот только сейчас получилось 4+3

Vort хм

weko orignal: реально? а вот это я не знал. я думал строит новый каждый раз

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

weko а разве не должен по разным строить каждый раз?

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

weko суть же в том что каждый 10 минут маршрут меняется

weko каждые*

orignal и в стримах бывает переключение на него

orignal нет такого чтобы "маршрут менялся"

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

weko туннелю*

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

orignal RTT поедет

orignal это никому не надо

Vort и если был быстрым, то быстрым и оставался

weko если туннель истекает или фейлится, меняем туннель

weko разве не так должно работать?

orignal тормозить будет

orignal в этом случае

Vort "всегда снчала строится точно такой же" - а когда не такой же?

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

weko это в торе одна цепочка может жить долго, а тут же такого быть не должно

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

weko смысл лимита в 10 минут разве не в том, чтобы создать другой туннель уже через другие роутеры?

weko в ш2з что, настолько глупый протокол стриминга?

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

weko а меня беспокоит что это странно

Vort weko: хе. RTT ведь не дочинили то

weko и не в концепции i2p вообще

weko а при чём тут rtt

Vort weko: при том, что он сейчас в i2pd заклинивает. его надо оперативно менять при смене маршрута

orignal не знаю

weko Vort: надо то надо, только вот прикола с использованием тех же цепочек я не понял вообще

weko зачем это

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

orignal насчет фейлов

weko нет я вообще не понимаю зачем использовать теже цепочки для туннелей

orignal если фейл то не пытаться

orignal не знаю так изначально было

orignal а джаве также

orignal зачем я тебе ответил

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

weko это потому что протокол стриминга глупый?

weko или потому что тупая его реализация в джаве?

weko или и то и другое

Vort надо оценку RTT пересчитывать. правильно

weko *недоумевает*

Vort даже на правильный пересчёт надо время

Vort а пока считается будут небольшие глюки

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

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

orignal что все вычисляется на основе RTT

weko и при смене туннеля он лагает, поэтому лагает стрим?

Vort стрим должен адаптироваться к новому туннелю так сказать (если я правильно понимаю)

weko должен

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

weko а

weko понял

weko было бы логично делать адаптацию заранее для другого туннеля

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

weko когда делали

Vort вот уж не знаю, насколько это возможно

Vort может и сейчас можно

weko а раньше почему нельзя было?

Vort я имею в виду, что я не знаю, мешает ли этому что-то сейчас

Vort и если мешает, то насколько серьёзно

weko а, понял

Vort но как я уже говорю, сейчас оценка RTT не гибкая, поэтому вообще вся эта система работает не очень

weko просто я не говорю что это надо срочно сделать, но вот было бы неплохо если бы так работало

weko поэтому и лагает всё

Vort но хоть самый главный баг когда оценка почти в ноль скатывалась починили

weko запросы могут застревать на пару секунд

weko уже хорошо

orignal Transit Tunnels: 14497

orignal бугага

orignal скоро упрусть в лимит в 15K

orignal Queue size: 72

orignal ха. а вот это уже тема

weko Дааааа

weko orignal: повысь значит)) я себе поставил 65535 чтобы забыть про него вообще))

orignal повышу

R4SAS orignal: я в одно мгновение видел 759

orignal вот это проблема

orignal счас сделаю чтобы иногда просиралось на предмет очистки

R4SAS но оно по идее довольно быстро рассасывает его

R4SAS какой то говнястый роутер не ответил и s2#1 ушел в режим FW

orignal ты не знаешь какие там пики бывают

orignal там не один а 5 не прислали HolePunch

orignal запилил

R4SAS а если алиса не отослала нормально запрос чарли, но при этом ответила что запрос отправлен?

orignal ты имено ввиду боб?

orignal и так 5 раз подряд как в анекдоте?

R4SAS да

orignal чет по моему кое кто берегов не видит

R4SAS не, так там же дедик

orignal в той теме у битка

orignal неее

orignal почитай там

R4SAS а

R4SAS ща

orignal ответить там что ли?

R4SAS а чего там?

orignal дед решил назвать нас земляными червяками ))

orignal ну ну