IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#dev
/2024/03/16
~R4SAS
~villain
@onon
&N00B
+Most2
+Xeha
+acetone
+r00tobo
+relaybot
+whothefuckami
AreEnn
KabaOS
Nausicaa
Vort
anon2
b3t4f4c3
karamba_i2p
nemiga
not_bob
orignal
poriori
profetikla
segfault
soos
tolik
un
Vort Anonymous: traffic drops are most likely not related to SAM, I expect the same to happen with regular destinations (in fact I saw similar bug when testing recent changes)
Vort "<~orignal> <zzz> new contender ~SN8" - 4 штуки у меня
Vort "Tunnel creation success rate: 26%" - неплохое значение (для последнего времени) у моего узла сейчас
Vort догадываюсь, что коммит 161ff357 как-то относится к клонам, но что именно он делает? есть смысл обновлять узел?
orignal этот коммит просто бага
orignal но к клонам да может относиться
orignal я начал разбираться с клонами и нашел багу
grimreaper make new TLD
Anonymous Vort: but it works for like 15-45 minutes, do you do non-stop traffic for that long with regular destinations?
Vort Anonymous: looks like problem appear when tunnels change. in such case you don't need long activity, you need just to be (un)lucky
Anonymous Why? Who's fault is it?
Anonymous It does not recover
Vort bugs, as usual
Anonymous it stays broken
Anonymous of course there's bugs, orignal made them
Vort maybe that's another problem then - in my case recovery happened after ~8 seconds
Vort also I've found two programs for testing - iperf3 and echoping - they can produce long time loads
Vort Anonymous: do you mean stream stays broken or entire destination breaks ?
Anonymous yeah I think iperf3 is probably best for easy stable loads like that, but I found it to be too complicated, maybe?
Anonymous Vort: I'll copy-paste the issue from e-mail
Vort just two commands: iperf3 -s 127.0.0.1 --timestamps="%%H:%%M:%%S|" / iperf3.exe -c 127.0.0.2 -t 20 -i 0.25 --timestamps="%H:%M:%S|"
Vort and corresponding destinations in tunnels.conf
Anonymous this was an e-mail sent to qbittorrent+libtorrent devs, look at issue #2
Anonymous "2nd issue:
Anonymous Vort: interesting!
Vort Anonymous: you can test torrents with i2p java. that way you will know if problem is with i2pd or libtorrent
Anonymous no Java on my land!
Anonymous Vort: you got libtorrent's test client to work with I2P?
Vort yes
Anonymous > This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions < This is stupid
Vort yes
Anonymous Is this how Linux also deals with issues? If no one is interested, then issue is "fixed"?
Anonymous Stupid solution
Vort this is one of the reasons why I i'm not very active in libtorrent development
Vort I don't want my work to be randomly thrown away by bot
Anonymous libtorrent really is libtorrent
Anonymous Anyways.. I didn't forget, I will do i2pd with debug symbols to help find SAM-crash bug
Anonymous Just not for a long time probably, my eyes...
Vort onon: на всякий случай спрошу: знаешь про ru.wikipedia.org/wiki/Теория_управления ?
Vort у меня подозрение, что congestion control - это регулятор, поэтому соответствующая теория может быть полезна
Vort ну и второй вопрос - знаешь ли про en.wikipedia.org/wiki/Project_Jupyter или en.wikipedia.org/wiki/Wolfram_Language ?
Vort значения, зависящие от времени, удобно представлять в виде графиков и подобные системы могут с этим помочь
Vort сделаю, кстати, сейчас одну визуализацию - по оценкам RTT для SSU2 ipv4 сессий, может что-то интересное найдётся
onon Vort, можно я не буду отвечать?
Vort странно, но ладно
Vort я беспокоился, что перепосылки могли куда-то исчезнуть после моих изменений. но нет, для них просто не было подходящих условий
Vort сейчас кто-то начал очень упорно тащить торрент по TCP и в i2pd отправок было на мегабайт/сек (3) больше, чем транзита (2)
Vort это позволило мне понаблюдать за новым внешним видом шипов переотправок и результат мне кажется очень даже хорошим
Vort удачный компромисс между хаотичностью и нагрузкой на процессор
orignal_phone Ну что сказать? С мобилы транк работает почти идеально
orignal_phone Хотя и через опсоса
Vort заметил я эффект скатывания оценки RTT для стримов, о котором onon говорил. для этого IRC чата был RTT около 100мс, при том, что все туннели были с пингом около 100мс. то есть, минимум 200мс должно было бы быть на стриме
Vort что касается механизмов, то у меня есть ещё два подозрительных места: rtt = 1; и m_RTT = routingPath->rtt;
Vort откуда берётся RTT у SharedRoutingPath - я пока что не знаю
Vort а, уже нашёл. i2p::garlic::GarlicRoutingPath{m_CurrentOutboundTunnel и так далее. нормальный источник вроде
Vort хотя он не обновляется, вроде - странно. но всё равно не должно быть сильно страшно
Vort а чтобы не писать "sent from the future" - монотонные часы воткнуть надо. и если future даже с монотонными пролез - то не надо rtt = 1 делать, надо просто выкидывать такой семпл нафиг
Vort orignal: можно вопросы по стримам задавать?
orignal задавай
orignal shared routing path он ставится
Vort да я уже сам допёр. покажу скоро коммит
Vort хотя вопрос там спорный
orignal давай
orignal меня целый день не было
Vort короч это моё предложение по решению проблемы порченных семплов rtt, обнаруженной onon
Vort там немного мутноватая ситуация, когда самый первый семпл испорчен, но я думаю, первый можно и порченый взять
Vort дальше выровняется само
orignal а где само значение numResends используется?
Vort else if (!sentPacket->numResends && rtt >= 0)
Vort примерно как и в SSU2
Vort оттуда стащил идею )
orignal ну так оно как bool испольщется а не само число
Vort ну да
Vort думаешь об экономии 3 байт? )
orignal может тогде лучше bool resent ввести?
orignal нет только о логике
orignal чтобы код выражал логичнскую мысль
Vort окей, сделаю
Vort я четвёртый раз этот код переделываю и поэтому очень боюсь накосячить
orignal да вроде нормально
orignal давай PR
orignal все
orignal и сегодня на илите обновлю
orignal рестарт илиты через 10 минут