Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Russian
    13 Posts 3 Posters 6.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      goliy
      last edited by

      Кто-нибудь сталкивался с ситуацией, в которой при включенном шедулере 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.2-RELEASE (i386)
      Intel(R) Atom(TM) CPU 330 @ 1.60GHz
      eth: Intel 82574L
      DOM sata, 1Gb
      over 150 users

      1 Reply Last reply Reply Quote 0
      • werterW
        werter
        last edited by

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

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

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

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

        1 Reply Last reply Reply Quote 0
        • G
          goliy
          last edited by

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

          2.0.2-RELEASE (i386)
          Intel(R) Atom(TM) CPU 330 @ 1.60GHz
          eth: Intel 82574L
          DOM sata, 1Gb
          over 150 users

          1 Reply Last reply Reply Quote 0
          • werterW
            werter
            last edited by

            @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» также исчерпана.

            1 Reply Last reply Reply Quote 0
            • G
              goliy
              last edited by

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

              2.0.2-RELEASE (i386)
              Intel(R) Atom(TM) CPU 330 @ 1.60GHz
              eth: Intel 82574L
              DOM sata, 1Gb
              over 150 users

              1 Reply Last reply Reply Quote 0
              • G
                goliy
                last edited by

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

                2.0.2-RELEASE (i386)
                Intel(R) Atom(TM) CPU 330 @ 1.60GHz
                eth: Intel 82574L
                DOM sata, 1Gb
                over 150 users

                1 Reply Last reply Reply Quote 0
                • T
                  Tamriel
                  last edited by

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

                  AMD Athlon™ XP 1700+
                  384MB Ram
                  NanoBSD Boot Slice pfsense0 / da0s1
                  Platform nanobsd (512mb)
                  Version 2.0-RELEASE (i386)
                  built on Wed Sep 14 09:08:10 EDT 2011

                  1 Reply Last reply Reply Quote 0
                  • werterW
                    werter
                    last edited by

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

                    Где 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 ]

                    floating.JPG
                    floating.JPG_thumb
                    shaper.JPG
                    shaper.JPG_thumb

                    1 Reply Last reply Reply Quote 0
                    • G
                      goliy
                      last edited by

                      @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? Они же дублируют др друга, и меньшее все равно игнорируется.
                      Зачем стоят такие большие очереди на все очереди? Как насчет голоса, игр? там же пинг взлетит. Какой в этом смысл?

                      2.0.2-RELEASE (i386)
                      Intel(R) Atom(TM) CPU 330 @ 1.60GHz
                      eth: Intel 82574L
                      DOM sata, 1Gb
                      over 150 users

                      1 Reply Last reply Reply Quote 0
                      • werterW
                        werter
                        last edited by

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

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

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

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

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

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

                        1 Reply Last reply Reply Quote 0
                        • G
                          goliy
                          last edited by

                          Может я что-то не так понимаю, но что насчет
                          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 не хуже, просто обладает чрезмерной функциональностью, которая от него в данном случае не требуется.

                          2.0.2-RELEASE (i386)
                          Intel(R) Atom(TM) CPU 330 @ 1.60GHz
                          eth: Intel 82574L
                          DOM sata, 1Gb
                          over 150 users

                          1 Reply Last reply Reply Quote 0
                          • werterW
                            werter
                            last edited by

                            @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

                            1 Reply Last reply Reply Quote 0
                            • G
                              goliy
                              last edited by

                              @werter:

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

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

                              2.0.2-RELEASE (i386)
                              Intel(R) Atom(TM) CPU 330 @ 1.60GHz
                              eth: Intel 82574L
                              DOM sata, 1Gb
                              over 150 users

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.