IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#dev
/2024/07/31
~AreEnn
~R4SAS
~acetone
~orignal
~villain
@onon
&N00B
+Xeha
+relaybot
+whothefuckami
Most2
Nausicaa
Vort
`
b3t4f4c3
fujifilm
nemiga
not_bob_afk
poriori
profetikla
segfault
soos
teeth
un
weko orignal: и что
Vort стоит юзерам Yggdrasil держать наготове на случай активизации цензуры
Vort там и quic и tls и вебсокеты
fffff а что случилось с github.com/str4d/ire никто не знает?
Vort автор жив, коммитит в соседнем репозитории
Vort а по поводу ire поленился даже ответить на простой вопрос: github.com/str4d/ire/issues/108
Vort вероятно, понял, что задача оказалась сложнее, чем хотелось бы, но признатся в этом не получилось
Vort но это мои догадки, конечно
orignal знаем
orignal страд просто забил на i2p
orignal ушел zcash делать
orignal страд так NTCP2 и ниасилил
onon Я, конечно, сделал чтобы слать по 6 пакетов за раз, но работает это из рук вон плохо
onon А как сделать, чтобы он слал пачками только когда упирается в таймер, я пока не придумал
onon Вернее, придумал, но это нужно всю логику переделывать.
orignal onon так сделаем лимит снизу на 250 микросекунд?
onon А на винде какой лимит?
onon Ворт говорит 500-1000
onon Или он преувеличивает?
orignal не знаю
orignal но 250 все равно лучше чем 0
onon Давай я вечером сделаю на 250, если хочешь
orignal давай лучше я там 1 строчка же
onon Делай
orignal сделал
Vort я пока ещё не разобрался, как этот таймер себя ведёт. иногда он срабатывает раз в миллисекунду, иногда - два. плюс к этому всему интервалы очень неравномерные
Vort это при том, что алгоритм запрашивает 1 микросекунду
Vort то есть, 1мс он точно держит, а вот меньше - это уже под вопросом
Vort жаль, я выкинул собранные данные по таймеру. сейчас опять соберу
orignal Vort разберись сколько держил и сделаем там #ifdef win32
orignal 250 это из практики на лиунксе
Vort тут же ещё вопрос, что делать с ситуацией "держит, но дерьмово". короч сейчас буду смотреть на данные
Vort вот такой сбор буду делать LogPrint(eLogError, "[", i2p::util::GetMonotonicMicroseconds(), "] Stream::HandleSendTimer m_PacingTime = ", m_PacingTime);
Vort с последним кодом, но MESSAGES_SENT_AT_ONE_TIME = 1, чтобы получить проблему
orignal я не думаю что где то не держит миллисекунду
Vort говорю ж, вопрос в качестве. сейчас станет понятнее
Vort вот сырые данные. сейчас буду обрабатывать
orignal а что за ошибка?
orignal то есть в каком случае ты ее видаешь
Vort это я такой уровень поставил, чтобы остальные сообщения не мешали
Vort просто вверху Stream::HandleSendTimer стоит
Vort теперь дельты надо посчитать для мелких m_PacingTime и гистограмму захренячить
Vort алгоритм целится в 1 миллисекунду несмотря на запрос 1 мкс, но иногда косячит и получается 300-700 мкс ?
Vort (алгоритм таймера имею в виду)
orignal вопрос к onon
Vort ну это общий вопрос про таймер
Vort короч мне кажется, что для винды надо ставить 1мс лимит и не морочить голову
orignal так поменяй константу и проверь как будет
Vort на сколько? 500? 1000?
Vort попробую сейчас 500. если результат будет такой же, как и с 1, значит, надо больше ставить
Vort теперь буду пробовать 1000
Vort для полноты картины
Vort один хрен. оно вообще работает? ) paste.i2pd.xyz/?cd1992bbe5d0a1c5#Dg4mj7aMyLNQ3MmwHYVY3kAGywStAkkSSmT5VYxhLh6w
Vort пробую 2000
orignal погоди ты утвреждаешь что срабатывет не через то время какое заказывали?
relaybot 13apophis: ты поставил другой тип таймера ? ориж ?
orignal нет
orignal некогда было
Vort orignal: ну то, что 1мкс не держится, я думаю, и так было понятно. это и есть "не через то время"
onon > Vort: вот такой сбор буду делать LogPrint(eLogError, "[", i2p::util::GetMonotonicMicroseconds(), "] Stream::HandleSendTimer m_PacingTime = ", m_PacingTime);
onon Ты учитываешь, что когда таймер сработал, m_PacingTime уже мог измениться.
Vort а вот дальше... я наверно неверно делаю измерения
onon Он же пересчитывается при получении ACK
Vort onon: нет, не в этом дело. ты напрямую наверно делаешь выховы
orignal а ты не можешь замерять время?
Vort хотя вроде нету прямых
orignal и передавать его в таймер
orignal а потом по завершению снова и сранивать
Vort onon: алгоритм упирается хоть в 1, хоть в 500, хоть в 1000 или 2000. это нормально, тут в чём-то другом дело
onon Я не понимаю, что значит "упирается"
Vort ну стоит на этом значении. если лимит поставить
onon Ну так логично
Vort я, кажется, понял, в чём дело. таймер то сбрасывается иногда
Vort onon: ну это я к тому что "мог измениться" тут не при чём. не меняется он
orignal правильный тест это передавать таймтсам до запусчка таймера
Vort пока что я хоть и с хреновой методикой, но обработаю данные по 2000
orignal нам надо понять с каким минимальным интрвалом срабатывает точно
Vort данные херня из за отмен таймера. но это _другая_ херня :)
orignal так онмену не учитывай
Vort короч меньше 1мс ставить смысла нету, картинка не меняется вообще
orignal там же код передается
orignal сработал таймер или отменился
Vort хех. окей
Vort сейчас сделаю ещё два сбора
onon Еще защиту выключи, чтобы он окно не сбрасывал
onon Будет на максималках топить
Vort хотя попробую чуть по-другому. во-первых, учту отмены, во-вторых, буду дельту между Stream::ScheduleSend и Stream::HandleSendTimer считать
Vort если получится
flumental а можете мне объяснить как dns-запросы i2pd резольвит? i2pd работает как dns сервер?
Vort понятно, почему были хреновые графики - слишком много отмен
onon Я же говорю, файл качай
orignal flumental читает из твоего локального файла ))
Vort да отфильтрую сейчас отмены
flumental я не понимаю как не происходит dns leak something.b32.i2p когда пишешь его в браузер
orignal потому что запрос идет к прокси
orignal адреса
flumental нет к хттп прокси идет запрос уже отрезольвленного айпи и идет получение данных вроде как
orignal через прокси нет
orignal он присылает CONNECT и ты сам в прокси резолвишь
orignal строка 442 HttpProxy.cpp
orignal и далее
Vort отфильтровал отмены и получил вот такую гистограмму при m_PacingTime = 2000 paste.i2pd.xyz/?6aae658eb6b5eae9#A8J58qAp3dpNeux1EjCQGRGDQvSvQGJSn2LiFkCqkxww
Vort стоит делать график для 1000 ?
orignal стоит я думаю
Vort ок
flumental у меня тут софтина такая что она dns-запросы через себя протрахивает, при этом я могу ей сказать шли этот днс-запрос на сервер 1.1.1.1, пробросив его через http-прокси 2.2.2.2
Vort среднее - 867
Vort это я воткнул логирование в Stream::ScheduleSend после if (m_Status != eStreamStatusTerminated)
Vort и в Stream::HandleSendTimer после if (ecode != boost::asio::error::operation_aborted)
Vort и посчитал между ними разницу
orignal так надо еще записать сколько заказывали
Vort 1000
Vort потому что я поставил такой лимит, а алгоритм в этот лимит упирается
Vort там всего несколько семплов с другой задержкой, я их выкидываю при построении гистораммы
orignal короче 1 мс нормально для винды я так понимаю
Vort ага
orignal ну что я тогда добавляю #ifdef?
weko orignal: как насчёт того, чтобы делать release canditate версии? чтобы перед релизом больше тестировалось всякого
orignal и кто их будет собирать?
orignal у R4SAS -а нет времени даже 2.53.1 собрать
weko и то верно
weko но просто тогда и меньше подверсий с фиксами надо будет делать
weko потому что всякие критичные проблемы будут всплывать в rc
orignal во первых некому собирать во вторых мало кто станет тестировать
orignal а промежуточные я и так все время ставлю
orignal и основные проблемы влазят
weko в 2.53.1 тогда что?
Vort "<~orignal> ну что я тогда добавляю #ifdef?" да добавить то можно, но без дальнейшей модернизации кода эффекта от этого не будет
Vort weko: есть сборки в GHA
weko я имею ввиду какие изменения там
Vort я оттуда и качаю всё время )
Vort а для этого список коммитов есть
Vort хотя бы просто на регрессии тестировать - уже полезно
orignal это понятно
orignal что надо больше отсылать
flumental получается то, что называется прозрачные прокси, которые работают, а приложение об этом не знает, не может в i2p
orignal так надо там днс запилить
flumental а как? у .i2p же нету айпи
orignal маппированием
orignal на запрос адреса xxx.i2p выдается IP адрес а внтури пишется в таблицу
orignal при обращении к нему идет на раельный I2P адрес
Vort onon: надо ещё учесть, что при полноценной нагрузке (допустим, локалхостовой), таймеры могут начать работать не так, как ожидается
Vort то есть, если при слабой нагрузке таймер тянет 1мс задержки, то при сильной нагрузке неизвестно что будет - это надо тестировать
Vort либо делать код, который адаптируется к той фигне, что творит таймер, независимо от того, что именно
orignal это более правильно
orignal надо замерять фактическое время
Vort локалхостовая нагрузка - это хороший стресс-тест алгоритма - многие возможные проблемы с его помощью можно выловить, не дожидаясь пока они вылезут в реальной сети
orignal и исходя из этого выдавать
onon Это уже вне моей компетенции, что таймер работает не так, как заявлено.
orignal вообще то гарантируется везде только 10 мс
onon Я вам сделал классный алгоритм, который неплохо держит стабильную скорость.
onon И адаптируется к разным условиям
onon И работает и на коротких и на очень длинных туннелях
onon И скорость может выдавать как в торе
orignal ну а теперь скажи что делать если таймер не тянет
onon Тыжпрограммист, сделай что нибудь =)
onon Да, я уже примерно представляю, как можно сделать
onon Но начинать не буду
orignal ну я тоже понимаю что надо
Vort для гарантий существуют операционные системы реального времени
Vort винда / линукс - это, скорее, "жрите, что дают"
Vort тут стоит делать измерения при различных условиях и на их основе строить алгоритмы
Vort учитывая, сколько хорошего софта под винду и линукс сделано - это вполне реально
Vort 100% ситуаций покрыть не получится, но это и не страшно. главное, чтобы основные (+ легко тестируемые) сценарии были проработаны
Vort классный алгоритм - это классно, но если при упоре в ядро софт начинает глючить - то это уже не так хорошо
Vort это не какое-это экзотическое придирчивое требование - это обычная реальность
orignal Vort так ставить 1 мс или нет для винды?
Vort я тщательно не смотрел, какие последствия сейчас такого ограничения для алгоритма
Vort скорее всего, никаких и можно ставить
Vort там всё равно по факту 1мс ставится, как я понял, просто алгоритм об этом не в курсе :)
orignal onon а сколько это будет в цифрах по скорости
orignal когда у на 1 мс минимум?
Vort а вот те 1700 KB/s и будут, скорее всего
Vort я потом это число в коде уже нашёл и понял, к чему дело идёт =)
Vort "как в торе" будет
weko запустил тестнет на последнем коммите
weko ssu2-only
weko во первых хочу за пару часов увидеть какой TCSR в идеальных условиях
weko во вторых проверю скорость при ssu2
weko 200 роутеров
Vort ну и за багами и глюками следи
Vort некоторые нормально только через тестовую сеть можно выловить
weko так. 40-50 Mbit/s при 0 хопов получается
Vort помнишь показатели прошлых тестов?
weko ну типо 1-2 мбит вроде
weko а не там тоже самое было
Vort а твои 40-50Mbit/s - это, похоже, 1700/0.25*8 :))
weko вспомнил
weko 20-25 мбит при упоре в процессор
weko но это без пинга
weko тестировать же надо с пингом
Vort а сейчас упор в процессор был? подозреваю, что только частично
Vort столько всего проверить надо... но не буду мешать
Vort надо для начала базовые показатели собрать
weko не было
Vort понятно. сейчас в коде кое какой лимит стоит...
weko какой же
Vort на частоту вызова таймера. который отправляет по одному пакету за вызов
Vort 4000 раз в секунду, а пакеты по 1700 байт (вроде).
Vort вот обсуждаем необходимость отправлять по нескольку пакетов за раз )
weko да похоже в это и упираюсь
orignal ну так лучше стал SSU2?
weko это хуй знает
weko я ж давно этим занимался не помню какие предположения были
weko ну вот ssu2 only даёт нормальную скорость на 0 хопов
weko с tcsr ещё выясним
weko щас вот пинг поставим и выясним
orignal так в 0 хопов он не используется))
weko почему это
weko 1 коннект всё равно используется
orignal в 0 хопах траспорт не зайдествован
weko так или иначе
weko как это
orignal если начало и конец тоннеля на одном роутере
orignal если на разных то да
weko так не на одном конечно
weko на разных стоят
weko задержка 30 мс, 0 хопов. 12-24 мбит/c
weko во среднее показало. 20
weko ставлю 3
weko 3 мбит/c
Vort при пинге 3мс что ли? не понял условий теста
weko 30 мс
Vort а, три хопа
weko это не пинг а зажержка при чём
weko doas tc qdisc add dev lo root netem delay 30ms
weko пинг же 60
weko 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=60.0 ms
Vort а вот тут уже может быть упор в окно
weko надо окно увеличить
weko но сразу скажу - раньше было куда хуже
weko ну как
weko было 1-2 максимум
Vort weko: в чате были ссылки на новые версии алгоритма
Vort с увеличенным окном как раз
weko так там одно число поменят
weko нет?
Vort и ещё одна версия с отправкой 6 пакетов за тик таймера
Vort там дофига поменяно в том коде
Vort только для совместимости с последним коммитом в этих версиях надо будет один нолик удалить
Vort компилер ругнётся - поймешь, где
weko да я пока проверю то, что в основной ветке
Vort окей
weko 7.76 Mbits/sec
weko но какие то нестабильные результатф
Vort иногда скорость в 0 сбрасывается кратковременно что ли?
weko пример
weko [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec
weko [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
weko [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec
weko [ 5] 3.00-4.00 sec 640 KBytes 5.24 Mbits/sec
weko [ 5] 4.00-5.00 sec 1.00 MBytes 8.39 Mbits/sec
weko [ 5] 5.00-6.00 sec 1.50 MBytes 12.6 Mbits/sec
weko [ 5] 6.00-7.00 sec 512 KBytes 4.19 Mbits/sec
weko [ 5] 7.00-8.00 sec 1.00 MBytes 8.39 Mbits/sec
weko [ 5] 8.00-9.00 sec 896 KBytes 7.34 Mbits/sec
weko [ 5] 9.00-10.00 sec 1.88 MBytes 15.7 Mbits/sec
weko [ 5] 10.00-11.00 sec 640 KBytes 5.24 Mbits/sec
weko [ 5] 11.00-12.00 sec 1.25 MBytes 10.5 Mbits/sec
weko [ 5] 12.00-13.00 sec 640 KBytes 5.24 Mbits/sec
weko [ 5] 13.00-14.00 sec 1.00 MBytes 8.37 Mbits/sec
weko это на стороне reciever
relaybot 13apophis: волна
onon Ох уж эти любители iperf-а
Vort apophis: но не рвануло же :D
weko onon: ок могу самописную тулзу запустить
relaybot 13apophis: это плюс
weko запустил. примерно тоже самое
weko и тут вот проблема есть такая
weko фактическая задержка между отправкой данных и из полученем 4-6 секунд
weko !!!!
onon И догадайся почему
weko потому что очереди
onon Нет, потому что loss-based
onon А у тебя дропов нет
weko как это нет
weko есть же
weko по крайней мере были
onon А delay в той версии слишком грубый
weko Server start send data
weko 378KB/s; min:721ms; max:4957ms
weko 1396KB/s; min:4289ms; max:5557ms
weko 1409KB/s; min:4062ms; max:6514ms
weko 1067KB/s; min:3968ms; max:5326ms
weko 852KB/s; min:3947ms; max:5549ms
weko 834KB/s; min:5083ms; max:6220ms
weko 1066KB/s; min:5106ms; max:7120ms
weko 983KB/s; min:5124ms; max:6180ms
weko 1213KB/s; min:4684ms; max:6732ms
weko 978KB/s; min:4102ms; max:5782ms
weko 1218KB/s; min:4274ms; max:5162ms
weko 1925KB/s; min:4111ms; max:5410ms
weko 1329KB/s; min:3873ms; max:5149ms
weko каждые 2000 кбайт данные
weko если поставить период меньше, видно вот такие всплески 55652KB/s; min:4745ms; max:5031ms
onon Это ты в буфер сокета наливаешь
onon Качай файл
weko это тоже делал... щас
weko а, тут же ещё в ssu2 окно ограничено.
weko сделал ntcp2. теперь лиссет не находит. прекрасно
weko о, нашёл
weko ха!
weko как не странно, проблема в SSU2
weko 38.0 Mbits/sec
orignal почему странно?
onon А ещё на NTCP2 bbr включи
weko orignal: да как раз не странно/
weko 5730KB/s; min:990ms; max:1184ms
weko большая задержка, всё равно
onon Это какой алгоритм?
weko всё по дефолту из последнего коммита, только повысил окно до 4096
weko максимальное
onon Нельзя на последнем коммите окно разгонять
weko почему это
weko работает
onon Потому что там dalay CC нету
onon Вернее есть, но он условный
onon Только на совсем жесткие случаи реагирует
onon А если RTT растёт плавно, он полагается только на loss
onon А лосей у тебя нету
weko ну потому что идеальные условия/
onon Если на реальной сети такое попробуешь сделать, все промежуточные узлы лягут под нагрузкой
weko так это понятно
weko я тебе говорю что ssu2 косячит значительно.
onon Я тоже это говорю
weko теже настройки, но на ntcp2 работают в разы лучше
weko но проблема с задержкой всё равно есть
onon Последний вариант, что я скидывал, собирай. Там с этим дела сильно лучше.
onon Только поставь отправку по 1му пакету, наверное
weko if (m_IsTerminated) return;
weko bool isSemiFull = m_SendQueue.size () > NTCP2_MAX_OUTGOING_QUEUE_SIZE/2;
weko for (auto it: msgs)
weko if (isSemiFull && it->onDrop)
weko it->Drop (); // drop earlier because we can handle it
weko else
weko m_SendQueue.push_back (std::move (it));
weko дропаются все пакеты при привышении очереди? чот ну такое, разве нет?
weko точнее когда половины достигают
onon Не все же, а только it->onDrop
weko ну а это условие когда?
onon Это у Лося полный список проси. Знаю что тесты туннелей туда входят
onon Если очередь забита, тест дропается, мы туннель помечаем ка плохой
onon Логика такая, емнип.
weko так узнаем это только если очередь забита на первом транспорте
weko ну ХЗХЗ
orignal onDrop при запросе роутеров
weko не понял
orignal мы запросили роутер
orignal если сообщение дропнулось
orignal вызывается onDrop и мы сразу знаем что запрос зафейлился
orignal не ожидая таймута
weko так получается условие срабатывает в конкретном месте только если задан onDrop
orignal естественно
weko ну где дропаем
orignal а если не установлен ничего не вызовется
weko так а если он не зада, дропаться не будет
orignal обычно в траспортах
orignal когда не можем соединиться
weko так должно всё дропаться
weko всё что не влезает
orignal и там тоже
orignal кстати правильная мысль
orignal запрос на тоннель тоже надо onDrop сделать
weko давно это писал и даже у меня локально было
weko orignal: всё что не влезло в очередь надо дропать просто
orignal так и дропается
weko так только если onDrop задан
weko а задан он только в некоторых случаях, как я понял
weko и данные в него не входят
weko так?
orignal нет
orignal дропрается всегда когда надо
orignal onDrop вызывается когда задан
orignal а если не задан то не вызывается
weko судя по коду не дропается в ином случае
onon Поищи по логам, я где-то код REDа для NTCP2 скидывал, поставь себе и радуйся.
orignal да это странный код
weko так он для всех очередей сразу
weko а тут вопрос одной очереди
orignal но тут смотри какое дело Drop это просто вызов onDrop
weko orignal: ха. а самого дропа нету
weko а, етсь
weko просто пакет не идёт никуда
orignal передалеать надо это
orignal я переделаю
orignal хорошая находка
weko у меня было сделано что цикл рабоает до тех пока очередь не превысит максимальную. нужно добавить что у всех остальнх вызывается Drop если можно
weko и никакого Terminate
weko потому что никогда это условия не сможет сработаь
orignal нет там все проавильно
orignal написан же комментарий
orignal что мы дропаем потому что знаем что с этим сделать
weko ну а где не знаем всё равно должны дропать
weko чтобы не закрывать транспорт как минимум
orignal там дропает на половине
weko ну это просто константу на 2 поделить
onon Раз уж ты туда полез, может посмотришь на RED, что я скидывал?
orignal попозже
orignal счас отойду
weko onon: а у тебя RED для одной очереди или роутера в целом?
onon Для ntcp
onon Для SSU там херня какая-то сейчас
weko ок это поняо
weko я про другое спросил
weko у тебя он для одной очереди или при привышении скорости на роутере
onon Для одной очереди
weko вот теперь понятно
onon Там где ты смотрел, там дропает
onon если больше половины
weko там вообще в большестве случаев не дропает
weko как я понял
onon И чем ближе к максимальному значению, тем выше вероятность дропа
weko потому что обычно onDrop нету
weko onon: а, это как у тебя сделано
onon Там тоже Drop вызывался вроде
weko да но если onDrop нету то пакет не дропается
weko а для данных его как раз нету
onon Ну значит он не работает
weko лось уже сказал что переделает но я могу
weko onon: так а я о чём
weko onon: а у тебя линейная зависимость вероятности от длины очереди?
onon Нет, там WRED
onon Если импульсно, то не дропает
weko ну да, может импульс быть тк tcp
onon А я дальше по коду и не смотрел, Drop вызывается, значит пакет должен дропаться...
onon Логично же
weko согласен
weko фактически дроп это НЕ перенос пакета из msgs в m_SendQueue
weko m_SendQueue.push_back (std::move (it));/
weko я думаю я понял в чём была основная проблема и моей реализации тоже...
weko надо чаще делать SendQueue
weko импульс может прийти больше ращмера очереди, и всё что не вошло дропается. хотя возможно транспорт справилсся бы
onon Нет, такое лучше дропать
` Посоны, посоны. Так что с 2.53.0? Я тут залётами бываю, какие-то проблемы видел. 2.53.0 ставить или корректирующий апдэйт ждать?
weko <onon> Последний вариант, что я скидывал, собирай. Там с этим дела сильно лучше.
weko а ты проверял?
weko я считаю задержку так: при отправке сую таймстемп, при получении вычитаю полученное время из текущего
onon Да, там алгоритм старается минимизировать задержку
weko каким образом?
onon Тебе весь алгоритм расписать?
weko нет просто на чём он основывается
onon Если задержка начинает расти - дропает окно
weko понял
onon Из-за уменьшенной скорости, RTT возвращается к норме.
onon Потом постепенно окно разгоняется, RTT начинает расти, окно снова схлопывается
onon И так по кругу
weko и ещё кстати окно бесконечно растёт даже когда на полную не грузим стрим
onon Не понял
weko ну вот я поставил скорость отправка в 1000 кбайт в секунду, а окно растёт выше чем нужно для такой скорости
onon Ну и нор
weko так если нагрузка вырастет резко, то мы всё отсылать будем
weko хотя многое дропнется
onon И как ты предлагаешь такое обрабатывать
weko ну не повышать окно когда не нужно
weko если буфер отправки пустой, то не повышать
weko вот и всё
onon Ну если просто добавить такое условие - всё равно увеличивать будет, просто медленнее
onon А как сделать правильно - это нужно подумать
weko именно пустой буфер отправки после того как мы из него забрали что можно было
onon TCP насколько я знаю такой фигнёй не страдает
weko это значит что текущего окна хватает и повышать нет смысла
onon Окно схлопывает только после некоторого времени неактивности
onon Но потом-то у тебя в буфере данные появятся
onon И ACK придёт
onon И окно увеличится
weko я сделал ограничение скорости в 1 МБ/c. получил получше задержку 350-600мс
weko onon: появятся. но мы их сразу отошлём и если в буфере не останется, значит мы справляемсяю
weko и повышать не надо
weko вот и всё
weko если же что-то остаётся, значит не справляемся и нужно повысить
onon Ну сделай
onon void Stream::HandleSendTimer
onon if (m_WindowIncCounter && m_WindowSize < MAX_WINDOW_SIZE && !m_SendBuffer.IsEmpty ())
weko onon: а твой алгоритм не поможет
weko потому RTT тут не настолько высокий
onon Я в курсе
weko он не больще 600, а задержка 1000
onon Он и не рассчитан на локальную работу
weko так эмулирована задержка в 30 мс
weko в чём вопрос то
weko именно сами данные через секунду приходят, что гораздо больше чем должно быть
weko а ещё похоже, что зависания стрримо тоже не делись никуда
onon weko: так эмулирована задержка в 30 мс
onon Постоянная? Без колебаний?
onon На реальной сети, промежуточные роутеры имеют свой буфер
weko ну, а тут нет что ли?
weko <onon> Постоянная? Без колебаний?
weko да, тем более должно быть нормально
weko могу и колебания сделать
onon И с 30 выросло до 1000?
weko должно быть где 270
weko где то
onon Это значения из консоли роутера?
weko 450-600
weko там должно быть 420
onon Ты меня запутал
onon То 30 то 450 то 420
onon то 1000
weko <onon> Это значения из консоли роутера?
weko <weko> 450-600
weko <weko> там должно быть 420
weko а, это был вопрос.
weko RTT 450-600, задержка данных 1000
weko 1000-1200
onon Это норм
onon Да
weko почему
onon Потому что любой CC перегружает роутеры
onon Этот перегружает меньше
weko нет, в CPU нет упора/
onon Если сможешь, сделай bbr
weko как
weko я ушёл