~AreEnn
~orignal
DUHOVKIN_
Guest7184
Most2
Nausicaa
Nikat
Ruskoye_911
Vort
Xeha
acetone
anon3
b3t4f4c3
fidoid
hypn-direct-nb
karamba_i2p
monkey
nemiga
not_bob_afk
plap
poriori
profetikla
qend
segfault
soos
teeth
tetrimer_
trust
uis
un
unlike
user
vade
weko_
whothefuckami_
orignal
onon
orignal
if (slowTunnel && (int)v.size () < (num/2+1))
orignal
v.push_back (slowTunnel);
orignal
короче если быстрых тоннелей набирается меньше половины лизсета то добавляется медленный
onon
И ты эти две строчки два дня писал?
orignal
нет они там всегда были
orignal
я просто счас посмотрел
onon
Ясно, тогда можно приступать к U роутерам.
orignal
тоннели да посмотрб чтобы не было U-U пиров
onon
Сначала просто чередование сделать, а потом уже пропосал.
orignal
естественно
Vort
Потестировал я алгоритм CC от onon более тщательно, на этот раз с графиками.
Vort
Получились вот такие выводы:
Vort
1. Разрастания очередей, от которых алгоритм должен был защитить, никуда не делись (горбы на графиках).
Vort
2. При этом, добавились тормоза - алгоритм может по минуте держать низкое значение окна без видимых причин.
Vort
3. Иногда, правда, регуляция выглядит правильной. Но, как минимум в некоторых случаях, это просто эффект от искусственного ограничения скорости, маскирующего проблемы алгоритма.
onon
Ох уж эти любители черрипикинга...
onon
1. Этот алгоритм действительно намеренно создаёт очередь. Один раз, при быстром старте и попытке определения BDP. Как только он определяет перегрузку, ср��зу дрейнит и после дрейна включает BDP.
onon
Во всех остальных случаях это не мы создаём очередь, а какой-то кубик, перегружающий наш туннель.
onon
2. Это правда, у меня в тестах так же большую часть времени работает на минимальной скорости. И во всех случаях это срабатывает защита от перегрузки, когда RTT неожиданно резко подскакивает.
onon
Я намеренно добавил ограничения скорости для тестов. Вот рядовой случай: шлю я в туннель равномерно 10кб/с пинги 800-900 всё касиво, и вдруг резко получаю RTT 2622-2741-2313
onon
Естественно, у меня срабатывает защита, я сбрасываю скорость.
onon
Но так как уже минимум, так и продолжаю слать 10 кб/с, и через 2 сек RTT возвращается к нормальным значениям
onon
Вот, как думаешь, это мои пакеты так перегрузили туннель или кто?
onon
Если бы ты добавил вывод BW, графики стали бы понятнее.
onon2
У этого алгоритма есть пока один случай, когда он может сильно перегрузить туннель. Это после быстрого старта, когда включается дрэйн, и отключается защита.
onon2
Если в этот момент кто-то ещё будет перегружать туннель, мы всё равно будем туда слать пакеты с постоянной скоростью.
Vort
"намеренно создаёт очередь. Один раз, при быстром старте" предлагаю посчитать количество горбов на первом графике
Vort
"<onon> Ох уж эти любители черрипикинга..." я провёл 5 полноценных тестов и 1 короткий, нормально графики выглядели только один раз - по последней моей ссылке
Vort
"<onon> Естественно, у меня срабатывает защита, я сбрасываю скорость." - я говорю и всё время говорил только про глобальный лимит, выше которого алгоритм не даёт поднять скорость в принципе
onon2
Вот тебе новая версия, над которой сейчас работаю, та уже не актуальна.
onon2
Тодними лимит как тебе нравится
Vort
"<onon> Вот, как думаешь, это мои пакеты так перегрузили туннель или кто?" - похожий эффект проявляется при смене туннеля
onon2
Погоди, что-то не то я походу скинул
Vort
"<onon2> Тодними лимит как тебе нравится" - я считаю, что его вообще быть не должно, как нету сейчас в алгоритме основной ветки
onon2
Ну так это я для своих тестов делал
onon2
Вообще, возможность ограничить скорость полезна
Vort
так если тесты успешны, то стоит лимит убрать. если неуспешны, то думать, как сделать алгоритм, не зависящий от лимита
Vort
мне кажется, что этот алгоритм без лимита будет глючить ещё больше, чем сейчас
Vort
то есть, это мешает сделать полноценное сравнение с нынешней версией
onon2
Вывод BW сможешь сделать?
onon2
Потому что там скорость регулируется не совсем через окно
Vort
если ты про те значения, которые код считает, то я помню, они какую-то херню показывали, поэтому я их не учитывал
Vort
они мне на локалхосте килобайты/сек выдавали, при том что реально упиралось в глобальный лимит полмега/сек
Vort
короч если скажешь, какую переменную выводить, то добавлю. но для начала стоит перепроверить адекватность расчётов
onon
Да, там расчеты были неадекватные
onon
Да в общем в плейнтестах и остаются сейчас неадекватные
onon
Я пока не переделал.
Vort
ок, перепроверю
Vort
так есть переменная, которую можно на график сразу вывести?
Vort
просто из iperf3 нормально данные я не вытащу
Vort
он показывает через задницу
onon
Есть но локальная, можешь сделать глобальной
onon
int bw = 1000000 * 1.73 / m_PacingTime;
Vort
и вообще я там какие-то адские глюки с новым кодом наблюдал
Vort
"<onon> Есть " - этого достаточно
Vort
я могу просто m_PacingTime залогировать
Vort
а дальше вывернуть его как надо при обработке
onon
Можно и так
Vort
а окно же от PacingTime считается?
Vort
просто в чём тогда отличие будет?
Vort
сейчас сам гляну
onon
Ну так через RTT считается
onon
Если большой RTT окно будет больше
Vort
а, всё, понял
Vort
надо значит и окно и bw выводить
onon
Что логично при нормальной работе, но плохо при заторах
onon
Поэтому я там пока сделал искусственный лимит в 6000RTT
onon
"<onon> Вот, как думаешь, это мои пакеты так перегрузили туннель или кто?" - похожий эффект проявляется при смене туннеля - ну так при смене туннеля, он пытается разогнаться снова
Vort
так ты даже if (freshTunnel) убрал O_o
Vort
и это только наши смены, а есть ещё смены той стороны
Vort
а тьфу, прошу прощения, не убрал, а просто не добавил
onon
Именно
onon
Я пока не переносил на последний транк
Vort
boost::posix_time::milliseconds(m_RTT*2) - так у меня не соберётся. надо к int привести
Vort
ну это я сам сейчас сделаю
Vort
onon: новая версия вообще зависла нахрен. может, конечно, я поломал логированием, но маловероятно
Vort
ResendTimer timeout каждую секунду и всё, на протяжении нескольких минут
onon
Должен каждые две секунды
onon
=)
onon
Ну так с лизсетами что-то
Vort
так он ничего не перепосылал, похоже
Vort
до зависания были "Streaming: packet 73 was not ACKed, resend"
Vort
а потом просто таймер и таймер
onon
Хмм, такое может быть если RTT улетел в небеса
Vort
логи нужны или просто дальше пробовать график получить (вдруг повезёт)?
onon
Рестартуй
Vort
ок
Vort
второй тест получился не показательный - на тормозные туннели попал. разве что горб посредине можно пронаблюдать:
Vort
третий тест тоже медленно пошёл. наверно надо узел будет перегружать, чтобы побыстрее туннель выбрался
onon
Это от времени суток зависит
onon
Когда все туннели перегружены
Vort
хз. рейт нормальный, транзитный трафик нормальный. наверно просто не везёт
Vort
обычные скорости (по данным алгоритма) сейчас получаются 6-18 KB/s
Vort
через X узлы до 50 KB/s получилось разогнаться
Vort
похоже, что это не сеть перегружена, а алгоритм стал осторожнее. но я ещё буду пробовать - может попаду на скоростной туннель
Vort
и это я на 1 хопе тестирую, кстати (1+1/1+1)
onon
Конкретно этот вариант на коротких туннелях не тестировал, не могу ничего сказать. Другие варианты на коротких туннелях работали хуже чем на длинных.
onon
Но бывает через 6 рандомных 1мб/сек жмёт на минимальном ртт
onon
А так да, обычно около 12кб/с
Vort
лимит же 700КБ, так что 1 не может (не должно) быть
Vort
в общем, сейчас "повезло" и один раз проскочила нормальная скорость, попробую графики сделать
onon
Где такой лимит в 700
onon
Я что-то наверно накосячил?
onon
MAX_STREAM_SPEED = 2000000; // in bytes/sec
Vort
у меня так на локалхосте было: PacTime=2640 bw=655kb/s
onon
Это может на старой версии?
Vort
хотя в реальности локалхост может около 15 мегабайт/сек выдать
Vort
короч я вначале график сейчас сделаю
onon
Если на этой, значит математика кривая
onon
Там с интами и округлением проблемы, я не переделывал ещё.
Vort
вот на реальной сети тоже на 140 секунде упёрло в 600 KB
Vort
можешь сам на локалхосте проверить
Vort
вероятно, идёт упор в разрешение таймера
Vort
вот я что нагуглил: "Evidently when wait is called with very small duration of 500 uSecs or lower the processor delays the thread scheduling by atleast 1 millisec."
Vort
на iOS, похоже, тоже есть такая же особенность: stackoverflow.com/questions/25967760/boost-deadline-timer-expires-not-accurate-in-ios
Vort
поэтому я и говорил, что по одному пакету слать не стоит
Vort
и поэтому предполагал, что новый алгоритм в принципе не сможет дать высокую скорость
Vort
хоть десятки мегабайт/секунду, наблюдаемые на локалхосте, в реальной сети будут не скоро, такой тест хорошо позволяет проявить недоработки алгоритма
onon2
Херня, только что разогнал до 1 мбайта/с через 1 хоп.
onon2
Больше чем 1.1мб действительно разгоняться не хочет.
onon2
1.2 пока максимум
onon2
1.3
onon2
Ну проц, действительно немного напрягается на таких скоростях
onon2
В любом случае, 1 мбайт/с с минимальным пингом лучше, чем нынешний кривой кубик
onon2
Если упираемся в лимит по таймеру - будем слать небольшими пачками по 2-3 пакета.
Vort
я сделал ещё один тест. да, скорее всего, _пока что_ упора в таймер нету. просто где-то что-то клинит
onon2
В коде одну цифру поменять
Vort
вот первый локалхостовый тест ^
Vort
вот второй ^. сейчас ещё разок прогоню
Vort
заодно проверил - в CPU упора нету, тестовые узлы где-то по проценту CPU потребляют
onon2
RTT маленький, часто сбрасывает туннель не дожидаясь АСКа. Может сделать минимальную константу...
onon2
если не получили АСК за время стд::макс(100мс, 2*РТТ); Меняем туннель
onon2
Может ещё и сверху ограничить
Vort
я проблему со сбросами из-за превышения RTO видел и с нынешним алгоритмом. поэтому и добавил MIN_RTO
Vort
меня больше удивляет именно заклинивание:
Vort
то есть, хоть иногда 2000 KB/s и проскакивает, алгоритм склонен залипать на PacTime=2640 bw=655kb/s
onon2
Да это просто я от балды быстрый старт сделал. m_PacingTime -= m_PacingTime / (m_ChangePacingTime);
onon2
Там когда уже инкремент большой делится на большое число, и округляется до нуля
onon2
Просто математику переделывать нужно, на более точную
onon2
В плейнтестах такая же фигня, а то и похуже.
onon2
Там скорее всего где-то деление на ноль выскакивает.
Vort
ок, понятно. но хоть в данном случае проблем с таймерами не было, на более высоких скоростях они вполне могут вылезти, а ограничиваться 700 килобайтами - это явное ухудшение по сравнению с тем, что есть сейчас
onon2
Ну так я и не предлагаю ЭТО вставлять в код.
onon2
Это просто демонстрация, как примерно должно всё работать.
Vort
ну особенность в том, что для проверки, как оно работает, ценно иметь возможность упереться локалхостовым тестом в возможности процессора
Vort
я это по многим программам знаю - только идёт упор по CPU - уйма багов вылазят
Vort
ну и подозреваю, что этот лимит также "срезает" некоторые горбы
Vort
то есть, для оценки, насколько хорошо алгоритм борется с горбами, лимита быть не должно
onon2
Ну подыми, тесты же для того и нужны
onon2
Сделай 1мкс
orignal
так че будем поднмать лимит окна?
onon
Нет
orignal
ну ладно
orignal
а то у меня у госткойна все время 128
onon
U узлы починяй
onon
Ну локально себе можешь и поднять
onon
Хуже не станет
orignal
это починю
orignal
чтобы следущий за U не был U
onon
И чтоб концом не был U
orignal
а чем он плох на конце исходящего?
onon
Мы не знаем что на конце входящего
orignal
знаеми
orignal
там то всегда R
orignal
причем ipv4
onon
В любом случае плохо. Потому что каждый коннект будет через интродьюсера с каждым клиентом. А если только в середине, тольк один раз при построении туннеля
orignal
почему?
onon
Ну вот я сервер, у меня конец U, все кто хочет на мой сервис попасть, будут ломиться через интродьюсера
orignal
U же всегда будет делать исходящие
orignal
U у тебя только на исходящих
onon
А, ну значит я буду медленно коннектится к каждому клиенту
orignal
а почему меделнно?
orignal
скорее всего ты вообще будешь по NTCP2
onon
Да, что-то я не так посчитал, но всё равно мне что-то не нравится
orignal
вот кстати да
orignal
когда выбираем пару проверять лиз есои есть в базе не U ли он