PRIQ. бьем по торрентам



  • Кто-нибудь сталкивался с ситуацией, в которой при включенном шедулере PRIQ торренты очень борзеют. В версии 1.2.3 в такой ситуации и при hfsc, я легко отделался увеличением очереди qlimit до 2000 в трубках с торрентами. Сейчас же это им как слону дробина. Я не скажу, что они совсем не конролируются, процентов 10 таки от канала отдают. Но что это за фигня?
    Это PRIQ так не комильфо работает, или у меня торрент-качки озверели и контролю не поддаются?)
    Вот настройки шейпера, если интересно. Все стандартно. Только все не пойму почему по дефолту стандартной трубкой вылупляется p2p, а на лан-интерфейсе не появляется  qOthersDefault.. Я ее досоздал и дефолт переназначил. Имхо, должно же все работать\

    $ pfctl -vsq
    queue qACK on re0 priority 6 priq( red ecn )
     [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qOthersDefault on re0 priority 3 priq( red ecn default )
     [ pkts:         38  bytes:       2236  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qP2P on re0 qlimit 2000 priq( red ecn )
     [ pkts:    5832443  bytes: 2186492510  dropped pkts:    884 bytes: 362836 ]
     [ qlength:  98/2000 ]
    queue qGames on re0 priority 5 priq( red ecn )
     [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qOthersHigh on re0 priority 4 priq( red ecn )
     [ pkts:       2824  bytes:     786902  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qOthersLow on re0 priority 2 priq( red ecn )
     [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qACK on vr0 priority 6 priq( red ecn )
     [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qP2P on vr0 qlimit 2000 priq( red ecn )
     [ pkts:    4968156  bytes: 5384350306  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/2000 ]
    queue qGames on vr0 priority 5 priq( red ecn )
     [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qOthersHigh on vr0 priority 4 priq( red ecn )
     [ pkts:        840  bytes:      62164  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qOthersLow on vr0 priority 2 priq( red ecn )
     [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]
    queue qOthersDefault on vr0 priority 3 priq( red ecn default )
     [ pkts:    1356912  bytes: 1593736816  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/50 ]

    ОТВЕТ ТУТ: http://forum.pfsense.org/index.php/topic,43023.msg222978.html#msg222978



  • Пф версии 2.0 Финал.

    Хм, у меня тоже торрентовская труба после визарда стоит первой во Флоатинг и кДефаулт на ЛАН не создавалась. Вместо нее другая была. Пришлось руками делать. Думается , это особенность работы визарда (?)

    Но торренты все рубятся мигом (HFSC) при появление трафика c более высоким приоритетом!

    З.ы. Может , стОит снести шейпер и по-новой создать? Мне кадась такое помогало.



  • Уже пересносил. Все один в один.
    И да, я замечаю, что рубятся, когда нагрузка не высока. По средине дня даже если канал торрентами забит - трафик распределяется в соответствии с приоритетом. Но вечером, в Часы наивысшей нагрузки, когда онлайн около 60 пользователей, все резко становится плохо.
    А в hfsc насколько  знаю приоритет - не учитывается. А мне нужно именно так, чтобы было проще, без фиксированной длинны канала. dummynet рубит все на трубки с фикс шириной per user, а PRIQ делит все на акноладжи, все существенное, и все остальное по приоритетам. Т.е. достигается ровно то, что мне и нужно. Но не при любой нагрузке, к сожалению. Такое ощущение, что когда торрентов уж Оочень много, он не успевает приоритезировать этот траффик…
    Попробовал установить для Первого правила floating, которое гребет весь UDP траффик в торрентовую трубку, Maximum number of established connections per host  в 300шт.
    Может как-то поможет



  • @goliy:

    А в hfsc насколько  знаю приоритет - не учитывается…

    Хм, как это не учитывается приоритет ? http://dreamcatcher.ru/2009/11/30/Использование-hierarchical-fair-service-curve-hfsc-в-openbsd/ .

    Диапазон приоритетов для HFSC и cbq может принимать значения от 0 до 7, а для priq диапазон равен от 0 до 15. Приоритет 0 является самым низким приоритетом и назначается наименее важным данным. Если приоритет на задан, то в качестве значения по умолчанию используется 1 приоритет. Очереди типа Priq с более высоким приоритетом всегда обслуживаются первыми. Cbq и очереди типа HFSC с более высоким приоритетом обслуживаются первыми в случае, если канал выбран полностью, а полоса пропускания «realtime» также исчерпана.



  • ну значит я знал не правильно -) Но сильно проблему это не меняет. Неужели таки на hfsc переезжать и больше нет предложений?



  • Таки все-таки стандартные правила шейпер-визарда надо хорошо осмыслять =)
    Поставив галочку "Метить весь некатегоризированный траффик как p2p я тем самым дал согласие на то, что стандартной трубкой будет трубка для торрентов. Так как я использую Сквид+СквидГвард, Весь прокси-траффик идет, не зависимо от правил фаервола, в дефолтную трубку. Чтобы этого не допускать, я изначально менял дефолтную трубку с qp2p на qOthersDefault.
    НО! я не предположил, что этот дефот и был основным что сделала функция CathAllP2P. Все решилось добавлением 2х первых правил во floating rules, глосящие "Ваще весь трафик пихаем в qp2p", а второе правило- "на весь udp трафик устанавливаем ограничение на established connections per host в 200" или около того штук. Все, торренты усмеренные и тусят в сторонке.
    Может кому будет интересно



  • отпиши подроднее :)
    мне интересно !
    так как PRIQ  болешую полосу может дать! кстати как у тя с ping-ами в играх и вообще ?
    спс



  • Хм.. У меня с такими настройками в шейпере и во флоатинг торренты ВСЕГДА уступают трафик очередям с более высоким приоритетом независмо от кол-во торрентоводов :

    Где qOthersLow - трубка для всего остального трафика, в том числе и для p2p.

    [2.0-RELEASE][root@pfsense2.localdomain]/root(1): pfctl -vsq
    queue root_pppoe1 on pppoe1 bandwidth 512Kb priority 0 {qACK, qDefault, qOthersH            igh, qOthersLow}
      [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/ 50 ]
    queue  qACK on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn linkshare 97.28Kb              )
      [ pkts:      5623  bytes:    231875  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qDefault on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn default links            hare 46.08Kb )
      [ pkts:      1742  bytes:    638859  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersHigh on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn linkshare              46.08Kb )
      [ pkts:        641  bytes:      40859  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersLow on pppoe1 bandwidth 512Kb qlimit 3000 hfsc( red ecn linkshare              1Kb upperlimit 460.80Kb )
      [ pkts:      2598  bytes:    1344157  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/3000 ]
    queue root_em0 on em0 bandwidth 1Gb priority 0 {qInternet}
      [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/ 50 ]
    queue  qInternet on em0 bandwidth 14.68Mb hfsc( red ecn upperlimit 14.68Mb ) {qA            CK, qOthersHigh, qOthersLow, qDefault}
      [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/ 50 ]
    queue  qACK on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn linkshare 2.79Mb              )
      [ pkts:      2702  bytes:    290403  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersHigh on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn linkshare              1.32Mb )
      [ pkts:        180  bytes:      37470  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersLow on em0 bandwidth 14.68Mb qlimit 3000 hfsc( red ecn linkshare              1Kb upperlimit 13.21Mb )
      [ pkts:      1891  bytes:    548402  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/3000 ]
    queue  qDefault on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn default links            hare 1.32Mb )
      [ pkts:      10525  bytes:  11509590  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]






  • @Tamriel:

    отпиши подроднее :)
    мне интересно !
    так как PRIQ  болешую полосу может дать! кстати как у тя с ping-ами в играх и вообще ?
    спс

    Ой не понимаю, про какую бОльшую полосу ты говоришь. Какая была- такая и есть -)
    У меня просто сразу куча перемен - даже и не знаю что хвалить. Сменили систему, жесткий, сетевухи обе и шедулер шейпинга. Стало все сильно лучше. Пинги теперь за 12 часов до я.ру был самый худший 32мс, средний 2.5. Тогда как раньше средний был около 5.5мс.
    В игры не играю. Но если есть проблемы - это означает что просто надо добавить для нее порты в floating rules, с засовыванием ее трафика с игровую трубу

    @werter:

    [2.0-RELEASE][root@pfsense2.localdomain]/root(1): pfctl -vsq
    queue root_pppoe1 on pppoe1 bandwidth 512Kb priority 0 {qACK, qDefault, qOthersH            igh, qOthersLow}
      [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/ 50 ]
    queue  qACK on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn linkshare 97.28Kb              )
      [ pkts:      5623  bytes:    231875  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qDefault on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn default links            hare 46.08Kb )
      [ pkts:      1742  bytes:    638859  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersHigh on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn linkshare              46.08Kb )
      [ pkts:        641  bytes:      40859  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersLow on pppoe1 bandwidth 512Kb qlimit 3000 hfsc( red ecn linkshare              1Kb upperlimit 460.80Kb )
      [ pkts:      2598  bytes:    1344157  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/3000 ]
    queue root_em0 on em0 bandwidth 1Gb priority 0 {qInternet}
      [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/ 50 ]
    queue  qInternet on em0 bandwidth 14.68Mb hfsc( red ecn upperlimit 14.68Mb ) {qA            CK, qOthersHigh, qOthersLow, qDefault}
      [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/ 50 ]
    queue  qACK on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn linkshare 2.79Mb              )
      [ pkts:      2702  bytes:    290403  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersHigh on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn linkshare              1.32Mb )
      [ pkts:        180  bytes:      37470  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]
    queue  qOthersLow on em0 bandwidth 14.68Mb qlimit 3000 hfsc( red ecn linkshare              1Kb upperlimit 13.21Mb )
      [ pkts:      1891  bytes:    548402  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/3000 ]
    queue  qDefault on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn default links            hare 1.32Mb )
      [ pkts:      10525  bytes:  11509590  dropped pkts:      0 bytes:      0 ]
      [ qlength:  0/500 ]

    Ой, как все непонятно.
    Зачем торрентам такой апперлимит?
    Зачем установлено одновременно значение для linkshare и bandwidth? Они же дублируют др друга, и меньшее все равно игнорируется.
    Зачем стоят такие большие очереди на все очереди? Как насчет голоса, игр? там же пинг взлетит. Какой в этом смысл?



  • Зачем установлено одновременно значение для linkshare и bandwidth? Они же дублируют др друга, и меньшее все равно игнорируется.

    Ау, а ничего что, Bandwidth стоит 0 (нуль! ) кбит\с . И где тут дублирование ? Мне помнится что кто-то с ником goliy в http://forum.pfsense.org/index.php/topic,41947.0.html писал о "почему Brandwidth 0%" и размер linkshare тоже далеко не нуль у него там был . Не ? Не так ?

    Зачем стоят такие большие очереди на все очереди? Как насчет голоса, игр? там же пинг взлетит. Какой в этом смысл?

    Голоса - нет, игр - тоже. Пинг , конечно, не 2.5 как у вас, но и не 20. Где-то около 10 разница. Мне хватает.

    Если я что-то не так выставил - укажите , как более подкованный в этих вопросах,  где и что. Будет не только мне полезно, поверьте.

    Заранее благодарен.



  • Может я что-то не так понимаю, но что насчет
    queue  qDefault on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn default linkshare 46.08Kb )
    queue  qACK on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn linkshare 97.28Kb )
    queue  qOthersHigh on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn linkshare 1.32Mb )

    вот о чем я
    Все значения линкшэйр учитываться при таких настройках не будут.
    Есть смысл указывать либо везде только bandwidth, а линкшэйр в то же время ставить 0,
    либо линкшэйр, тогда как бандвиф везде будет 0. Это не обезательно, просто понятнее, чтобы не путаться в и без того куче значений

    в примере по ссылке, показано как раз пример 2:
    queue qP2PDown bandwidth 0% priority 1 qlimit 2000 hfsc (  red ecn upperlimit 90% linkshare 1Kb )

    Так же будет не лишним добавить, что в той ситуации, апперлимит был необходим чтобы гарантировать прочий траффик. Но это был проблемный вариант, т.к. были потери на максимальной нагрузке. Как выяснилось, в ЧНН, провайдер давал не полный(или не совсем полный) канал. Таким образом, снижение полосы материнских труб на Точно Гарантированное значение, дало эффект, благодаря которому от апперлимитов стало возможным отказаться.
    И что касается меня, я пришел к выводу, что оптимальным в моей ситуации было переехать на PRIQ+Dummynet. Благодаря этому решению мы имеем возможность приоритезировать общий пользовательский трафик, гасить торренты, двать приоритет критичному траффику и в то же время (с помощью dummynet'a) предоставлять юзерам фиксированные каналы (aka тарифы)
    Еще раз, для понимания, уточняю, что hfsc не хуже, просто обладает чрезмерной функциональностью, которая от него в данном случае не требуется.



  • @goliy:

    Может я что-то не так понимаю, но что насчет
    queue  qDefault on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn default linkshare 46.08Kb )
    queue  qACK on pppoe1 bandwidth 512Kb qlimit 500 hfsc( red ecn linkshare 97.28Kb )
    queue  qOthersHigh on em0 bandwidth 14.68Mb qlimit 500 hfsc( red ecn linkshare 1.32Mb )

    вот о чем я
    Все значения линкшэйр учитываться при таких настройках не будут.
    Есть смысл указывать либо везде только bandwidth, а линкшэйр в то же время ставить 0,
    либо линкшэйр, тогда как бандвиф везде будет 0. Это не обезательно, просто понятнее, чтобы не путаться в и без того куче значений

    У вас pf 2.0 ? У меня такой листинг выводится по pfctl -vsq. Хотя везде указан Bandwidth 0! Видимо особенность 2.0



  • @werter:

    У вас pf 2.0 ? У меня такой листинг выводится по pfctl -vsq. Хотя везде указан Bandwidth 0! Видимо особенность 2.0

    Да, листинг был от 1.2.3. В 2.0 я даже не пробывал использовать hfsc. Возможно тут как-то изменилась логика работы. Я не в курсе.


Log in to reply