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

fffff а как там дела с тем, что клирнет пиры почти никогда не ставятся на конце туннеля? видел на форуме это. сам не пользуюсь игг, но есть ли вообще какой-то плюс от игг для ш2зв, если я за натом? раньше

fffff помню у ацетона был сайтик, где можно было посмотреть кол-во игг роутеров в ш2з, а сейчас не нахожу

orignal как это не ставятся? они всегда ipv4

orignal специально посмотрел у себя концы тоннелей

orignal нет далеко не все с ygg адресом

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

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

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

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

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

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

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

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

orignal бывает еще проблема на роутере

orignal а нас на работе дропы пакетов в совновном на циске происходят

orignal Vort а у поляков на serv00 не пробовал?

orignal для тестов вполне подойдет

relaybot 13apophis: Vort, когда/если твой большой буффер переполняется, что происходит ? Ты дропаешь рандомно или хвост ?

relaybot 13apophis: Vort, в принципе, учитывая твою имплементацию и возможный РЕД/АРЕД, я бы склонялся к той, где меньше зависимостей от различных вариантов железок и таймеров. <clipped message>

relaybot 13apophis: Из этого исходит, РЕД сильно зависим от гранулярности таймера и ХЗ как разное железо будет гарантировать таймерную стабильность. Большой буфер, имеет мен <clipped message>

relaybot 13apophis: ьше зависимостей чем РЕД. Вот и смотри по логике. Вряд ли РЕД даст сильные преимущества(?), и если нет, то твой метод в данной ситуации более подходит.

Vort apophis: перёд дропаю (самые старые). мысль в том, что у свежих пакетов выше шанс оказаться полезными

Vort "а у поляков на serv00 не пробовал?" - да я вообще не искал хостинг, но если решусь, то попробую

relaybot 13apophis: ясно, Таил Дроп значит

Vort tail - это хвост

Vort head drop

Vort apophis: размер же буфера в моей реализации зависит от RTT. дропается всё, что старше 3*RTT

relaybot 13apophis: > ясно, Таил Дроп значит

relaybot 13apophis: я про очередь говорил/queue

Vort ну да, очередь сообщений. по-моему и буфером её тоже называют

relaybot 13apophis: в очереди, ты дропаешь естественно самый старый элемент

Vort я вот такое описание находил: linkmeup.gitbook.io/sdsm/15.-qos/5.-predotvrashenie-peregruzok-congestion-avoidance/0-tail-drop-i-head-drop

relaybot 13apophis: главное что ты дропаешь самый старый и ето верно

Vort по той ссылке, что я кинул, картинка с Head Drop

Vort а вот с RED там, по-моему, сделать head drop не так просто

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

relaybot 13apophis: тры смотрел в той статье про АРЕД ? это единственное улучшение РЕД, которое бы стоило посмотреть ( если бы ты решил менять все на РЕД )

relaybot 13apophis: вот интересно про TD/HD и пример с большим буффером: reddit.com/r/networking/comments/jtf9y1/why_do_most_queue_management_algorithms_do_tail

Vort глянул статью: "Both of the above advantages of ARED come with the disadvantage that the input of the target queue size beforehand means that there is a tradeoff between small queuing delay and stability"

Vort именно о той проблеме пишут, которую я решал, устанавливая размер буфера зависимым от RTT

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

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

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

relaybot 13apophis: еще один довод, что НЕТ адекватного решения совсем. РЕД не панацея никак, пока длительное тестирование не докажет обратное.

relaybot 13apophis: кстати, откуда ты взял 3хРТТ ?

Vort целился, чтобы "поглотить" всплески RTT - чтобы выкидывать только тогда, когда действительно что-то пошло не так

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

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

relaybot 13apophis: т.е. опытным путем определил 3

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

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

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

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

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

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

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

Titlacahuan Vort: с таким сетевые изменений нужно делать множество опитов и смотреть на их статистически

Titlacahuan например 20 опитов

Vort Titlacahuan: с реальными узлами сети или в виртуальной машине?

relaybot 13apophis: Vort, случаи с Ретрансмит и Трансмит с одим АСК и их влияние на РТТ .. смотрел ?

Titlacahuan с реальными, в тестовой сети можно и менше

Titlacahuan когда я работал над стримов делал по 20 в тестовой сети

Vort apophis: RTT считается только с чистыми данными, если пакет был переотправлен, то он исключается из расчётов

relaybot 13apophis: хорошо

Vort if (ts && !it1->second->numResends) в SSU2Session.cpp

relaybot 13apophis: > Titlacahuan: с реальными, в тестовой сети можно и менше

relaybot 13apophis: это потому что много и2пд роутеров на одном ТСП стаке это плохо для тестовой сети, да ?

Titlacahuan нет, за то что условия в тестовой сеть более статичные

Titlacahuan с tc qdisc можно добавить терянию пакетов но всё равно

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

relaybot 13apophis: я про другое спросил.

Titlacahuan сколько эсть много?

Titlacahuan я тестовал с 16 контейнеров

relaybot 13apophis: по твоему мнению, тест сеть из 10 роутеров на ОДНОМ компутере с одним ТСП стаком и 10 роутеров на 10 компутерах, что лучше ?

Titlacahuan 10х10 конешно но не думаю что с 10 будет замечаемая разница

relaybot 13apophis: вот именно этот ответ, я и хотел слышать. Спасибо за подтверждение !!!

Titlacahuan зависит от железо

Titlacahuan на виртуалках плохая идея

relaybot 13apophis: конечно зависит

relaybot 13apophis: да, я именно против виртуалох и выступал

relaybot 13apophis: один знакомый, пробовал на "ХЕН" даже, но я не знаю если это полноценный тест.

Titlacahuan с контейнеров немножко лучше

relaybot 13apophis: я смотрел на ГИТ мануал с кубернетами

relaybot 13apophis: > Vort: RTT ведь динамически определяется и при перегрузке может начать ползти вверх

relaybot 13apophis: похоже, что ты сделал все как полагается тут ( *Karn ):

relaybot 13apophis: 1.Ignoring Retransmission RTTs: When a packet is retransmitted, its RTT is not used to update the timeout value.

relaybot 13apophis: Recalculating Timeout after Successful Transmission: Once a packet is successfully acknowledged, the new timeout is calculated based on the most recent successful transmission's RTT.

relaybot 13apophis: 2.Cumulative ACKs: When a cumulative ACK acknowledges multiple packets, the sampleRTT is typically calculated based on the RTT of the earliest unacknowledged packet in the window.

relaybot 13apophis: 3.Timeout backoff: You can also Implement timeout backoff to limit the growth of the timeout value in case of packet loss.

relaybot 13apophis: SRTT (?) и другие... вряд ли сильно изменят ситуацию.

relaybot 13apophis: Vort: cs.toronto.edu/~marbach/COURSES/CSC358_F19/tcp.pdf Good read :)

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

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

Vort RTT при слабой нагрузке был 100мс, теми же пингами измерил

Vort по логике, лимит в 3*RTT должен был бы ограничить задежку до 300мс, но что-то пошло не так

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

orignal есть куча багов

orignal я же предлагал в стримы onDrop сделать и там что то с RTT

orignal или тоннели прееключать

Vort orignal: стримы - это отдельный вопрос

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

orignal а они там есть?

orignal я не уловил мысль как они должны сработать

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

orignal только если onDrop есть

orignal а если нету то нет

Vort то есть, получается 1.5*RTT, а такое значение уже близко к естественным колебаниям

Vort это я просто про выбор константы говорю

orignal ты про RTO?

Vort я про m_MsgLocalExpirationTimeout и m_MsgLocalSemiExpirationTimeout

orignal я x3 чего там onon написал

orignal не разбирался еще

orignal некогда

Vort это я писал

Vort уже даже не помню, когда

orignal ааа

orignal ну я все цифрф брал от фонаря или что дед сказал

Vort это я выбирал константу, а теперь вспоминаю, почему выбрал именно такую )

Vort "<~orignal> а они там есть?" очередь SSU2 есть же, я о ней говорю. где-то ведь данные эти 2+ секунды болтаются

Vort вот и надо выяснить, где именно

orignal в очередях ясен пень

orignal где ж еще

Vort я делал тест мой локальный узел 1 -> 2RRY -> мой локальный узел 2

relaybot 13apophis: вы смотрели как тор сделали алгоритмы ?

Vort и откуда-то конские задержки вылезли при больших пинг пакетах

Vort (я отойду)

relaybot 13apophis: orignal, ты в курсе, как вы вычисляете РТТ ? он же не равен у вас просто sampleRTT ?

Vort apophis: по-моему, вначале баги надо выловить, а потом можно и в код Tor смотреть

Vort apophis: херово RTT вычисляется, если честно. но как сделать лучше - не очевидно

Vort сейчас семплы просто через EWMA пропускаются

Vort в итоге, степень сглаживания зависит от частоты семплов

Vort это я про SSU2 говорю. что там в стримах - давно не смотрел

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

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

Vort "<~orignal> в очередях ясен пень" очереди на всех трёх узлах да ещё и на разных уровнях. выловить чётко надо проблему

Vort решил ещё разок воспроизвести проблему с уползающим вверх пингом

Vort первым делом проверил очереди на вкладках транспортов. нет там очередей

Vort затем посмотрел на вкладку с дестинейшеном. на удивление, там тоже порядок - RTT 100мс показывается

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

Vort paste.i2pd.xyz/?6834646b8dda2d32#84xzaVHR6SeM9B6mWxPDfE6TTxvuLiLqkbXi3yoRadK3

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

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

relaybot 13apophis: Estimated RTT = (1- α) * Estimated RTT + α * Sample RTT

relaybot 13apophis: DevRTT = (1- β) * DevRTT + β * |Sample RTT - Estimated RTT|

relaybot 13apophis: Time-out Interval = 4 * DevRTT + Estimated RTT

relaybot 13apophis: я думал вы так считаете ( вместо отпроса всех кто старше 3*RTT ).

Vort так дропы и расчёт RTT - это разные вещи

Vort одно от другого зависит, да

Vort в SSU2 сделано так, как в первой строчке написано

relaybot 13apophis: ты сам сказал, что дропаешь все что > 3*РТТ. это и есть таймаут в этом аспекте

Vort m_RTT = SSU2_RTT_EWMA_ALPHA * rtt + (1.0 - SSU2_RTT_EWMA_ALPHA) * m_RTT;

Vort таймаут - это RTO, скорее всего

Vort m_RTO = m_RTT*SSU2_kAPPA;

Vort RTO - определяет, когда надо делать перепосылку пакета

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

Vort когда он не отправлен, а болтается в очереди - тогда работают дропы через 3*RTT

relaybot 13apophis: да, РТО похоже

Titlacahuan это стандартное Рино, забыл номер РФЦ

relaybot 13apophis: да Рено

Titlacahuan datatracker.ietf.org/doc/html/rfc6298

Titlacahuan это тоже ползуется в жаве datatracker.ietf.org/doc/html/rfc5681

Titlacahuan но переделвли на researchgate.net/publication/2381299_TCP_Westwood_congestion_control_with_faster_recovery

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

relaybot 13apophis: altready implemented in java router ?

Titlacahuan да, несколько лет назад

Titlacahuan ~2018-2019

relaybot 13apophis: тогда я совсем ничего не понимаю, разве и2пд группа про это не знала ?

Titlacahuan для стримов, не знаю если в SSU2

relaybot 13apophis: аааа.. теперь ясно.

relaybot 13apophis: понял да

Titlacahuan в SSU1 сделано, и думаю тот самой код пользуется в 2

Vort только вот, насколько я помню, семплы RTT из стандарта отличаются от того, что сделано в i2pd в SSU2

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

Vort в SSU2 i2pd же - что пришло - то и семпл

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

Vort вот те расчёты с альфой и бетой то есть

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

Titlacahuan в каком стандарте так?

Vort я сейчас поищу

Titlacahuan в Рино сэмпл когда прийдет ак

Titlacahuan я не слышал об стандарте где усредняют

Vort Titlacahuan: datatracker.ietf.org/doc/html/rfc6298

Vort "Traditionally, TCP implementations have taken one RTT measurement at a time (typically, once per RTT)."

Vort Additionally, when multiple samples are taken per RTT, the alpha and beta defined in Section 2 may keep an inadequate RTT history. A method for changing these constants is currently an open research question.

Vort вот эта inadequat`ность в i2pd сейчас и реализована

Titlacahuan но это можно решить и без усреднения

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

Titlacahuan хватит брать сэмпл лишь раз в РТТ

Titlacahuan зависит и от честоту ак-ов

Vort может вообще не прийти ни одного семпла за RTT. тогда считать прошлое значение за семпл что ли?

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

Titlacahuan нет, тогда не меняется прогноз (estimate)

Titlacahuan да, точно так гарантируется отсуствие резких изменений

Vort мне казалось, что при использовании всех собранных данных, результат должен быть точнее, но нашёл вот такой ответ на StackExchange: networkengineering.stackexchange.com/a/57878

Vort "As the next thing we do with the RTT series is smooth them, it doesn't make much difference if we have the full set or the subset."

Vort "Having times for 100% of the segments as opposed to one-per-send-window doesn't make the predictions significantly better, because the real issue is with unpredictable sudden changes such as links going down or high-usage streams starting."

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

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

orignal а конкретно что выкидывать?

Vort вычисленные из ack`ов семплы RTT

Vort брать первый попавшийся, ждать RTT, потом ещё один, опять ждать

Vort а дополнительные не считать

Vort да я понял, как алгоритм сделать

orignal это мы про SSU2 счас?

Vort да

orignal а кого дропать?

Vort в стримах похожее надо делать, но то потом

Vort сейчас покажу, о каком куске кода речь

Vort github.com/PurpleI2P/i2pd/blob/8e1fb8ca9fd79654a2d3f0c274b08b84265be952/libi2pd/SSU2Session.cpp#L1817-L1826

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

orignal его кстати тоже не я писал

orignal я так понимаю это усреднение

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

Vort иначе получается хрень. то есть, сейчас хрень написана

Vort а написана хрень потому, что до этого была ещё бОльшая хрень ))

orignal само собой

Vort так и идёт развитие - от одной хрени к другой :)

orignal раньше просто было посдении

Vort а ещё там время не монотонное...

нубус Где есть документация для библиотеки libi2pd? Хочу сделать простенький клиент с подключением к стриму

Vort зачем библиотека? может проще через SAM подключиться?

нубус так для SAM нужен роутер установленый

нубус если делать например чат клиент, то SAM одного не хватит

orignal нигде нету

orignal сэма хватит для любых нужд

нубус так для сэма нужна еще прога роутер, не?

Vort libi2pd, как я понимаю, это и есть роутер, только в виде либы

нубус да

orignal нужна естественно

orignal но роутер он же обслуживает кучу вещей сразу

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

нубус Типо предлагаешь стартануть libi2pd роутер и через любую SAM либу подключатся?

Vort мне кажется, что с libi2pd ты просто задолбаешься

orignal запустить роутер

orignal а дальше через сэм

orignal libi2pd это крайне специфическая вещь

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

нубус с i2p лучше чем в Tor'ом в России?

orignal ну россияние не жалуются

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

Orion Возник вопрос) В цепочках туннелей, например hbBb X ⇒ irTO N указаные первые четыре буквы это Router Ident?

Orion Но отправитель/получатель пакетов не указан же. Только промежуточные?

orignal 4 буквы это от base64 роутера

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

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

orignal разумеется тебя в списке этом нет

Orion Спасибо. Спустя столько лет возник наитупейший вопрос)