как улучшить чувствительность altq к изменениям в очередях?

[mainbrain]

хочу чтобы когда кто то стартовал любые загрузки в любых количествах и в любые стороны,
очередь полезного траффика это не затрагивало (в том числе во время резкого старта закачки), ну или хотя бы держался в ней пинг < 40
но при этом чтобы дефалтовая очередь не имела фиксированный bandwidth, то есть чтобы не приходилось тупо обрезать канал

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Гость]

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

но я так и не понял
почему tcp,udp,icmp должны быть в одной очереди?
попробуйте разделить icmp от них

хочу чтобы когда кто то стартовал любые загрузки в любых количествах и в любые стороны,

а причем здесь icmp?

[mainbrain]

потому что некоторые игры не умеют пинговать клиентов через udp например
а пингуют через icmp , и даже если мы выставим приоритет на порты игры
нас выкинет с сервера из за больших пингов по icmp как например в Counter strike

[mainbrain]

но я так и не понял
почему tcp,udp,icmp должны быть в одной очереди?
попробуйте разделить icmp от них

а чем же они помешают друг другу?

[mainbrain]

тогда какая то из игр получит меньший приоритет , а надо чтобы они были наравне, что за дискриминация,
тем более что icmp с другим приоритетом не сможет показать реальную ситуацию в игровой очереди

[Гость]

ок
как я представляю себе очередь
девочка маша - очередь
петя, вася, дима, стас, егор - мальчики которые хотят побывать в этой очереди
вы разделили на очередь
хорошие мальчики
и остальные
но лучше маше от этого не стало))

[Гость]

тогда какая то из игр получит меньший приоритет , а надо чтобы они были наравне, что за дискриминация,
тем более что icmp с другим приоритетом не сможет показать реальную ситуацию в игровой очереди

у вас игры используют icmp?
странные игры

у вас ассиметричный канал?

[mainbrain]

мне нравится Ваше чувство юмора))
я отделил icmp
все осталось так же
зато видно очередь отдельно от остальных
это удобно

[mainbrain]

у вас игры используют icmp?
странные игры

CS использует обычный пинг =(

у вас ассиметричный канал?

в хлам ассимметричный tvoe tv
3000 на вход
1450 на выход

притом если исходящий занят на 100% то входящему от этого становится тоже плохо (видимо ack пакеты не выходят как надо)

я в очередях чуть чуть еще ограничил скорость, говорят так надо чтобы altq вообще работал, и правда, только увеличиваешь до истинного размера канала и начинается бред

[Гость]

а попробуйте сменить очередь на внутреннем интерфейсе на cbq ?

[mainbrain]

Код: Выделить всё

QUEUE                             BW SCH  PRIO     PKTS    BYTES   DROP_P   DROP_B QLEN BORROW SUSPEN     P/S     B/S
gameport_out                         priq   14     1482   109864        0        0    0                     1     147
def_out                              priq    0   141743 33042380      122    87729    0                   199   49418
icmp_out                             priq   15        0        0        0        0    0                     0       0
gameport_in                          priq   14        6      962        0        0    0                     0       0
def_in                               priq    0   187964  250476K    10579 14584098    5                   267  361130
icmp_in                              priq   15     1844   141082        0        0    0                     1     147

в icmp_out перестали попадать пакеты(

[mainbrain]

написал no state стали попадать

[Гость]

а попробуйте сменить очередь на внутреннем интерфейсе на cbq ?

ай
там еще кучу всего переделывать
толку наверное будет ноль

тогда разве что в соурсах вам долбатся) что бы найти где эта реакция на изменения
хотя если канал реально рогружается
какая может быть реакция?

может лучше как то клиентов разделить?
на разные приоритеты
или проверить сколько максимально клиентов может нормально жить в одной геймочереди

[Гость]

у меня из вариантовы были, это использовать другие типы очередей
priq вы уже используете на обеих интерфейсах
можно на внутреннем интерфейсе попробовать cbq, а на внешнем priq

потом на внутреннем и внешнем cbq

ну и еще поигратся с hsfc

[mainbrain]

altq on $int_if hfsc bandwidth 2800Kb queue {gameport_in def_in icmp_in}
queue gameport_in bandwidth 20% priority 6 hfsc (red)
queue def_in bandwidth 1% priority 0 hfsc (default ,red )
queue icmp_in bandwidth 20% priority 7 hfsc

[mainbrain]

у меня из вариантовы были, это использовать другие типы очередей
priq вы уже используете на обеих интерфейсах
можно на внутреннем интерфейсе попробовать cbq, а на внешнем priq

потом на внутреннем и внешнем cbq

ну и еще поигратся с hsfc

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

[Гость]

я не говорил что возникнут проблемы когда на обоих иф, одинаковые шедулеры
просто нужно понять какой шедуллер плохо делает реакцию
и попробовать другой
может у дрогого лучшее время реакции

[Гость]

hfsc думаю не совсем то
для гем очереди можно попробовать cbq(borrow)
что бы при нехватки полосы, он заимствовала со стандартной

но я все равно запутался
у вас канала не хватает для пропускной способности
или нехватает реакции очереди что бы обрезать запросы

[mainbrain]

так как мой полезный траффик неспособен занять даже 1% канала как следует, то методы, где надо указывать bandwidth (cbq и частично hfsc )для очереди становятся бессмысленными, так как полезный траффик не способен полностью занять полосу допустим в 30% и выдавить из нее обычный трафик
а если разделить полосы жестко и фиксированно (cbq), то получается полоса default остается без полезной скорости в то время как игровая почти пустая, это неэффективно. (если поставить borrow то default задушит игровую)
остаются priority , который есть в hfsc и priq и работает там одинаково и с той же скоростью реакции
в общем полный тупик

[mainbrain]

нехватает реакции очереди что бы обрезать запросы

а также качество приоритезации оставляет желать лучшего

[mainbrain]

вот такая очередь победила лаги

altq on $int_if hfsc bandwidth 2900Kb queue {gameport_in def_in }
queue gameport_in bandwidth 20% priority 7 hfsc (realtime 80%)
queue def_in bandwidth 1% priority 0 hfsc (default ,red, upperlimit (0%, 200, 90%) )

[mainbrain]

но это улучшило работу лишь только протоколу icmp

[mainbrain]

altq on $int_if hfsc bandwidth 2900Kb queue {gameport_in def_in http_in udp_in }
queue gameport_in bandwidth 20% priority 7 hfsc (realtime 80%)
queue def_in bandwidth 10% priority 0 hfsc (default , red )
queue udp_in bandwidth 10% priority 0 hfsc ( red )
queue http_in bandwidth 10% priority 0 hfsc (red , upperlimit (0%, 150, 80%) )

вот такая ничего еще

[mainbrain]

тогда разве что в соурсах вам долбатся) что бы найти где эта реакция на изменения
хотя если канал реально рогружается
какая может быть реакция?

а вот она оказывается
upperlimit (0%, 150, 80%)
upperlimit (m1, d, m2)

m1 -скорость которая держится в очереди первые d миллисекунд с начала закачки , затем меняется на m2
поэтому траффик на графике становится такими волнами(пилообразными)

[mainbrain]

да и еще очень похоже , что ответный трафик, проходя через нат меняет порты , поэтому на внутреннем интерфейсе его трудно опознать,
можно поставить теги , но не напишу же я на внешнем интерфейсе из за этого pass in ... ... ... tag gameport
получается тем самым я открою порты наружу ....