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

Vort за ночь всего два случая лагов SSU2 у высокоскоростных узлов заметил (>500 сообщений в очереди)

Vort в основном тупят медленные узлы (10-100 сообщений)

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

Vort кстати, это хоть и совпадение, скорее всего, но с этим моим патчем рейт (TCSR) у меня сейчас 20%

Vort в последние дни обычно 10-15% было

` <Vort> про mail.ru гадости слышал, а про yandex пропустил, наверно

` Кажется на хабхабр была статья, как Яndex слил силовикам ВСЮ ПОЧТУ ЗА 5 ЛЕТ одного адвокатишки, хотя силовикам столько вроде бы и не нужно было.

orignal с твоим изменением?

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

Vort Uptime: 17 hours, 21 minutes / Tunnel creation success rate: 18%

orignal кстати имей ввиду что для сооющение Tunnel там таймтсам не наш а отправителя

orignal аналгично и Gralic если кидаешь какой то роутеру напрямую

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

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

onon1 Устанавливать соединения дорого, особенно через н��ты. Дропать их по малейшему чиху, вероятно плохая идея. Либо согласованное завершение, либо по таймауту при отсутствии ответов.

orignal а все понял

orignal а как их не дропать если очередь забилась?

onon Дед всё правильно говорил, как очередь подходит к лимиту, нужно дропать случайные пакеты

onon Если оверлимит, то само собой, всё лишнее

onon Насчет, дропать случайно ближе к концу очереди или по всей длине очереди пока не скажу, изучаю вопрос.

onon en.wikipedia.org/wiki/Weighted_random_early_detection

onon Vort, сможешь нам WRED реализовать?

orignal а надо?

onon Надо Федя, надо.

onon Чтобы мы могли реализовать нормальный congestion control на уровне стримов

Vort onon: сомневаюсь, что в java лимиты очереди по времени, как я сделал, так что их подход напрямую не подходит

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

Vort а если узел не тупит, то ничего вообще дропать не нужно

onon Я про яву вообще не говорил. WRED это, похоже, на сегодняшний день. самый оптимальный способ как-то сообщить отправителю, что мы перегружены.

onon Все нормальные маршрутизаторы делают так.

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

Vort "Я про яву вообще не говорил" - "Дед всё правильно говорил" - у него могут быть свои причины экономить буферы/очереди, в i2pd пока что таких причин не видно

onon Нам до релиза было бы неплохо это всё-таки сделать. Вне зависимости от причин образования очереди.

onon Даже когда мы найдём и пофиксим причины нынешних тормозов, WRED не потеряет актуальность, а на данный момент это решит проблему с дропом коннекта.

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

Vort ты говоришь какие-то странные вещи

Vort надо вначале думать, а потом делать

Vort мне кажется, что ты хочешь наоборот

onon Но это _не_совсем_корректный_ механизм, который ты реализовал.

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

onon WRED так же решает эту проблему, только более _правильным_ способом.

Vort делать всё "красиво" - это явно не срочность "до релиза"

onon Да там вроде алгоритм простой.

orignal если этого дропа не сделать

orignal тогда атакующий моментально положит всю сеть по нехватке мапяти

Vort wred предполагает, что ресурса (очереди) не хватает. я такого не видел

Vort orignal: ну попробуй завалить узел с моим патчем. пипец

onon > Даже когда мы найдём и пофиксим причины нынешних тормозов, WRED не потеряет актуальность.

orignal с твоим никак

orignal я говорю зачем был лимит изначально

onon Если не хочешь, делать WRED, тогда делай такой же таймаут для NTCP и добавляйте. Это будет лучше, чем никак. Но я всё же за WRED.

orignal Vort ты только для ssu2 или для ntcp2 тоже сделал?

Vort orignal: сделал только для SSU2, так как 1. onon говорил, что там очередь чаще переполнялась. 2. пока что не уверен в отсутствии багов, поэтому может иметь смысл оставить узлу запасной вариант - прыгнуть на NTCP2

Vort onon: это можно сделать в будущем, после обдумываний и обсуждений

Vort onon: меня интересует, стали ли узлы прыгать на NTCP2 и там переполнять очередь или проблемы с SSU2 ушли "в никуда". можешь глянуть по логам, как часто с моим патчем переполняется NTCP2 очередь?

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

Vort установкой лимитов на очередь эту проблему не решить

onon onon: меня интересует, стали ли узлы прыгать на NTCP2 и там переполнять очередь или проблемы с SSU2 ушли "в никуда". можешь глянуть по логам, как часто с моим патчем переполняется NTCP2 очередь?

onon Без твоего патча за сутки прмерно 20 переполнений на NTCP2 с патчем - 30. Значения слишком маленькие, сложно делать из этого какие-то выводы.

Vort этого достаточно, спасибо

Vort меня беспокоило, чтобы тысячи переполнений SSU2 не перешли в NTCP2

Vort раз не перешли, значит с переделкой NTCP2 можно подождать

onon > установкой лимитов на очередь эту проблему не решить.

onon Если будет обратная связь через WRED/RED стрим снизит скорость через данный туннель/узел, что снизит нагрузку на ЦПУ, или вообще перепрыгнет на другой туннель.

Vort это если там стримы, а не датаграмы

Vort или не запросы к флудфилу

onon Не похоже, чтобы запросы к флудфилу генерировали такой поток.

Vort в случае транзита вообще неизвестно, что там идёт

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

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

Vort это если вообще дело в перегрузке CPU, а не в чём-то ином (к примеру, в проблемк с блокировкой в SSU2)

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

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

onon Ты пытаешься поставить телегу впереди лошади.

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

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

onon Я пока думаю над чем-то вроде BBR2

onon Но сначала нужно что-то с SSU2 сделать

onon Вполне возможно для правильной работы нужно будет добавить ещё один слой, который бы регулировал доступ разных SSU2 сессий к UDP.

onon А ткср у нас низкий ещё потому, что подавляющее большинство U роутеров за непробиваемым натом. Но мы всё равно пытаемся через низ строить туннели.

onon По-хорошему бы ввести ещё один флаг, который бы отличал пробиваемый нат от не пробиваемого.

Vort откуда такой вывод про непробиваемый NAT ?

onon1 Какой вывод?

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

onon1 А это не так?

Vort я проблемы с доступом к U узлам видел в другом

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

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

Vort плохо разбираюсь в NAT - какой из его типов считается "непробиваемым"?

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

onon1 Symmetric и Restricted

orignal а что такое непробиваемый нат?

Vort onon1: Symmetric у меня в виртуалке, по-моему, был

orignal а нам какая печаль?

Vort я на VirtualBox тестировал

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

onon1 Т.е. у нас нет проблем с натом?

Vort говорю же - баги мешают

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

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

onon Тогда почему у нас транзита за натом нету?

Vort onon: баги, говорю же

orignal потому что через них не стоят

Vort так это только в некоторых позициях их нельзя ставить

Vort транзита мало из-за багов

orignal джависты вообще не стороят через них

Vort и да, его не "нету", а "мало"

Vort ну допустим минус половина

Vort в реальности же и 10% нету, скорее всего

Vort может, 1%

onon А как у нас интродьюсеры реализованы?

onon Может у нас с логикой проблемы?

Vort во-первых, из-за багов пир теста интродьюсеры теряются

Vort во-вторых они и сами по себе потеряться могут

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

Vort и куча еще всякого

onon Так вот делай WRED, чтобы сессия с интродьюсером не рвалась =)

orignal да у меня дохуя трназитов

orignal с Firewalled

Vort это сколько ? сотня?

orignal несколько сотнет

onon это у него 201 транзит.

Vort ну вот, а без Firewalled 22 тыщи сейчас. допустим, из-за java было бы на Firewalled 11 тыщ

Vort а получаем в 50-100 раз меньше

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

Vort по моим оценкам, пир тест починить проще всего (то есть, сложно, но остальное - ещё сложнее)

Vort я почитал немного про BBR: queue.acm.org/detail.cfm?id=3022184

orignal и что там?

Vort и пока что мне кажется, что "щедрая" очередь совсем ему не мешает

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

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

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

orignal ну логично

onon Твоя "щедрая" очередь это искусственный рост задержек.

Vort ну а стримы у нас занимают буфер пока не пойдут дропы

Vort onon: нет, какие будут задержки определяет "юзер"

onon Дроп пакетов "пачками" это очень плохая идея.

orignal у меня размер очереди вообще от фонаря

onon И когда будешь глубже разбираться с проблемами передачи трафика, ты сам к этому придёшь.

Vort onon: ну вот почитал я про BBR. пишут, что не надо доводить до дропов. правильно?

onon Именно так, но те самые единичные дропы и определяют "потолок" в механизме.

Vort меня беспокоит, что туннели - слишком хаотичны. 6 хопов через разные транспорты, через разные сети - кто через VPN, кто через Yggdrasil

Vort через разные имплементации (i2pd/java) разных версий

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

orignal да еще и разные страны

orignal в каждой из которых сидит свое хуйло

Vort со своим сортом DPI, да

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

Vort "задать" её можно лишь очень ограниченно

orignal ну так что решили?

orignal вносим это изменекние?