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

orignal починил хрень с перепосылками

onon Можно начинать sender пилить.

orignal я же не могу разорваться

onon Ты не рвись, ты пока ещё целый нужен.

orignal постепенно

orignal вот стримами займусь дубликатами

onon И какие мысли, как пачку обработать?

orignal как ты и сказал на каждую сессию надо очередь на отправку

orignal и брать из разных

onon Я имел ввиду стримы

onon Если пачкой ретрансмиты идут

orignal если полученный дубликат пришел снова после 2*RTO то менять тоннели

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

onon Будет при нормальной работе срабатывать.

orignal получили след замеряли если после 2*RTO то сменилит тоннели а время сбросили

orignal почему это?

onon Если только, не ставить bool, что новых пакетов не было

orignal если через интервал значит это уже вторая попытка

orignal что означает что они не получили ack

orignal новые нас ниебут нас только дубликаты

onon Ещё имей в виду, что RTT на клиенте и сервере разный

onon Потому что на клиенте не пересчитывется

onon Это ты на каждый дубликат собираешься время записывать?

orignal да

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

orignal просралось все время сбросили

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

onon Ну, посмотрим на реализацию, сразу предположу что будет сильно медленно. Потому что m_RTO *= 2;

orignal ну время я еще не выбрал

orignal это только идея

onon Это я про сервер

onon Он будет ретрансмитить так

orignal ты про стримы или ssu2?

onon Если с первого раза клиент не угадает туннель, будет ждать следующего

onon Про стримы

onon А следующий будет через 2 рто

orignal ну это лучше чем счас

orignal когда вообще ничего

onon Однозначно

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

onon Так будет работать и с твоими стримами и с моими =)

orignal не вижу смысла зачем нужен массив

onon А как ещё можно запомнить номера пачки пакетов?

R4SAS вам че не спится? уже полночь же )))

orignal на самом деле там можно не массив а сет

orignal R4SAS потому что 8 вечера ))

R4SAS up 1124 days

R4SAS 3 года аптайм сервера...

onon Я кстати сейчас посмотрел что такое локинет.

onon Весь код не смотрел только сетевую часть.

onon И в общем это выглядит неплохо.

onon Не знаю что там с шифрованием, но сеть будет работать быстро, потому что quic

onon Не знаю, какая там версия квика, в последних пакет шифруется не полностью.

onon Я видел, что zlatnib пеарил локинет, и говорил что он переписал в яве стримы на основе локинета.

onon Что, правда в яве квиковые стримы?

orignal ты что то путаешь

onon Нормального описания этого локинета не нашёл, в факе всё мутно и непонятно.

onon SNApps хостятся на сервис нодах, которые тебе не принадлежат

onon И не понятно, что я предоставляю сети, подключаясь к ней. Через меня будут некрозоогуропрон качать из клирнета, и тов. майор придёт ко мне.

Vort "<~orignal> Vort ты понимаешь суть проблемы?" - суть в том, что 10мс*128пакетов*размер задают лимит скорости. но он внушительный и на практике упереться в него сложно

Vort "<onon> Весь код не смотрел только сетевую часть." лучше финансовую часть посмотри

Vort "<onon> Почему не до 1" - вот я и спрашиваю уже, наверно, третий раз - при какой пиковой нагрузке линукс не выдерживает? может, он 128+128 с интервалом в 1 мс воспримет ровно так же как и мгновенную отправку 256 пакетов?

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

orignal ну забыва1 что 128 это не на каждую сессиб а на всех

orignal 1 мс проблема что таймер будет вызываться слишком часто тем самым грузить тред

orignal другое дело что на нагужденных узлах тред просыпается чаще

Vort orignal: так если с первого раза не получалось дойти, то получилось бы со второго, третьего..

orignal так может оказаться что у первых за прошедшее время еще накопились

orignal и опять не доходит

Vort так, что упор в 128 пакетов постоянно?

orignal ну я вот счас переделал

orignal да

orignal 128 это не всех а у тебя сессиий тысячи

Vort "<~orignal> да" я об этом и говорю - это упор в неявный лимит скорости

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

orignal ну это не скорости а ретрансмисии только

Vort ну скорость для ретрансмиссий значит

Vort ещё сложнее упереться

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

orignal и я тоже не знаю почему там 128 а не 256 например

orignal или не 100

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

orignal может надо размеер буфера/MTU?

orignal да именно так

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

Vort надо узнать возможности сетевого оборудования

Vort ну и ОС в том числе

orignal ну а как в общем случае сделать?

Vort чтобы не глючило 99% оборудования/ОС

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

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

Vort а затем уже играться параметрами шейпинга/пейсинга/...

Vort и смотреть, становится меньше глюков или больше

orignal 10 миллисекунд это тоже от балды взято

Vort можно даже на специально сделанной тестовой программе проверять

orignal я даже больше скажу

orignal может вообще не надо никакую задержку а только post вызывать?

Vort вот взять эти 128 пакетов по 10мс - запустить в цикле и посмотреть, сколько просрётся

orignal если больше 128

orignal просто вызываем post для следубщих

Vort так важна же скорость прочистки буферов. если не успеет ОС/железо буфер прочистить, то будет пофиг там 128+128 или 256

orignal буфер вроде 134K по умолчанию

Vort а размер пакета? динамический?

Vort хотя можно по максимальному смотреть

orignal от 1280 до 1500

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

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

Vort для ОС можно напихать данных в буфер и подождать, пока в 0 наполненность уйдёт. измерить время - вот и будет примерное время задержки

Vort тред внутри ОС?

Vort наша программа пихает, а чистит кто? поток внутри ОС?

Vort или чистится в том же потоке, в котором и пихается, только внутри вызовов ОС?

orignal чистит ядро

orignal перекладывает в буфер сетевой карты

Vort ну у ядра тоже потоки есть

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

orignal естественно

Vort или ядро может в том же потоке что и юзерская программа отправить

orignal там планировщик сам решает

onon Есть ещё один важный нюанс, о котором, возможно забыл упомянуть. Если размер буфера отправки сокета больше чем карта может вместить (1000*MTU), то ядро переложит, что сможет, а остальное дропнет.

onon А ты об этом не узнаешь.

onon Если в переполненный буфер ты не запихнёшь, тебе ошибку вернёт, то тут так.

orignal именно так

orignal если просто не может отправить адресату то же самое

Vort "<~orignal> естественно" может ли поток юзерской программы переключиться без выделения времени отправляющему потоку ядра?

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

orignal Vort да запросто

orignal но мы на можем на это полагаться

orignal потому что системы могут быль реализованы по разному

orignal onon что думаешь если не ждать 10 мс?

Vort "<~orignal> именно так" неужели линукс настолько поломанный?

onon Я же говорил, нужно реальную скорость узнавать

onon От этого и считать

orignal это не линукс это протокл UDP такой

orignal с неграрнтированной доставкой

orignal дропнуть может где и и когда угодно

Vort "<~orignal> но мы на можем на это полагаться" - если ядру может не достаться времени, значит нельзя сразу отправлять вторую порцию

onon Поэтому и нужно пейсинг

Vort "<onon> Я же говорил, нужно реальную скорость узнавать" скорость чего? и это выглядит какой-то фантастикой

onon Скорость интерфейса

onon Если там мобилка

orignal так что у нас с ошибками отправки? они есть?

onon Что ты туда будешь слать каждые 10 мс. Может ширины канала не хватить банально

Vort "<onon> Скорость интерфейса" так у компа может быть высокая скорость интерфейса, а у роутера низкая. и какая в таком случае важна?

orignal "SSU2: Send exception: ", ec.message (), " to ", to);

orignal onon про мобилку мы не говорим

orignal речь только по флудфила которых сидят на минимум гигабитном канале

onon Я не совсем понял вопрос. Все роутеры важны, и должны работать хорошо.

Vort я про железячный роутер

orignal вопрос в том что на мобилках вряд ли будет эта проблема

Vort вот подключен комп к роутеру, а роутер к какой-то фигне (dial-up)

orignal потому что там трафика с гулькин нос

onon Тред, который занимается только отправкой, лимитируется скоростью интерфейса или настройками пользователя

onon А перегрузки контролирует каждая SSU сессия отдельно

onon До своего "клиента"

Vort onon: так всё же - какая скорость важна если на компе, допустим, сеть 1 гигабит/сек, а подключен комп к сети 1 мегабит/сек?

onon Ну так я же и говорю, чтио пользователь должен указать реальную скорость

onon Если он поставит гигабит, а в реале у него мегабит, то у него будет переполняться буфер постоянно и не будет работать

Vort то есть, не "скорость интерфейса", а "скорость, которую указал юзер". это разные вещи

Vort "<onon> Я же говорил, нужно реальную скорость узнавать" = узнавать у юзера, да?

onon Да

onon А как по другому?

onon Я не знаю.

orignal onon так это проблема пользователя

Vort ну можно просто трафик измерять да и считать это скоростью

onon Может у него 100мбит, но он хочет разделить канал и отдать нам только 50

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

onon Ну и сам будет страдать

orignal давайте смотреть на вещи реально

Vort orignal: onon: можно сделать ограничение задержки с двух сторон

orignal исходя из возможностей а не пожеланий

Vort допустим, от 1мс до 10мс

Vort внутри интервала считать от настроек юзера

orignal так что с моей идеей отправлять оставшиеся без задержки только ставить в конец очереди

orignal а если оаставлять 10 мс я считаю надо вводить variance

onon Всегда лучше чаще, но меньшими порциями.

onon Вопрос в проце

orignal ну я и предлагаю вообще без задержки

onon Мне не нравится

Vort "<~orignal> так что с моей идеей" - если ядру не достанется времени на отправку, то это будет то же самое, что отправлять всё сразу

orignal Vort не совсем

Vort почему?

orignal потому что я отправляю не пачкой

orignal а отправляю тред я спячку

Vort а если отправка не сработала, то не всё ли равно?

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

Vort так воспользуется ли ядро этой возможностью?

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

orignal ядро то может не воспользуется

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

orignal перед тем как пойдет следующая порция

orignal а задания как правило криптография

orignal а если узел не нагруженный то не пох ли?

Vort короч моё мнение всё то же - нужны тесты, воспроизводящие проблему (потерю пакетов). по результатам экспериментов с ними будет видно, как поступать дальше

orignal onon ты с последним коммитом попробовал?

onon Нет ещё

onon 2.5.1 version string, not the api string, is being published via routerinfos. ORIGNAL!!!

onon Опять там Лось что-то накосячил

orignal а ну это старая атака

orignal уже 2 недели как

orignal они задергались потому что у них подпись не фелится

onon С каждым разом сборка занимает всё больше времени.

orignal это что то у тебя

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

orignal сделал чтобы не запрашивал себя

orignal до кучи заменил set на unordered_set

onon Vort, нужно кое-что сделать. Лось там айсберги покоряет, ему не до того. А дело нужное и как раз тебе точно по силам.

onon Нужно каждому туннелю добавить атрибут, туда записывать разность времени создания и запроса на построение. Т.е. как быстро он построился.

onon Дальше на основе этих данных вычисляем среднюю скорость строительства туннелей, можно просто MA. Делаем с запасом например MA*1.5 и выставляем как таймаут на строительство туннеля.

onon Каждый таймаут увеличивает MA на некоторый процент, например 5%. Пока не упрётся в максимальное значение.

onon Успешное строительство будет поддерживать MA на адекватном уровне.

onon И ещё для туннелей, которые не строятся "с нуля" а перестраиваются, сразу ставить минимальный таймаут, например 5 сек.

onon1 Потому что сейчас он слишком долго ждёт, и это проблема. Сервис без туннелей висит.