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

onon I2P_TUNNEL_CONNECTION_BUFFER_SIZE = 16384

onon ^тут проблема

orignal это псих такое поставид

orignal скажи в чем проблема

onon Ща погоди перепроверю

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

onon Короче смысл такой что у меня с ростом размера окна не увеличивается скорость

orignal и ты считаешь что виноват буфер

onon Ну он за 1 раз не может отправить больше чем есть в этом буфере

onon 16кбайт

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

onon Т.е. он отправил 1 раз а в след. раз отправлять нечего т.к. буфер пустой

onon Вот я ничего другого не менял, буфер этот в 4 раза поднял, скорость стала в 2 раза выше

onon Максимальная скорость имею в виду

orignal выражайся конкретнее

onon Ладно, сформулирую, напишу.

onon Короче у тебя так сделано, что этот буфер запрашивает новые данные только когда пустой

onon Отсюда все проблемы

onon Я сделал его в 512кб и вижу, что он постепенно уменьшается до нуля по мере отправки, а потом снова набирает 512кб

onon Нужно бы как-то сделать чтобы буфер пополнялся после отправки пачки пакетов

orignal запрашивает откуда? с i2p или с клира?

onon С клира

orignal а ну это кривизна рук ясен пень

orignal я починю

orignal вечером

onon Тот, который m_SendBuffer

onon В стримах

orignal там же не так делается

onon Я по логам вижу что так

orignal там ждем коллбэка от AsycSync и читает клир

orignal AsyncWrite

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

onon Можешь проверить, сделать этот буфер пару мегабайт и в вебконсоли смотреть

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

onon Там с этими буферами у тебя сложный запутанный код, я не могу пока разобраться

onon Кто кого вызывает и когда

orignal я знаю как он работает

orignal ты объясни что требуется

onon Чтобы после отправки пачки пакетов в SendBuffer() он подгружал новую порцию данных из клира в этот буфер

onon Чтобы он не опустошался

onon До нуля

onon SendBuffer()

onon {

onon sendSomePackets;

onon refillBuffer;

onon }

orignal даже если буфер не полностью отослан?

onon Да

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

onon А в чем проблема?

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

onon Проц грузит?

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

onon Ммм...

orignal тут короче думать надо

onon А что значит набивалось в стрим

onon У тебя же буфер не бесконечный

onon Он должен заполнить буфер и встать

onon И ждать

onon Буфер понемногу опустошается - он доливает.

onon Это в какой версии так было. Может я поищу, потестирую

orignal вообще то бесконечный у стрима

orignal ну посмотри историю I2PTunnel.cpp

orignal в этом суть что теперь мы ждем отправки пакета в стрим а не просто запихивания в буфер

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

onon Так?

orignal не так

orignal не 16K а вплоть до 16K

orignal там может и один байт быть например

onon Это понятно

onon Из-за такой работы у вас и не работает интерактив

onon Потому что CC на этом сокете клира не может нормально работать

onon Поэтому ваш iPerf не работает

orignal ну так а что ты то предлагаешь?

onon А по поводу размера буфера в 16кбайт. У нас сделана отправка 1 раз в ~11мс. Т.е. 1000/11*16384=1489454байт/с

orignal мы прочитали с клира в буфер запихали его в стрим

orignal дальше что?

orignal чего мы ждем

onon Получается лимит в ~1,5 мбайта/с

orignal там это лимит стримов

onon Потому что за раз SendBuffer() отправляет только один буфер

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

onon А я думаю нужно делать так: отправил ты из 16кб например 6кб - запрашиваем эти 6кб из сокета и вставляем в конец бкфера

onon И буфер снова полный

orignal ладно подумаю

orignal то есть ты хочешь коллбэ

orignal к

onon Т.е. брать из сокета меньшими порциями и чаще

onon Да

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

onon Да

orignal а не все

orignal сделаю

Most2 12.<taureg> после последнего обновления i2pd-tools не компилится

Most2 12.<taureg> https://xmpp.trus.i2p:5343/upload/b84216eb030e2571c35fc6b97615ae02bf6c762e/hTePIegZIBFh8KadFMQoDmWly3NUm1ZvUWVJBMwC/431fd009-39a9-471a-9c66-510e85a93415.png

Most2 12.<taureg> мало ему

Most2 12.<taureg> шланг тоже не доволен

Most2 12.<taureg> https://xmpp.trus.i2p:5343/upload/b84216eb030e2571c35fc6b97615ae02bf6c762e/tTPbNx2yJ1MUQfdr0wDqAwuFJzIwRfWdfyqHLGpd/e1ae0c60-b409-44e1-95a1-028f3b623425.png

weko onon, orignal я про эту штуку вроде уже давно говорил. видимо сказал хреново

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

weko он и шлёт

weko когда ещё со стримами возился

Vort weko: 16к - это как бы не особо дохуя. наверно ещё где-то есть подобное место

weko Вполне достаточно

onon Нет, там в буфер сокета льёт

onon Пока не заполнит

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

Vort плохо этот механизм помню

onon Да

Vort понятно

onon Ты вычитываешь из буфера - место освобождается

onon Он шлёт акк - получает новые данные

onon Если не хочешь такого поведения - делай recieve buffer на этом сокете маленьким

Vort может так и надо сделать? я, правда, сомневаюсь, что ОС обязана сделать именно такой буфер как заказано

Vort если у стрима 16к, то нафига сокету больше?

onon Если у тебя сокет локальный - то больше и не нужно

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

onon А если удалённый - то малый буфер на приёме ограничит скорость

onon Из-за flow control

Vort смотреть куда bind сделан. вроде

Vort я думаю у 99% юзеров сокет таки локальный. или нет?

onon Я тоже так думаю

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

weko ну через впн но не суть

weko точнее важно, потому что это qg

weko wg'

weko wg

Vort а там не будет ещё одного слоя буферизации?

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

weko wg через udp

Vort onon: думаю это архитектурный вопрос. не будет ли говнокода если так завернуть

onon Просто это всё дополнительные задержки

orignal можно

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

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

orignal так что решили делаем?

orignal как только часть буфера запихнули в стрим вызываем коллбэк с размером?

onon А сложно это сделать?

orignal и читаем сокет на такой же объем

orignal не сдожно

onon Тогда делаем

orignal просто я пытаюсь понять концептуально

orignal что надо

onon Ну вот то что ты описал

onon И размер этого буфера увеличить

onon Чтоб хотяб мегабайт 5 было

onon в секунду имею в виду

orignal на сколько увеличить?

orignal weko считает что даже 16K много

onon Ну сейчас около мегабайта реальной скорости

weko тут проблема что пинг

weko растёт

weko когда упор в скорость

onon Ну вот, если важны задержки - то много, если важна скорость - то мало

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

weko надо сделать чтобы были и то и то нормально

orignal я в упор не понимаю чего мы выигрываем этим

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

orignal у меня есть другое предложение

onon Что сокет отправляет подтверждения когда буфер освобождается

orignal разбивать буфер на пакеты в 1K

onon И получает новую порцию данных

orignal неправда

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

orignal котоырй впихнули

orignal а если мы будем пихать по 1K?

onon А почему именно по 1?

orignal ну наример

orignal можно по 4K

onon Ничего не понимаю

orignal пришел буфер 16K

orignal мы пихаем в стрим 4 пакета по 4K

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

onon Это чтобы не читать по байтам?

onon Типа нагрузка меньше будет?

orignal чтобы аллоцировать фиксированные куски

orignal и да ты будешь пихать по 100 байт например что хорошего

onon Важно что: плохо когда у нас сейчас в буфере осталось 500байт а мы должны в этот такт оправить пять пакетов например

onon А он отправит один получается

orignal то есть в буфере осталось мало а в сокете сидит много и ждет

onon Да

orignal я счас подумаю