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

Vort Anonymous: yes. with latest commit timeouts are different and disconnect by local node happens earlier than by remote node

Vort so when my IRC client reconnects, old "ghost" connection is still active and client can't take that nickname

Vort добрался я наконец-то до визуализации параметров стримов:

Vort paste.i2pd.xyz/?c149352834461a36#EpcWV6BaGbBFRPWBCLSm29b42vM7pXHcMzFY3KDvXKPo

Vort на графике отображены данные 90-секундного iperf3 теста через 1+1 / 1+1 рандомный хоп

Vort ось x - время теста, ось y - задержки

Vort серые точки - хорошие семплы RTT, красные точки - пропущенные семплы RTT (обычно перепосылки)

Vort синяя линия - сглаженная оценка RTT (m_RTT), пурпурная линия - m_RTO

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

Vort как видно, при таком расчёте среднего RTT (с помощью функции минимума для пачки), расчитанное значение RTO (1.5 * RTT) получается "тесноватым". хорошо это или плохо - сказать пока сложно

Vort ещё одно наблюдение: никуда задержка при таком методе congestion control не уехала. были, правда, попытки на 40й и 60й секунде, но довольно быстро ситуация вернулась в норму

onon1 Vort: ещё одно наблюдение: никуда задержка при таком методе congestion control не уехала. были, правда, попытки на 40й и 60й секунде, но довольно быстро ситуация вернулась в норму

onon1 Какая задержка имеется в виду? И какой новый метод congestion control?

Vort усреднённая m_RTT. метод тот, который сейчас в основной ветке

onon1 А куда она должна была уехать?

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

onon1 Через 6 хопов пусти, заметишь.

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

Vort надо больше тестов делать, согласен

onon1 Он работает на переполнении и потерях пакетов.

onon1 На 6 хопах потери пакетов довольно частые.

Vort 6 хопов - это обычные 3+3 сервер 3+3 клиент?

onon1 Да

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

Vort но это опять же неточно

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

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

onon1 Ты бы лучше разобрался, почему стримы зависают. Это на данный момент самый противный баг, имхо.

onon1 Когда клиент не может отправить аск, и пишет в лог что лизсет не подтверждён

onon1 Хотя при этом все туннели на клиенте и на сервере живые.

Vort интересно. но вообще всякого рода подвисаний много

Vort это на какой примерно конфигурации вылазило?

Vort сколько хопов и какой пинг?

onon1 На любой

Vort вполне может быть баг

onon1 Сделай длительный тес и поймаешь

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

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

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

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

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

onon1 Потому что туннели не живут вечно, и любой стрим должен нормально переживать смену туннеля.

Vort дольше надо прыгать и "разумнее"

Vort ну это самый простой вариант

Vort а вообще надо задумываться на будущее о многотуннельной системе. если она вообще возможна

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

Vort окей, понял

Vort вот график для 3+3 хопов: paste.i2pd.xyz/?e9c17de5729ad183#EmM6M873pSFV2dUCQ45xjhmr8hwKp8QBy776Z1mLqXbm

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

Vort попробую попасть на хороший туннель и собрать данные по нему

Vort пока что ещё один "грязный" результат: paste.i2pd.xyz/?cbf360d08c311b96#33ZUTki991uYNLpku1tuW7Uks97HXvW3vw5xaJMn6vBA

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

Vort на 6 (3+3) хопах слишком много хаоса - туннели меняются быстрее, чем я успеваю заметить какую-то закономерность в регуляции. скину три графика на всякий случай и попробую на 4 (2+2) хопах собрать данные

Vort paste.i2pd.xyz/?f392c6abf4029bb9#3fUTemhdrfianmG1B93CByZGCodu599zt9MJkEnkgcax

Vort paste.i2pd.xyz/?3f1e0d979f73be7c#7UsT7LCFf6FnJ7omWQcGiZGsuXtF9dm3vYZmauaF3roy

Vort paste.i2pd.xyz/?75e9d7b357537b0e#J7iEhAtGkmHfT8QTWuWTnWAi2zrm2kfXNSfZ4vmjVnYL

Vort на 2+2 хопах картина намного яснее:

Vort paste.i2pd.xyz/?e7fdae0b11083595#BoaoptWtbJpgdT7TqPRXdDJdLYiwKBpYaEcwrWRZBc94

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

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

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

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

Vort paste.i2pd.xyz/?3e99b257066c491c#4bDkkqGTZgxM7aMns3CFGRT8j6RfVCVAkVryPTmfy4D6

Vort вот это график большой проблемы. горы слева при нормальном алгоритме congestion control быть не должно

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

Anonymous Vort: I think I had something important to say related to qBittorrent/i2pd but I seemingly cannot recall what it was.. you were unreachable for a few days, sadly

Vort Anonymous: results of your tests with client_test maybe?

Anonymous no

Vort did you found what is happening by looking in logs?

Anonymous There aren't logs lol

Anonymous Nothing goes in logs

Vort did you specified "-f log.txt --alert_mask=all" as I said?

Anonymous Found it, 1min

Anonymous Vort: to qBittorrent?

Vort no, in client_test

Anonymous No, I said I don't use it yet

Anonymous I have to compile it and probably apply some patches becaues I'm not on Shit/Shitinux

Anonymous Vort: I'll send in DMs

Anonymous Vort: most of it is related to qBittorrent

onon1 Vort: вот это график большой проблемы. горы слева при нормальном алгоритме congestion control быть не должно

onon1 Для этого cc - это норма. Он же на переполнение работает. Предположу, что это он в твой "длинный" буфер всё складывал. А если бы там был RED он бы начал дропать пакеты и окно начало бы схлопываться.

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

Vort иногда (или даже часто) этот алгоритм нормально работает

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

Vort она сейчас лучше, чем раньше, но всё равно с проблемами

onon1 Ну сделай тестовые туннели через реальную сеть с узлами с твоими длинными очередями, и посмотри на результат.

Vort дальше уже на основе надёжного алгоритма сглаживания RTT можно дальнейшие улучшения делать

Vort я понимаю, что этот алгоритм с проблемами, но не из-за буферов

onon1 Ну он же на переполнение буфера работает, как он ещё узнает, когда окно заполнилось?

onon1 От полного забивания всех буферов в туннеле спасает только рэндом лосс

onon1 Но тут получается неполная утилизация канала.

Vort он детектирует резкие лаги (а переполнение это или нет - ему всё равно)

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

Vort примерно поровну

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

onon Если задержки будут расти достаточно плавно - нет.

onon1 Я, кстати, пытался сделать пэйсер через std::this_thread::sleep_for (std::chrono::milliseconds(10)); но это почему-то тормозит все стримы одновременно, вместо одного.

Vort так поток общий вроде

onon1 Может знаешь как можно "усыпить" отдельный стрим?

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

onon1 Ясно.

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

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

onon1 Да, я работаю над этим, но на больших RTT медленно реагирует.

pupok_temp Приветствую, вопрос по ноде, разве транзит не должен постепенно разгонятся пока не достигнет лимита в конфигурации? моя ситуация:аплинк 300мбит, лимит на 150, сейчас транзит 45 и не поднимается. не ругайте если я нуб

Vort на больших RTT всё медленно, как я уже понял

Vort pupok_temp: i2p не идеален. может, когда-то так и будет. но пока что для навороченных конфигураций стоит несколько узлов запускать (если хочется помочь сети)

Vort сейчас больше проблема, что юзеры скорость L ставят :)

Vort при том, что могут намного больше пропустить

pupok_temp Сразу видно читаешь en) принято, другие пути увеличения есть?

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

Vort нет, не читаю, подсказал "кое кто"

pupok_temp может выставление сделать авто, изменились скорость, взяли 50% например и установили лимит, и такие измерения делать при запуске

Vort pupok_temp: флудфил поставить если ещё не стоит. и если узел соответствует требованиям (но думаю, что соответствует)

Vort pupok_temp: так у кого-то помегабайтная тарификация допустим

pupok_temp флудфил стоит. измерение*

Vort кто-то не может (и им мешать не надо), а кто-то не знает, что так можно (и вот им надо бы как-то рассказать)

onon1 pupok_temp, ты надеюсь дефолтное количество транзитных туннелей увеличил?

Vort кстати да, 100000 лимит стоит поставить

Vort pupok_temp: и ещё обновиться на последний коммит (у меня транзит вырос по сравнению с релизом)

pupok_temp транзит стоит 65535

pupok_temp лимиты по ядру x10 от дефолта на freebsd

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

Vort onon1: буферы и на релизе будут замедлять. на то они и буферы

pupok_temp не стану, дождусь лучше реализацию от вас, протестируете и полетит, у меня последняя и так стоит

Vort если пихать данные бездумно)

onon1 Я надеюсь, вы всё таки проявите благоразумие и выпилите длинные буфера и поставите RED

pupok_temp заебал меня т9

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

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

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

pupok_temp или на крайняк спросить пользователя пр первом запуске

onon1 Но ты решил эту проблему "не оптимальным" способом.

pupok_temp я? или о буферах разговор

onon1 Который будет создавать другие проблемы, решая эту.

onon1 pupok_temp, я ворту.

Vort onon1: ну вот моё требование к размеру буфера - чтобы лаг был не больше 2 секунд. какая альтернатива? взять какое-то фиксированное значение? так найдутся случаи, когда оно ещё больший лаг даст

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

onon1 Ну чем тебе RED не угодил? Все так делают и не выпендриваются.

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

onon1 А вот то что внутри роутера у нас пакеты вставляются срабу большими пачками, и могут всё-таки его переполнить, так это не проблема REDа

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

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

onon1 Это плохая идея

weko onon1: почему же

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

weko Да и я знаю какой

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

weko В стримах баг

weko Вероятно

weko onon1: это другое

Vort (я отойду)

weko Мы уже нашли различия пока обсуждали

onon1 Везде, где есть несколько претендентов на ресурс, нужно делать небольшие очереди.

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

onon1 Ну, а если на том конце кто-то медленный

onon1 Куда данные складывать?

weko Ну тогда окно не расширяется

weko Дропать

onon1 Плохая идея

weko ну и почему

onon1 У нас трафик всегда идёт не равномерным потоком, а бертами

onon1 бёрстами

weko Только в стримах и это надо бы исправить

onon1 У тебя половина пакетов будет дропаться

onon1 И нихера работать не будет

weko Но это исправляется буфером треда

weko Или нет

weko Нет но нужно просто исправить такую отправку

weko А хотя....

onon1 То что нужно чинить SSU2 я не спорю

weko Да, надо исправить

weko И тогда проблем не будет

onon1 Но я пока не добрался, завис на стримах

weko onon1: это в стримах отправка пучками

weko Пока не знаю, что делать с этим

onon1 Ну вот из-за архитектурных ограничений, я пока и мучаюсь.

weko Равномерно отправлять надо, вроде как. Но это больше нагрузки на переключение тредов

orignal давайте результативную часть