~R4SAS
~villain
@onon
&N00B
+Most2
+Xeha
+acetone
+r00tobo
+relaybot
+whothefuckami
AreEnn
KabaOS
Nausicaa
Vort
anon2
b3t4f4c3
flumental
karamba_i2p
nemiga
not_bob
orignal
poriori
profetikla
segfault
soos
tolik
un
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
на графике отображены данные 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
на 2+2 хопах картина намного яснее:
Vort
скорее всего, слева - регулировка дропами, справа - регулировка задержками/таймаутами
Vort
хотя в случае накопления пакетов в очереди от роста окна, мне кажется, RTT поднимался бы постепенно
Vort
тут же видны всплески, хоть и разные
Vort
думал уже выключать тестовые узлы, а хорошо, что решил ещё один раз собрать данные
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
давайте результативную часть