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шт.
Может как-то поможет
-
А в 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 ]
-
отпиши подроднее :)
мне интересно !
так как PRIQ болешую полосу может дать! кстати как у тя с ping-ами в играх и вообще ?
спсОй не понимаю, про какую бОльшую полосу ты говоришь. Какая была- такая и есть -)
У меня просто сразу куча перемен - даже и не знаю что хвалить. Сменили систему, жесткий, сетевухи обе и шедулер шейпинга. Стало все сильно лучше. Пинги теперь за 12 часов до я.ру был самый худший 32мс, средний 2.5. Тогда как раньше средний был около 5.5мс.
В игры не играю. Но если есть проблемы - это означает что просто надо добавить для нее порты в floating rules, с засовыванием ее трафика с игровую трубу[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 не хуже, просто обладает чрезмерной функциональностью, которая от него в данном случае не требуется.
-
Может я что-то не так понимаю, но что насчет
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
-
У вас pf 2.0 ? У меня такой листинг выводится по pfctl -vsq. Хотя везде указан Bandwidth 0! Видимо особенность 2.0
Да, листинг был от 1.2.3. В 2.0 я даже не пробывал использовать hfsc. Возможно тут как-то изменилась логика работы. Я не в курсе.