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

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 paste.i2pd.xyz/?4376a87c379968a9#72oFx4SRFabFC4WUCetLvWEh3NU962tuYsjibHFAMJxW

onon paste.i2pd.xyz/?51f7b120e56229ff#GHcLEuaAnUrkYKKVsfY5qBoJqUNuh3GT182CdNmZEJYq

onon Я, конечно, сделал чтобы слать по 6 пакетов за раз, но работает это из рук вон плохо

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

onon Вернее, придумал, но это нужно всю логику переделывать.

orignal onon так сделаем лимит снизу на 250 микросекунд?

onon А на винде какой лимит?

onon Ворт говорит 500-1000

onon Или он преувеличивает?

orignal не знаю

orignal но 250 все равно лучше чем 0

onon 1*

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 paste.i2pd.xyz/?3e91688fcf5844b8#3pZcM2QxeLAq4k3ye4FcpZ35xYwU45G4XEidoJFa9mWA

Vort вот сырые данные. сейчас буду обрабатывать

orignal а что за ошибка?

orignal то есть в каком случае ты ее видаешь

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

Vort просто вверху Stream::HandleSendTimer стоит

Vort теперь дельты надо посчитать для мелких m_PacingTime и гистограмму захренячить

Vort и как это понимать? paste.i2pd.xyz/?71aa761296336425#8xEJEa4cPBYxUmtHYvhthaVA8a1YfbhPoUN7MKLJGnfQ

Vort алгоритм целится в 1 миллисекунду несмотря на запрос 1 мкс, но иногда косячит и получается 300-700 мкс ?

Vort (алгоритм таймера имею в виду)

orignal вопрос к onon

Vort ну это общий вопрос про таймер

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

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

Vort на сколько? 500? 1000?

Vort попробую сейчас 500. если результат будет такой же, как и с 1, значит, надо больше ставить

Vort paste.i2pd.xyz/?83ccb51de709429f#EGjVGZf3pjyL4PHV8DRobaepWRt2WquhCRxWjPJYtPUe

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 вот теперь я вижу различие: paste.i2pd.xyz/?6ff19eaceab94469#58jfPczmcWBSNVdXePGV9Tihr7JUFNcFRrg6iLMMHC4t

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 paste.i2pd.xyz/?9aad7e5c7f8d735f#2Vjgms55Z4AMtj97ndPCvNC4g4kUWwj8AwPop9z9e2B6

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 ь

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 Ну и нор

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 я ушёл