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

weko orignal: так пробовать или нет?

weko а то запарно делать просто так

orignal как хочешь

orignal пока не надо я думаю

weko Ну просто ты результам на локалхосте не доверяешь

weko Вот потому и предлагаю

orignal я просто говорю почему NTCP2 сильно лучше

orignal но как ты правильно говоришь это не объясняеь плохие резлуьтаты SSU2

orignal нужен тест именно для SSU2

weko 1 хоп ты имеешь ввиду?

weko orignal: ну если причина в локалхосте, то на по проводу будет хуже чем ра локалхосте с тем же пингом

orignal я имею ввиду чтобы два SSU2 соединялись и смотреть в какой момент наступят торомза

weko orignal: ну да как раз 1 хоп

weko 1+0

weko А хотя 0+0 тогда

orignal ну вот да

orignal можно и 0=9

orignal 0+0

weko Нужно

weko Чтобы ровно один коннект был

weko А не 2

weko поставил 60+-5. ntcp2 разогнался с 20 до 150-200

orignal мне инттересно на чем SSU2 затыкается

weko при 0 выдаёт 3500 - меньше чем ssu2 при нуле

orignal возможно там размер буфера надо увеличить

weko orignal: как будто ждёт подтверждение прошлого пакета перед отправкой нового

weko ну да как раз про буфер

weko сколько сейчас он?

orignal 128 пакетов вроде

weko ssu2 сам по себе быстрее ntcp2, но при увечении пинга ntcp2 быстрее

orignal const size_t SSU2_MAX_WINDOW_SIZE = 256; // in packets

weko orignal: так это число выходит сколько максимум пакетов за время пинга

weko ну теперь понятно почему

weko под какую скорость ориентируемся? я посчитаю какой буфер ставить надо

weko хотя как я блять посчитаю

orignal не знаю

orignal надо исходя из практики

orignal раньше было 128 потом поднряли до 256

weko надо взять целевое количество пакетов и целевой пинг

weko под который оптимизировано будет

weko orignal: это мало очень просто

weko 10000 пакетов в секунду при пинге 25ms

weko а если mtu 1500 то это как раз 15 KB/s

orignal и сколько надо?

orignal 512? 1024?

weko <weko> надо взять целевое количество пакетов и целевой пинг

orignal так память же будет жрать

weko так динамический надо

weko чтобы расширялся когда надо

weko ну как именно реализовать ты лучше знаешь

weko возьму 10 миллионов пакетов в секунду тогда

weko нормально?

weko хотя стоп чот дохуя

weko так стоп

weko это я что-то не то посчитал

orignal так он и так джинимаеский

orignal 256 это максимум

weko ну это я затупил

weko при пинге 25ms максимальная скорость 14.6 MB/s

weko значит дело не в этом

orignal довольно неплохо

weko ну или связано с этим но не с размером

orignal так я и говорю надо понять механизм торомозов

weko в идеале я должен поставить пинг 25ms на 0+0 SSU2 и получить 14.6 MB/s

weko orignal: возможно буфер на самом деле не расширяется

weko тоесть фактически он меньше

weko константа константой, но важно чтобы буфер реально был такой

weko orignal: есть идея. можно поставить большой буфер и посмотреть как будет поребляться память при нагрузке

weko хотя не

weko если проблема не в этом, то память не увеличить. и если проблема в этом тоже не увеличиться

weko <weko> при пинге 25ms максимальная скорость 14.6 MB/s

weko если сделать погрешность на метаданные то будет меньше конечно

weko но я беру mtu 1500

orignal так поменяй ту константу на 1024 и посмотри

weko так всё надо 0+0 смотреть

weko просто если скорость 30 KB/s из-за буфера, то он тогда 0.5 пакета

weko что бред

weko но вероятно скорость ниже изза 6 хопов

weko значит надо смотреть 0+0, если в итоге при расчёте буфер будет равен 1 - вероятно баг тут

weko стоп. а разве роутер умеет делать коннекш к самому себе?

weko думаю нет, потому стоит перенести на второй

weko как не странно - может

weko а нет

weko он не создаёт вообще

weko ну короче перенёс

weko при пинге 0 выдаёт 8000

orignal значит и правда влияет

orignal это при 1024,

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

weko нет это 0+0

weko поставил 25ms - 300 даёт

weko не ожиданно

orignal а было?

weko на 3+3 было 15-30

weko кстати такой вопрос

weko какой буфер у сессии стриминга?

weko http же tcp

weko значит в ш2з стриминг

weko const int MAX_WINDOW_SIZE = 128;

orignal наверное да

weko есть подозрение что надо больше

orignal наверное да

orignal я там давно не трогал

orignal ну так что с SSU2 поменять на 512?

weko не вижу смысла

weko оно в это число не упирается

weko нет тут 128 тоже достаточно

weko хотя я бы прозапас как раз тут побольше сделал

weko потому что при пинге 175 ms максимальная скорость 1.2 MB/s тут

weko mtu взял как 1730

weko const size_t STREAMING_MTU = 1730;

weko надо для сравнения ntcp2 померять на 0+0

orignal MTU там нельзя трогать

orignal оно длиной пакета в тоннеле определяется

weko ну его трогать понятно не надо

weko это естесна

weko const int MAX_WINDOW_SIZE = 128;

weko вот тут повысить стоит

weko прозапас сделать 512

weko не много

weko 256 хватит

weko при SSU2 кстати Tunnel creation success rate: 49%

weko *** ушёл ***

orignal значит потерей много

weko Нету потерей на локалхосте

weko Уж точно не в таком количество

orignal ну надо понять где теряются запросы и ответы

weko const int SSU2_RESEND_INTERVAL = 300;

weko Что означает эта константа?

weko Раз в сколько мы переотправляем пакеты?

orignal через какой интервал в миллисекундах идет перепосылка

orignal const size_t SSU2_MAX_OUTGOING_QUEUE_SIZE = 500; // in messages

orignal может потерии из-за этого?

orignal 500 сообщений и выкидываем

weko Но они должны обрабатываться быстрее чем копится по идеи

weko Вот ещё что странно. SSU2 умеет 300KB/s, но при этом когда 7 поряд SSU2, то тогда в 10 раз меньше скорость

weko Ну то есть понятно время на криптографию

weko Но явно не столько

orignal ну вот разбираться надо

relaybot 13apophis: крипютография поол рандом не сильно садит для многих роутеров на одном компе ? на одном то нет, а в докере ?

weko apophis прикол в том что ntcp2 при 7 подряд работает в ~10 раз лучше

weko Так что в лимит по I2NP нету упора

weko Проблема явно с SSU2, но пока не ясно какая

weko 1. где-то слишком медленно отправляется

weko 1.1 медленно формируется и шифруется

weko 1.2 медленно шлётся на сокет

weko 2. где-то слишком медленно принимается

weko 2.2 медленно принимается с сокета

weko 2.2 медленно расшифровывается и парсится

weko Ой бля ну там 2.1...

mauzer мы понели

weko Ток надо будет проверить ещё NTCP2 на 0+0 и заебок буит

weko Надо сделать чтобы несколько сетей можно было оперировать...

weko Оперирование нах)

orignal ну так вот и надо найти конкретный ответ

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

weko чёт на 0+0 NTCP2 скорость скачет сильно

weko плохой знак

weko но скачет она точно выше ssu2

weko хотя по логике наоборот должно быть

weko вплоть до 1.9 MB/s было

weko пинг 25+-1

weko но и до 700 KB/s опускается

weko и до 500

weko короче скакун

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

weko пинг 25мс намеренно стоит

Vort а. понятно

weko но упора то в порт нету

weko так что вероятно от буфера зависит

weko вот щас увелечил для стриминга

Vort пинг можно динамически менять?

weko да

Vort если поставить 50мс, упадёт ли скорость ровно в 2 раза?

weko сложно понять

weko она скачет постоянно

Vort ну 100мс поставить тогда

weko на ntcp2

Vort в 4 раза падение легче заметить

weko ну давай ща

weko да

weko поставил 100ms. +-300 скорость/

weko а вот щас упала

weko до 150

Vort ну значит буферы виноваты

Vort а где - хз

weko ну я попробовал в стриминге константу увеличить

Vort хрень конечно. совсем мало получается

weko в ntcp2 вроде не нужен буфер (tcp же), но я гляну

Vort 100 пинг - это обычное явление

Vort как раз для TCP и нужен. буфер сокета

weko Vort: да. но по планете в среднем 66 выходит

Vort иначе TCP ждёт подтверждений и тупит

weko да но если взять пинг такой не при ш2з то норм скорости могут же быть

weko на tcp

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

Vort в сокетах

weko я к тому что у ядра точно нормальный размер

weko Vort: и как определяется по твоему?

weko вот щас скорость 500

Vort так этот же буфер через API вызовы задаётся, вроде

weko Vort: интересно

Vort setsockopt(чё-то там

Vort ну я не на 100% уверен

weko надо код глянуть

Vort в i2pd, похоже, не трогается вообще

Vort SO_SNDBUF and SO_RCVBUF

weko ну да константы нет такой

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

weko Vort: условно браузер может качать с большим пингов на весь

weko порт

weko могу даже проверить с сотней пинга

Vort для софта, основное назначение которого - работа с сетью...

weko о ёпт

weko 1100 выжало!!

Vort ну так поищи в исходниках браузера SO_SNDBUF и SO_RCVBUF

weko нихуя себе

weko ещё я не искал в коде фаерфокса

weko ))

Vort а я всюду всё ищу )

weko хм. а вот без ш2з на 100ms выдаёт 14100

weko можно высчитать буфер

weko 1024 пакета вызодит буфер

weko выходит*

weko поставил пинг в 2 раза меньше - выдаёт в два раза больше скорость - 28000

Vort попробуй подпихнуть SO_SNDBUF и SO_RCVBUF куда-нибудь в i2pd - вдруг разгонится :)

Vort там, конечно, не всё так просто. но попробовать не помешает

weko не знаю

weko браузер использует буфер 1024

weko а вот какой по умолчанию я не знаю

weko явно можно задать

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

Vort но тогда не понятно откуда тормоза

Vort если не из-за них

Vort размер там, кстати, не в пакетах, а в байтах

weko ну да tcp же

weko ну значит в байтах там 1.5 миллиона

weko +-

weko net.ipv4.tcp_rmem = 4096 131072 6291456

weko net.ipv4.tcp_wmem = 4096 16384 4194304

weko 6 миллионов

weko где то ошибся

weko rb5109741

weko я уже не помню зачем смотрю

weko кстати да потери есть. вот тут 96 пакетов например

weko проблема явно не в ntcp2

weko ну он умеет как минимум 1.4 MB/s

weko я решил по wget'у смотреть

orignal я думаю где то в SSU2 я лищнего подтверждаю

weko во 1.9 выжал

weko у меня подозрение что со стримингом что-то

orignal стриминг это отдельная беда

weko orignal: да но потецеал ограничен. явно что-то у него с буфером

weko но теперь мы уверены что 300 у ssu это именно упор в ssu а не во что-то другое

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

weko хотя как бы их быть не должно, порт то не ограничен

Vort так ОС по-разному обрабатывает TCP и UDP

weko ну как бы то не было

Vort через iperf3 лучше смотри, на что ОС способна

Vort хотя... может и он не идеален. хз

Vort iperf3 может и через TCP и через UDP измерения делать

weko net.core.rmem_max = 2621440

weko 2 миллиона тут

weko явно хватает

weko я буду сейчас пробовать тыкать разные константы

Vort так почему ты думаешь, что ОС не способна затупить и не разогнать до максимума?

Vort проверь таки скорость через iperf3 вначале

weko окей сейчас посчитаю соответсвие скорости загрузки и сокета

weko чтобы удедится что ось даёт максимум

weko хм

weko ну терь и wget тупит

weko 28.5 MB/s крч при пинге 100

orignal я думаю как

orignal пока нет потерь пакетов SSU2 работает быстро

R4SAS weko: на сокет повесь параметры

orignal как начинаются потери там где то бага с подтверждениями

weko R4SAS: ты о каких параметрах и на какой сокет?

weko orignal: потери всегда есть

R4SAS RCVBUF, SNDBUF

weko R4SAS: а ну ядро само справляется с настройкой

orignal не всегда я думаю когда небольшой поток то нет

orignal а вот с перепосылкой какой то глюки

weko ну когда поток маленький понятно оно не ставит много

orignal R4SAS пересобрал с фиксом?

R4SAS нет, я только добрался до компа

R4SAS а от TCP_NODELAY есть смысл у нас?

weko короче мой месседж такой что буферы ядра спокойно справляются и проблема точно в ш2з где то

R4SAS еще посмотри на net.core.rmem_max и net.core.wmem_max

R4SAS плюс net.core.netdev_max_backlog

weko первое глянул, второе ща

orignal я не знаю

weko 2.5 лимона тож

orignal вряд ли

orignal вот QUICK_ACK да это отменная гадость в линуксе

weko net.core.netdev_max_backlog = 1000

R4SAS weko: # cat /proc/net/softnet_stat

R4SAS во второй колонке есть значения отличные от нуля?

weko нету

R4SAS тогда нормально

R4SAS I/F Name Recv=KB/s Trans=KB/s packin packout insize outsize Peak->Recv Trans

R4SAS eno1 36036.3 36053.4 46154.744187.2 799.5 835.5 38128.7 39438.5

R4SAS гоняют во всю

weko так у меня вопрос. Window в морде показывает сколько пакетов в буфере, да?

R4SAS не пакетов, а байт

weko или он показывает сколько i2pd сейчас ставит максимальный window

weko 78 байт? такой себе буфер

weko тут манелькие числа

R4SAS потому что отсылать успевает

weko const int WINDOW_SIZE = 6; // in messages

weko const int MIN_WINDOW_SIZE = 1;

weko const int MAX_WINDOW_SIZE = 256;

R4SAS ну значит тут в сообщениях

R4SAS в TCP это немного по другому

weko ну тут стриминг

R4SAS сообщение ставится в буффер, который по ACK высылается порциями

weko orignal: что именно выводится в Window в морде?

weko могу попробовать дёрнуть MIN_WINDOW_SIZE

weko кстати я мало того что уже повысил MAX_WINDOW_SIZE так его всё равно не хватает на 0+0

weko так что и его до 512

R4SAS Streaming.cpp

R4SAS ProcessACK

R4SAS всё то же самое

weko посмотри как текущий размер window считается

R4SAS Stream::SendBuffer

weko R4SAS: при максимальной нагрузке (а у меня максимальная) стриминг делает сообщения по 4096 байт (MAX_PACKET_SIZE = 4096). соответсвенно в байтах будет window * 4096

R4SAS switch (m_NumResendAttempts) - меня это больше интересует

R4SAS в Stream::HandleResendTimer

R4SAS почему перепосылка уменьшает окно?

R4SAS при чем в 2 раза

weko NTCP2_MAX_PADDING_RATIO = 6;

weko а не мало?

R4SAS нормально

weko DPI не сцапает?

R4SAS оно вариативно

weko ну понятно что от 0 до 6

weko но и DPI всё хитрее

R4SAS это уже протокол, тут нельзя просто взять и число изменить

weko разве? я думал получателю шлётся размер паддинга и он чистит его сколько бы там не было

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

R4SAS нет

weko тоесть если получатель видит что больше 6% паддинга то ошибка?

orignal текущий размер окна в пакетах

orignal чем окно больше тем лучше

orignal 2 раза уменьшается так дед сказал

R4SAS странно это

weko очень странно

orignal ну он так сказал давно а я ничего не менял

weko короче я поставил минимальное окно 512 и максимальное 512

weko сейчас посмотрим

weko блять

weko 4.2 даёт

weko алгоритм текущий полная хуита

R4SAS байта?)

weko R4SAS: )))

weko MB/s

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

weko повысим скорость наХ

weko ща поставлю ещё больше

orignal что именно ты поставил?

weko ща кину

R4SAS *_WINDOW_SIZE

weko const int WINDOW_SIZE = 512; // in messages

weko const int MIN_WINDOW_SIZE = 512;

weko const int MAX_WINDOW_SIZE = 512;

orignal нельзя так

orignal ты всю сеть зафлудишь

orignal нельзя так

weko исскусвенно скорость лимитируем?

weko или как

weko вполне ясно во что лимит

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

orignal оно не просто так сделано

orignal это не скорость

weko orignal: ну может и нельзя

weko но смысл ты понял

orignal const int WINDOW_SIZE = 6;

orignal поставь 16

weko проблема в алгоритме

orignal или 32

weko который считает window

orignal дак это давно известно

weko а это init значение или что оно делает?

orignal это превоначальное

orignal и поставь MIN 8 например

weko оно при 1-256 и первоночальном 6 колеблется от 20 до 256

weko хотя очевидно что нужно всегда 256 так как в скорость упора нету

` <~orignal> ты всю сеть зафлудишь

` свою или окружающих? думоет про какерофф..

weko и первоначальное значение и минимально 8 ничего не поменяет

R4SAS orignal: я не понимаю откуда дед взял что надо уменьшать окно вдвое при перепосылке

R4SAS данные так точно не теряются?

` а дед соффок - взять и поделить

` (с)Ватсон

R4SAS `: брысь

weko R4SAS: ну данные не теряются иначе бы ничего не работало

weko но скорость падает

weko как раз в 2 раза

weko orignal: объясни почему я так сеть буду флудить?

R4SAS по идее ведь, окно - это указание принимающей стороне, что мы можем отослать столько-то данных до момента необходимости получения ACK

weko да

weko поставил 2048 - вообще заглохло после 9 мегов

weko о заработало

weko глохнет видимо баг где то

weko но 17 MB/s выдаёт

orignal данные нет не треяются

orignal если у тебя 512 пакетов ты каждый раз их будешь пытаться пачкой отсылать

orignal там с данным если окно полное то пихать не будет

orignal пока не освободится место

R4SAS это то понятно что не будет

R4SAS но мы после ретрансмиссии делим объем на 2

orignal делим

orignal но окно это для того кто в него пихает

orignal мы сами данные не меняем

R4SAS ну... переотправили мы 16 пакетов

R4SAS из 16

orignal ну уменьшили окно до 8

orignal но как 16 было для отправки так и осталось

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

orignal а окно это такая штука что вся пачка отправляется

weko orignal: окно - это размер буфера, в который мы кладём пакеты, пока на них не придёт ACK для них, верно?

R4SAS верно

orignal да

orignal и каждый раз пытаемся перепослать их все

weko это же тупо

R4SAS так если мы переотправили, но не получили ACK, то почему далее мы будем пересылать только 8?

weko если вторая сторона сообщает что нет конкретного пакета, может стоит только его слать?

weko или нет такой фичи ?

orignal нет далее мы снова переслыаем 16

orignal но новые не отсылаем пока неподтвежденных не останется 8

` чтобы стак новый сформировался

orignal weko та сторона так и делает

weko а нахуя мы всё заного шлём?

orignal она подтверждает какие пакеты получены а каких нет

R4SAS github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Streaming.cpp#L1003-L1005

orignal мы шлем только то что не подтвердилось

weko orignal: нахуя тогда нам слать пакеты, которые есть у второй стороны??

orignal что пожтвержилось мы выбрасываем

weko orignal: ну это уже не всё окно

orignal а мы не шлем

orignal как только получили от той стороны что пакет получен все

weko orignal: ну и нету флуда в этой схеме

weko мы в любом случае шлём только то, что надо

orignal так если 512 в окне

orignal и подверждений на них не пришло

orignal все они и выструтся сразу

weko ну есть же лимит на переотравку

orignal ну вот пачку по 512 нельзя выбрасывать

orignal потому и стоит лимит в 128

weko почему нельзя?

orignal потому что сеть зафлудишь

orignal нет я ничего не говорю

weko ну это копейки же трафика

orignal можно поменять 128 на 512 попытаться

weko мы лишнего не тратим

orignal чего нельзя делать так это MIN =MAX

weko ну да вероятно поэтому и заглыхает оно

weko потому что =

orignal оно соотвествует состянию соединению

orignal и 128 так никогда не бывает

orignal там на каждлый Ack +1

weko orignal: я согласен что нет смысла 6 раз слать 512 если всё равно пакеты не доходят

orignal а если не получен то вполовину меньше

weko но тогда алгоритм надо менять явно

weko он закосячен

orignal ну так предлагаей на что менять

orignal почитай какие алгоритмы в TCP используются

orignal болгарин с ними долго говорился

orignal *ковырялся

weko orignal: окно должно сужаться ровно на количество потеряных пакетов

weko а не в 2 раза

weko тоесть если всрали 1 пакет то не страшно

weko но если всрали все 512 то значит нахер не нужно снова все 512 слать в следущий ращ

weko ну это как минимум. не знаю ещё от чего окно сужается

orignal возможно

orignal так попробуй

weko при этом пока буфер отправки > 0 окно увеличивается - на сколько не знаю

weko у меня есть подозрение что и в ssu2 тоже криво определяется

orignal в SSU2 та же хрень

weko так эта задача приоритетная

weko у нас в ш2з скорости смешные и лаги постоянные

weko orignal: даже если ты боишься наплыва юзверей, можно оставить 64 окно например

` > окно должно сужаться ровно на количество потеряных пакетов

` доп.расходы ¯\_(ツ)_/¯

weko чтобы максим 0.5 MB/s было

` так, это, а что если какеры поставят эти окна?

` "оверсайзные"

weko ничего

weko банить надо умников спамеров

weko как - я уже говорил

orignal так говорю же попробуй

orignal ` у датаграм окна вообще нет

orignal можно срать как угодно

weko orignal: ты не забывай что я не плюсер

orignal ну так понять место в коде ты сможешь

flumental github.com/PurpleI2P/i2pd/blob/d724948d031dbd4fe05f106c0b07a1c58b007987/daemon/HTTPServer.cpp#L1301

flumental а что так можно было? Я думал нужен какой-нибудь strcmp для проверки равенства const char*[]

weko orignal: объективно заебало с лагами сидеть. это же пиздец какой-то

weko я говорю что у роутеров больше мощностей чем выжимается

orignal ну так пробауй

orignal потом расскажешь

flumental а, тут вся магия в стрингах, тогда забыли я неправ

weko вот щас ssu2 попробую

weko после 3+3 проверю

weko ssu2 я тоже мин буфер повысил

weko на 2048 оно где то багует, поставлю 512 - работало нормально, хоть и не будет весь потенциал выдавать, будет понятно

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

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

orignal а меня интересует почему потери на SSU2

weko из-за двух коснстант половину i2pd пересобирает

Vort зато стиль "правильный" :)

orignal ну так для того и модули придумали типа

weko ну быстрее на потоках конечнор

weko но всё равно ЗоЧеМ вопрос остаётся

Vort как по мне, если константа только в .cpp используется, то нефиг её в .h тыкать. ну это мелочи. баги и лаги важнее

weko и читаемость

orignal они используются в других файлах

weko не все )

weko бля чот не пойму. загрузка начал глохнуть. ща попробую понять где проблема

orignal ну так а ты думал хуяк поменял размер окна и стало быстрее?))

weko так оно реально стало быстрее

weko 17 MB/s я не из потолка взял

weko взад вернул - работает

weko так но с ntcp2 норм же было

weko попробую аккуратнее играться

weko вопрос. на уровне i2np если транспорт куда слать надо забит - пакет дропается?

weko orignal:

orignal что?

weko [21:31:39] <weko> вопрос. на уровне i2np если транспорт куда слать надо забит - пакет дропается?

orignal нет

orignal там есть очередь

weko а если очередь забивается?

orignal но у нее есть какой то лимит типа 500 сообщениц

orignal дропается

weko то есть если мы привышаем скорость идут потери

weko верно?

orignal угу

orignal но 500 это сильно большой лимит

orignal можно 1000 поставить

weko я просто эксперементирую тут

weko пытаюсь понять почему может глохнуть

weko кстати может сторона просто не может ACK такой большой отпавить

weko потому что я пробую на SSU2 а тут же с ним беда

weko потому на 512 идут жёсткие потери

weko но теряются на все пакеты

weko надо тупо в лог глянуть

weko о, SSU2 прорвало

weko не на долго

weko было 600 KB/s

weko orignal: ну всё теперь ясна главная проблема скорости ш2з

weko потому что в ssu2 таже херня с окном

orignal а почему рейт на чистом ssu2 низкий?

orignal даже если скорость низкая

weko без понятия. вероятно другой баг

weko Tunnel creation success rate: 50%

weko ssu2

weko тут туннели по 8 хопов

orignal ну все равно вопрос отсается почему потери

orignal меня интересует именно этот баг в первую очередь

orignal скорость то понятно что дело в окне

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

orignal значит акк в середине пришел

orignal и все остальная пачка пакетов просралась

weko ssu2 явно с перепосылками плохо справляется

weko когда перегружаешь он тупит

weko бля неправильно объясняю

orignal видимо баг

weko да вполне вероятно

weko тоесть когда стриминг грузит его сильнее его возможностей происходит зависание

orignal вот надо понять

orignal в лог писать перепосылки

orignal и полученные аки

weko ssu2 окно 1024 а скорость даже ниже

weko а блять

weko ну понятно

weko я забыл окно стриминга поднять

weko ну короче окно тоже бездумно поднимать нельзя

weko можно перегрузить буферы и всё встанет

weko не пойму почему именно в 0 уходит - видимо какой то баг

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

weko после кучи тестов вывод такой: я вообще не ебу почему оно виснет