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

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

Vort ага, вижу. [queue:38]

Vort видимо, жирный транзит там идёт

Vort ⇒ ~xCJ: 71.19.146.214:3001 [147701992:6460070] [queue:244]

Vort там, где большие объёмы, там и очередь накапливается

Vort ⇒ NoeR: 176.212.72.221:18522 [82750963:337065] [queue:196]

orignal вот

orignal значит следующий шаг

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

orignal собсьвенно ради чего все и затеяно

Vort так это же, скорее, очередь из-за объёма, а не объём из-за очереди

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

orignal правильно очередь из-за объема

Vort а.. ну то есть, не пихать туда ещё данные, если и так уже забито?

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

orignal лучше взять какое то другое

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

Vort с забитостью согласен

orignal ну нам это не важно плохое соединение там или объем

orignal важно что данные не пролазят

Vort в данный конкретный момент не пролазят. вот что важно

Vort когда (если) будут пролазить - тогда и пихать

orignal ну разумеется

Vort да это я пишу под впечатлением от любителей банить на каждый чих )

Vort на всякий случай в общем

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

orignal ну так я не собираюсь банить

Vort я уже это понял

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

orignal ну так это от той стороны заивисит

orignal Transit Tunnels: 15375

orignal новый рекорд у меня

baz всем дров.

orignal что хотел?

WebClient88 orignal: а что если поймать парочку биткоино-водов, прицепить им клеммы с дискового телефона с крутилкой и заставить повторить чистый эксперимент? пусть запишут всё что можно. пару экспериментов

WebClient88 синхронизации с нуля, 4-5 экспериментов с обновлением. И ещё очень интересует сколько у них хопов. 3? И какие пиковые значения на 1 тоннель. не средние, а пиковые. Это же очень интересно. Пусть

WebClient88 вкладку tunnels сохраняют, потом найти максимально число и разделить на 10*60 600 секунд и получим хотя бы среднее пиковое значение на 1 тоннель . или есть какой то другой способ увидеть пиковую

WebClient88 скорость на 1 тоннель/соединение? Средствами ОС?

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

Vort хопов, скорее всего, три. тут один юзер выкладывал кое какие результаты

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

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

quake tube.i2p вооще не войти

orignal без толку

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

orignal *сеть

orignal я пробовал

orignal Vort правильно понял

orignal но мы счас пока 0 даже шифрование не создаем

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

WebClient88 ну во первых очень интересно - а какая пиковая скорость на 1 тоннель. Может оказаться что через 3 хопа i2pd скорость очень выскокая - это же "отвал бошки". Тогда будут прямые доказательства что

WebClient88 сеть можно раскрутить до запредельных скоростей

Vort вот вижу я Client Tunnels: 50. а сколько мой узел насрал мёртвых туннелей по транзитам - непонятно

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

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

Vort то есть, удача одного юзера из 1000 ничего хорошего для среднестатистического юзера не означает

Vort ну повезло. бывает

WebClient88 Во вторых сейчас в обсуждении просто слово против слова. Джавистам кажется, что дело где-то там в i2pd. "Хдэ фаши докасателства? Кокаинум". просто какие-то набросы. Факты, где факты.

Vort обсуждения мутные, это точно

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

Vort вычислить точно источник нагрузки из-за этого нельзя

Vort можно только гадать. что получается так себе

WebClient88 "то есть, удача одного юзера из 1000 ничего хорошего для среднестатистического юзера не означает" - означает. Если вдруг окажется, что i2pd потенциально при удаче выдавливает по 3-4 мегабайта на 1

WebClient88 тоннель при 3 хопах, то это подстегнёт джавистов расшивать узкие места.

Vort quake: это проблема с самим сайтом. выдаёт ERROR WTF

weko WebClient88: ну, например, если у джавистов нет туннелей, на которых такие скорости, то это почти прямое доказательство, что причина тупняков в сети - Java I2P. В i2pd такие транзиты есть точно

weko Можно у них спросить

Vort для чего то ведь флаг X придумывали

Vort так что скорее всего эта скорость реальна

weko Ну когда придумали не думали о том что мощностей реально хватит на 100мбит ный порт

weko Или даже 10мбит

weko Сейчас вот хватает

Vort на всякий случай сделали? на будущее? :D

weko Нет

weko Наоборот

weko Сейчас хватит и на гигабит

weko i2pd точно, джава ХЗ

Vort не вижу просто смысла в флаге > 2 мегабайт/сек если такого никогда не бывает

weko Даааа

weko А теперь бывает

weko Раньше не бывало

Vort зачем тогда флаг было придумывать?

weko Поэтому и не сделали

weko ?

WebClient88 кстати не хватает флага на 4,8,16 МБайт/сек

Vort ну есть же ограничение 2 мегабайта/сек

Vort зачем в таких условиях был нужен безлимит?

weko Так вдруг у кого то мощнее

WebClient88 "не вижу просто смысла в флаге > 2 мегабайт/сек если такого никогда не бывает" - всмысле не бывает? У меня роутер трещит по швам две недели

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

Vort ну вот. значит у кого-то такие скорости были реальны

weko Нет

Vort WebClient88: да мы про джаву

weko Не были

weko С чего ты решил

Vort WebClient88: да, меня вообще удивили флаги "с потолка". вместо того, чтобы задать число

Vort weko: обычно фичу делает из-за потребности, а не просто так

orignal я уже предлагал флаг Q в 100мбс

Vort если не было потребности в анлиме (то есть не хватает P), то непонятно зачем было это делать

orignal потмоу что на многих впс это ограничение порта

Vort orignal: порт и без флага ограничит

weko Ну и чо джвависты послали?

weko Vort ты не понимаешь, зачем нужны флаги

Vort а вот если я хочу, чтобы от порта и мне что-то осталось, то скорее будет нужен около 6 или 8 мегабайт в сек лимит

weko Во первых они влияют на выбор пиров

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

orignal Vort чтобы другие знали

weko Глупо ориентироваться на ограничение обсоса/сетевой карты

weko Это не надёжно

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

weko И бывает очень часто лагано

weko Vort вот именно

weko Поэтому нельзя ориентироваться на лимиты порта

weko Как ты выше предложил

Vort юзер готов дать X, а провайдер у него по dial-up :))

weko Ну готов пусть ставит x

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

weko Я не вижу проблемы

weko Где проблема?

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

weko Ну так есть профайлер

weko Если пир творит херню , то мы его баним для наших туннелей

weko Ну и всё

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

weko Не понимаю зачем об этом думать

Vort "<weko> Vort ты не понимаешь, зачем нужны флаги". вот именно

Vort вот был бы Q. на что бы это повлияло? :))

Vort "<weko> Глупо ориентироваться на ограничение обсоса/сетевой карты" когда я качаю файлы на всей скорости, то почему-то об этом не жалею

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

Vort и не лагает

Vort и ещё одно - если i2pd таки будет ограничивать скорость, то это ограничение будет жрать CPU

Vort юзеру будет выбор - или поставить Q и получить жор CPU или поставить X - скорости будут ровно те же, но CPU будет попроще

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

Vort может, это и невозможно. не знаю. но в нынешнем решении я всё же вижу странность

weko Бред

weko Сети порядочный юзер может сообщить

weko И от этого не умрёь

weko Браузер это не p2p

weko Сравнение не корректно

weko И тем более браузер это не i2p

weko Да ограничение будет жрать CPU, но опять же в разы меньше, чем потенциальная нагрузка без ограничения

Vort если сетевая карта 100 мегабит/сек, то через неё всё равно больше не пролезет

weko Логично

weko И что

Vort и если поставить такой же лимит, то точно так же в эти 100 мегабит/сек и будет упираться

weko Я тебе уже сказал зачем лимит в i2p

weko И зачем его сообщать сети

weko Да но с обработкой на уровне i2p

weko А не уровне сетевой карты

weko Что важно для отсутствия затыков

weko Я уже писал разные варианты как обрабатывать

weko Динамический или статический лимит

weko Как пример; может быть можно придумать лучше

weko I2p же не знает про лимиты карты, и не знает что будет при превышении

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

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

weko Vort: а я ответил что есть профилирование

weko Сколько раз про него сказать?

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

weko Бывает

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

weko Бывает всегда

weko Просто где то их видно

weko А где то нет

weko Vort: флаги ускоряют эту работц

weko В рады

weko Разы

weko При учёте что не все подряд юзеры ставят X (а это так и есть)

Vort самый просто алгоритм "не лезет - не пихай" достаточен для того, чтобы не было "происшествий"

Vort в TCP это делается автоматически, в UDP надо немного подумать

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

weko Не знаем сколько у транзитов максимум сейчас

weko Ты про низкий уровень думаешь

Vort "Ну так в i2p мы не знает сколько можно запихать в очередного юзера" последние коммиты i2pd смотрел?

weko А он тут не при чём

weko Vor

weko Vort: нет. В любом случае не знаем

weko Только если он сам не скажет (что я и предлагал сделать)

Vort ну допустим не буду особо сейчас спорить. просто мини-историю расскажу

weko В случае динамического лимита

weko Или почитаем в случае статического

weko посчитаем*

Vort вот у меня 100 мегабит/сек. кто-то погрыз кабель. ну работает всё-таки сеть и ладно

Vort только вот как-то раз это привело к тому, что какая-то из железок решила, что мне и 10 мегабит/сек хватит

Vort пока не перезагрузил роутер так и стояла десятка

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

Vort и поменять флаг зараннее )

weko Ну профилировщики будут реже твой пир выбирать вот и всё

weko Не вижу проблемы

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

weko А не сколько можешь

weko Ощущение что ты очень сильно тупишь

weko Или не понимаешь что i2p это не просто p2p

weko А p2p с перенаправлением трафика

Vort "<weko> Ну так в i2p мы не знает сколько можно запихать в очередного юзера" "<weko> Флаг это сколько ты готов пропустить" "<weko> А не сколько можешь" -> как не знали, так и не знаем

weko Ну если в реальности меньше профилировщик будет слать такой пир

weko 0_∆

weko 0_0

weko Если пир не соответствует ожиданием, мы его шлём на три буквы

weko Вот и всё

weko Не вижу проблемы всё ещё

` Извините за оффтопик. Но шотам с Флибустой в ш2з? Они в этот раз ушли в дипнет всех дипнетов - локалхост?

orignal ` молчат

orignal я в твиттере их постоянно спрашиваю

HidUserZ orignal: вопрос по поводу Tunnel creation success rate. Судя по коду берется количество успешных попыток создания тоннеля и делится на общее количество попыток. Получается что этот показатель зависит от аптайма роутера => чем больше аптайм тем

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

orignal именно так

HidUserZ Было бы хорошо использовать "Экспоненциально взвешенное скользящее среднее"

Vort (не просто так я это с RTT сравнивал)

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

orignal HidUserZ сделай PR об этом

orignal у меня просто времени на это нет ))

HidUserZ хорошо, попробую

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

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

orignal зато считать проще всего

weko Поэтому нужно оставить и текущее значение тоже

weko Ну понятное дело

WebClient88 "Скорее, чем больше аптайм, тем точнее значение." Чем больше аптайм, тем точнее значение которые с течением времени становится всё более не нужным. Средняя температура по больнице

Vort тут подходим к вопросу - как его применять?

Vort тогда станет понятнее, какое нужнее

weko WebClient88: есть и смысл среднего по больнице, и в текущем значении

weko Ну в "текущем"

weko В реальности имеет смысл смотреть последние 3 часа

weko Иначе будет просто скакать

HidUserZ WebClient88: отлично сказано

HidUserZ ну вот так и будет, последние n часов

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

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

mblw_ такс

mblw_ понял

HidUserZ у меня при alpha = 0.01 среднее значение сводится к истинному среднему значению (если брать алгоритм EWMA)

mblw_ не париться

WebClient88 суточных больших нет. Есть в субботу

mblw_ и запилить 10gb/ps карточку надо))

Vort WebClient88: за неделю усреднять? :)

HidUserZ Vort: но

mblw_ я выкл ygg

HidUserZ Vort: но это точно лучше текущего алгоримта

mblw_ но транзит такойже

HidUserZ через неделю уже становится неизвестно реальное значение

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

HidUserZ ru.wikipedia.org/wiki/Скользящая_средняя

WebClient88 Экспоненциально взвешенное скользящее среднее учитывает все данные за весь период. Только в зависимости от коэффициента можно будет говорить о том что вес данных за последнюю неделю

WebClient88 составит 99%

HidUserZ в смысле?

HidUserZ оно учитывает только предыдущее значение среднего

Vort "через неделю уже становится неизвестно реальное значение" - оно в любом случае реальное. только разная фильтрация (частота среза грубо говоря)

WebClient88 Вес исторических данных стремится к нулю, но не является нулём

WebClient88 и вопрос как быстро зависит от коэф. сглаживания

HidUserZ WebClient88: ты про мой коэф. 0.01?

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

HidUserZ на <0.01 оно фиксируется в пределах 2 знаков

Vort ещё кое что вспомнил

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

Vort так что слишком большое "окно" не годится

WebClient88 всмысле колебаться? А если оно реально сейчас прыгает? может так и должно быть. надо сначала определиться за какое время брать данные и что чем можно принебречь. Условно - надо чтобы

WebClient88 учитывались данные за посдение 4 часа с весом 99%. А все остальные данные соответсвенно с весом 1%. И высчитать коэффициент альфа. поискать формулу надо, как вывести из показателей 4 часа и 99% -

WebClient88 коэффициент сглаживания (альфа)

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

Vort WebClient88: ну да. надо понять, зачем нам это значение вообще нужно

Vort (один из ответов - для прекращение очистки)

HidUserZ WebClient88: нет смотри. я сделал массив из числе [1, 1, 0, 1, 1, 0, ...], их реальное среднее значение = 0.3(3), а в алгоритме прыгать значение перестало только при alpha < 0.01.

HidUserZ В I2Pd возможно понадобится значение по меньше

Vort я просто вот этот коммит если что

Vort github.com/PurpleI2P/i2pd/commit/3458665df8c784a2c58873549dd56bac918f87e6

Vort про*

HidUserZ значит точно нужно высчитывать нормальное значение

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

HidUserZ слишком мало - начнет прыгать

HidUserZ занчение

Vort ну это я шумом и называю

HidUserZ в общем попробую подобрать

weko Самое простое - брать рейт за всё время, за (например) день, 3 часа, 10 минут. Тот что за 10 минут брать для определения подключения роутера к сети (нужно для вкл/выкл очистки роутеров).

weko Не имеет смысла усложнять, имеет смысл упростить

Vort 4 значения - это упрощение? O_o

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

weko За 5, 10 м 15 минут

HidUserZ там, кстати, по такому же алгоримту считается вроде

weko Vort: ну так тут же всё понятно

orignal ну это первое приближение

orignal типа если рейт низкий то у нас что то с сетью

weko Ладно если бы это были мудрёные значения, так тут тут же таже формула

orignal все счас начну релиз писать

HidUserZ уже релиз?

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

weko А не через пару часов

Vort для разных целей - разные усреднения получается? :)

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

orignal weko знаю

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

orignal но на все нет времени

orignal HidUserZ да

weko Vort: ну так понятно

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

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

weko Отлично!)

HidUserZ отлично

Vort хороший момент, когда много всего успели починить, но мало ещё успели поломать

orignal ну да потому что праздники были ))

orignal поломал я только SSU

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

weko orignal: просто с этим проблема - я уверен, что есть оптимальный алгоритм, но я его не знаю, чтобы смотреть среднее за последнее n времени

weko Vort: сейчас новые фичи будут только локальные наверн))

orignal да нет много чего есть делать

weko По крайней мере не будем ломать сеть))))

orignal времени нет )

weko Я вот думаю за c++ сеть....да вот времени нет:))))

weko Сесть*

weko Есть кто на 2.43? Сколько у вас там SSU ?

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

weko Я понимаю, вот и спрашиваю сколько мамонтов ещё

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

Leopold оххх

weko :)

Vort фильтров очень много понапридумано вообще-то

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

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

Vort какой-то узел много попыток делает, какой-то - мало

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

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

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

Vort если можно быстро получить точное значение, то так ли это плохо?

weko Ну я "на ходу" придумал как увеличить точность с незначительным увеличением потребления памяти. Ну, чтобы получить среднее за последние n времени

Vort что-то типа многоуровневой системы? усреднять усреднённое? )

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

weko Даааа

weko )))

weko Многоуровневая система!)

Vort что-то такое в DSP тоже используется

Vort если вспомню, то скажу

weko Могу описать примерно, но мне кажется ты понял

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

weko В случае среднего за 10 минут это не проблема, а вот есть брать сутки, то это же большое число

Vort dsprelated.com/showarticle/903.php

weko *что-то сложное*

Vort угу. это чуть из другой области. но суть близкая

weko Блять

weko Обрезалось

weko Тупой клиень

weko Клиент

HidUserZ Норм если tunnel creation success rate будет сходиться за 20 мин?

HidUserZ orignal: а Tunnel creation success rate учитывает длину тоннеля? ведь у тоннеля с длиной 3 будет в 3 раза меньше шанс чем у тоннеля с длиной 1

weko Не в 3 раза

weko Если у тебя шанс успеха каждого пира, предположим 0.5, то туннель 1 хоп - 0.5, 2 хопа - 0.25, 3 хопа - 0.125 и так далее

HidUserZ хорошо, не в 3 а в 4

HidUserZ суть та же

orignal нет не учитывает

orignal ему плевать какая длина

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

HidUserZ это нужно учитывать. если длина 3 то нужно инкрементировать 3 раза

weko HidUserZ: не та же

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

weko Например 0.4 * 0.4 * 0.3

HidUserZ суть в том, что tunnel creation success rate неправильно считается

weko Правильно

weko Он локальный

weko Считает твои туннели

weko Успех туннеля, в название не сказано успех соединения пиров

weko А именно туннеля

weko Туннель он един,

HidUserZ иначе его нужно использовать толкьо как относительный показатель

weko И не важно что он 1 или 8 хопов

weko Так он есть относительный

weko Никто не говорит что он у всех равный

HidUserZ короче при alpha = 0.005 картина такая

HidUserZ Uptime: 21 minutes, 40 seconds

HidUserZ Network status: OK

HidUserZ Tunnel creation success rate: 15%

HidUserZ вроде все ок

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

HidUserZ +

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

weko Так и надо сравнивать

weko Что вы мудрите

weko Не надо*

weko HidUserZ: сделай это как отдельное число, старое оставь

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

HidUserZ +

Vort HidUserZ: тут есть ещё особенность, о которой я говорил раньше - вместо времени тут используется просто номер точки

Vort может, это и не страшно

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

HidUserZ да, это я понимаю

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

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

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

HidUserZ если кто хочет опробовать - могу выгрузить в репу

Vort я потестирую

Vort можно просто линк на коммит

Vort кинуть сюда

weko Vort: каких лишних?

weko Почему лишних?

weko С чего вдруг полезное число стало лишним?

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

Vort нужно выделять главное

weko Так ты не смотри на то, что не нужно

weko Что за истеризм

weko Лишнее, лишнее

weko Не бесполезно = не лишнее

weko Кому? Мне нет.

HidUserZ weko: успокойся ))

weko Мне важно, что не удаляют важные цифры

weko На которые я смотрел

weko Меня беспокоит настойчивость Vort удалить то, что работает и есть не просит

HidUserZ оно не работает спустя неделю

weko Так цель другая этой цифры

weko Сколько раз сказать

weko Никто не говорил что оно показывает текущее значение

HidUserZ оно бесполезно спустя неделю

HidUserZ что противоречит твоим хотелкам

weko Оно наоборот более точное спустя неделю

weko Потому что охватывает больше данных

weko Ещё раз

weko Никто не сказал что показывает это число текущий процент

weko Это не написано

weko Там не написано "процент за последние 20 минут"

weko Значит там этого быть и не должно

Vort по такой логике и трафик там не точный

weko Трафик за 15 секунд вроде, не?

Vort но этого же не написано

HidUserZ так там не не написано что за 15 секунд

weko Или сколько там

weko Я не виноват что не написано

HidUserZ :D

HidUserZ почему не орешь лосю что неправильно алгоритм написан?

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

weko Секунду

HidUserZ а почему она не средняя за все время? почему именно 15 секунд? где это сказано?

weko HidUserZ: так потому что он и так это знает

HidUserZ кто он

weko Hi

weko ЛОСЬ

weko Hid

orignal че?

weko Да бомбит тут меня

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

orignal это почти 10 лет назад было ))

weko Они хотят удалить цифру туннелей и заменить на свою

HidUserZ orignal: тебе weko хочет сказать что у тебя подсчет трафика неправильно происходит

weko HidUserZ: ты клоун?

weko Я такого не писал

HidUserZ а что ты возмущается то ))

weko Я не доволен тем что хочешь удалить полезную цифру

weko Тем более кушать она не просит

weko Я не против новых, я против удаления старых

HidUserZ weko: последнее слово за лосем, удалять или нет

HidUserZ я всего лишь отправлю PR

orignal возможно

orignal я не помню как там ))

weko HidUserZ: ну так я не говорил что это это не так

orignal но вроде показывает правдоподобно

HidUserZ weko: говорил

weko Где?

weko Покажи

HidUserZ короче сейчас патч скину

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

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

weko Так что тот факт, что это не то, что ты ожидаешь не делает её бесполезной

HidUserZ weko: мое дело лосю RP написать, а нужен он или нет - обсуждай с лосем

weko Так он же в том числе читать будет (наверное). А если не будет, я скопирую и вставлю

weko Во всяком случае ты мне ответил, а значит был готов к обсуждению:)

HidUserZ 0xff.i2p/0I.tar.gz

HidUserZ так, неправильно собрал

Vort вместо того, чтобы линк на коммит гитхаба кинуть...

HidUserZ на форк?

Vort конечно

HidUserZ ну прост креды от git.community.i2p долго искать

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

Vort но с GitHub было бы намного быстрее

HidUserZ ))))

HidUserZ эт потом

Vort пришлось устанавливать patch :) но на удивление сработал сразу

orignal счас релиз сделаю посмотрим

Vort HidUserZ: у меня за 3 минуты до 18% догнало

HidUserZ смотрим дальше

HidUserZ у меня медленнее

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

Vort за следующие 2 минуты дошло до 20% и спустилось до 19%

Vort видимо, 19% - "реальное" значение

HidUserZ orignal: ну сделал скользящее окно

HidUserZ для Tunnel creation success rate

HidUserZ вот сейчас занимаюсь подбором коэффициента

orignal аааа я думал ты реальный рейт увеличил

HidUserZ Vort: а у тебя сколько клиентский тоннелей?

HidUserZ orignal: ахах ))

HidUserZ orignal: а реального рейта мы не знаем

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

Vort Client Tunnels: 50

HidUserZ Vort: не уверен что это как то скажется

HidUserZ просто повысится значение

HidUserZ но посмотрим

Vort HidUserZ: туннели сейчас ломаются постоянно

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

orignal надо у деда узнать как они меряют

HidUserZ Vort: ну да, зачем еще коэффициент крутить?

Vort HidUserZ: будет сходиться за разное реальное время

orignal zzz how do you calculate tunnel build success rate?

HidUserZ orignal: возможно строется тоннель в длину = 1 и смотрится успешность

orignal from startup or for last N mintes?

HidUserZ Vort: ну главная цель чтобы он не скакал

Vort HidUserZ: ок

orignal HidUserZ ну не это читерство

Vort тогда норм

orignal честный тест это когда длина 3

HidUserZ ну если 1 то проверяется шанс именно для одного узла

HidUserZ а на основе него же можно вычислить и для n

HidUserZ orignal: а у деда в вебморде есть этот показатель?

orignal не совсем

orignal для длины 1 у тебя 3 запроса и 3 ответа

orignal а для 3-х у тебя один запрос и 1 ответ

orignal но успешный только тот для которого в ответе прищли все нули

HidUserZ ну узел либо доступен либо нет, не важно же количество сообщений

zzz orignal, what we publish in the netdb and collect on stats.i2p is a one-hour bucket. We don't have any stat in our UI, but if we did, maybe last 10 minutes would be right

orignal HidUserZ где то есть

orignal zzz, where in netdb?

orignal zzz we want to make sure that our figures match yours, e.g. we calculate the same thing

zzz periodically we put in:

zzz stat_tunnel.buildExploratoryExpire.60m = 1.00;1.00;109.47%;79.86;

zzz stat_tunnel.buildExploratoryReject.60m = 5,054.98;7,516.41;95.47%;6.42;

zzz stat_tunnel.buildExploratorySuccess.60m = 4,105.44;7,066.70;87.18%;13.73;

zzz stat_tunnel.participatingTunnels.60m = 1,636.27;2,335.14;103.33%;555;555;555;

zzz but I'd have to get back to you on what that all means

zzz jrandom stuff

zzz we don't publish stats in netdb for client tunnels, would expose too much

HidUserZ Vort: скачет?

orignal hmm

Vort HidUserZ: до 23% дошло. теперь опять вниз идёт. наверно, надо больше сглаживать

HidUserZ Vort: значит да

HidUserZ уменьшаю до 0.001

orignal is there way you can see client tunnel build rate?

zzz no. not in our UI, not published in the netdb

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

orignal I remeber you mentioned this rate somewhen

HidUserZ Vort: понял

zzz if you want to publish in the netdb, so i2pd routers will be included in the stats.i2p graphs, I'll figure it out for you some time

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

HidUserZ калибровка называется

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

weko Какой толк тогда

HidUserZ не факт

weko Или не надо будет?

HidUserZ я не вижу причин

orignal I can do it if you tell me the format

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