No buffer space available

dvserg

Поищите по английскому форуму.

http://freebsd.monkey.org/freebsd-mobile/200605/msg00159.html

Еще у меня такое было когда что-то некорректно настраивал на интерфейсе (бридж). Но давно было не помню.

goliy

Кажется, выцепил проблему

werter

Сорри за оффтоп ;)
@goliy:

…вот, какие стандартные настройки я подкрутил:
1. выставил трубкам qlimit'ы, ибо без них торренты непобедимы. Стало все чудесно, потерь больше нет, пинги отличные, життер еденичка, трубка с торрентами всегда уступает место кому угодно. Вообщем, кулимитов мне очень давно не хватало.

Если можно, по-подробнее - размеры qlimit для каждой трубки. Скриншотами с настройками ВСЕГО шейпера было бы идеально. Заранее очень-и-очень благодарен.

P.s. И как решили проблему ?

goliy

@dvserg:

Поищите по английскому форуму.
http://freebsd.monkey.org/freebsd-mobile/200605/msg00159.html

Мои значения(стандартные) net.inet.udp.maxdgram: 57344 и net.inet.udp.recvspace: 42080, и я считаю их вполне достаточными. Нет, тут что-то пожещще. Но я почти разрулил. Еще пару часов тестов и выложу результат.

@werter:

Сорри за оффтоп ;)
@goliy:

…вот, какие стандартные настройки я подкрутил:
1. выставил трубкам qlimit'ы, ибо без них торренты непобедимы. Стало все чудесно, потерь больше нет, пинги отличные, життер еденичка, трубка с торрентами всегда уступает место кому угодно. Вообщем, кулимитов мне очень давно не хватало.

Если можно, по-подробнее - размеры qlimit для каждой трубки. Скриншотами с настройками ВСЕГО шейпера было бы идеально. Заранее очень-и-очень благодарен.

Смотри в чем тут дело http://forum.pfsense.org/index.php/topic,9129.0.html
Не понимаю, как люди столько лет шейпили торренты без этой возможности? К счастью, в ПФ 2.0 эта возможность идет из коробки, но в 1.2.3 приходится изгалятся так.
Я сегодня-завтра напишу скрипт, который будет проверять и вбивать значения qlimit'ов по крону в файл конфигурации, не портя его. И выложу. подожди сдецл

goliy

Вообщем, таки трабла была описана здесь: http://kerneltrap.org/mailarchive/openbsd-misc/2008/9/14/3293054
А про**ался я на том, что обратил внимание только на доунлоад канал(т.е. на qlanRoot), а аплоад (qwanRoot), видимо, превышал номинальным значением фактическое на какое-то незначительное кол-во килобит. Снизив его с ~18900 до 18432 Kb я совершенно избавился от проблемы!
я вычислил я это таки по RRD графикам. Они в приложении. На котором ясно видно, как момент взлета пинга совпадает с моментом макс нагрузки канала qwanRoot.

–-----------------------------------------------------------------------------------------------------------------------

И да, темка с шейпингом и торрентами. Чтобы все работало чики пуки, добавьте в крон */15 * * * * (отрабатывающий каждые 15мин) скрипт, со след текстом:

#!/bin/sh
if grep "priority 1 hfsc" /tmp/rules.debug
then
sed -i "" 's/bandwidth 0% priority 2 hfsc/bandwidth 0% priority 2 qlimit 500 hfsc/g' /tmp/rules.debug
sed -i "" 's/bandwidth 0% priority 7 hfsc/bandwidth 0% priority 7 qlimit 500 hfsc/g' /tmp/rules.debug
sed -i "" 's/bandwidth 0% priority 1 hfsc/bandwidth 0% priority 1 qlimit 2000 hfsc/g' /tmp/rules.debug && pfctl -A -f /tmp/rules.debug
fi

Вообщем, повторяю, зачем увеличивать некоторые значения qlimit со стандартных 50 написано здесь:
http://forum.pfsense.org/index.php/topic,9129.0.html

Кратко зачем это:
значение qlimit не поддерживается web интерфейсом, а значит, как и любое другое изменение файлов конфига не из веб интерфейса, затерается при любоми нажатии на кнопку apply. А мы сделали скрипт, который монитор файл настроек и, если необходимо (в данном случае это тогда, когда у трубки с приоритетом 1, а обычно это торренты, не назначен qlimit), ввинчивает указанные в нем значения qlimit в указанные трубки и перегружает фаервол. Если же значение присвоено - не делает ничего. Удобно, черт возьми =)

Почему Brandwidth 0% читаем тут http://www.probsd.net/pf/index.php/Hednod%27s_HFSC_explained

Ну и напоследок, мои настройки шейпинга. Они очень скудны, но мне большего и не надо =)

queue qwanRoot bandwidth 18432Kb priority 0 hfsc { qwandef, qwanacks, qP2PUp, qGamesUp, qOthersUpH }
queue qlanRoot bandwidth 47Mb priority 0 hfsc { qlandef, qlanacks, qP2PDown, qGamesDown, qOthersDownH }
queue qwandef bandwidth 0% priority 2 qlimit 500 hfsc ( ecn default linkshare(0% 3000 33%) realtime(37% 3000 1Kb) )
queue qlandef bandwidth 0% priority 2 qlimit 500 hfsc ( ecn default linkshare(0% 5000 68%) realtime(62% 10000 1%) )
queue qwanacks bandwidth 0% priority 7 qlimit 500 hfsc ( linkshare 25% realtime 35% )
queue qlanacks bandwidth 0% priority 7 qlimit 500 hfsc ( linkshare 15% realtime 10% )
queue qP2PUp bandwidth 0% priority 1 qlimit 2000 hfsc ( red ecn linkshare 1Kb )
queue qP2PDown bandwidth 0% priority 1 qlimit 2000 hfsc ( red ecn upperlimit 90% linkshare 1Kb )
queue qGamesUp bandwidth 0% priority 4 hfsc ( linkshare 20% realtime 6% )
queue qGamesDown bandwidth 0% priority 4 hfsc ( upperlimit 20% linkshare 12% realtime 6% )
queue qOthersUpH bandwidth 0% priority 6 hfsc ( ecn linkshare 1% realtime 1% )
queue qOthersDownH bandwidth 0% priority 6 hfsc ( ecn linkshare 1% realtime 1% )

http://doc.pfsense.org/index.php/Traffic_Shaping_Guide со вкладкой Other Documentation в помощь тебе по настройке и понимании шейпинга.

shap.png_thumb

Tamriel

Очень интересно.
Можно по подробнее про qlimit (как сделал чтоб не р2р трафик вытеснял р2р)
и про No buffer space available

у меня постоянно такая картина

miniupnpd[40873]: sendto(udp_notify=12, 192.168.0.1): No buffer space available

dhcpd: send_packet: No buffer space available

спс

goliy

обо всем написал выше.
всетаки буфферы так и плачут. пока ничего с ними не решилось. Попробую еще снизить ширину Root трубок
вот как это выглядит.

про qlimit'ы тоже написано в после выше(гоу по ссылке). Вообще - переход на 2.0 устраняет эту проблему

quality.png_thumb

werter

Ув. goliy! Спасибо за объяснение. У меня pf 2.0 final. Рекомендуемые настройки в файлы /boot/loader.conf и /etc/sysctl.conf внес (для чего они , описано здесь - http://www.zeon.kiev.ua/?p=72) через Edit file. qLimit-ы выставил следующие - 500 для всех , кроме qP2p и qOthersLow - на них поставил 2000 (в qOthersLow попадает весь неопределённый правилами трафик - так визард шейпера сформировал правила. На родительских LAN и WAN qlimit-ы не ставил, ест-но. Ребутнул pf. Ошибок нет.

Теперь о грустном :'(. Життер ДАЛЕКО не единица . Скачет будь здоров. Как добится стабильного пинга ? А при попытке в дочерних очередях в Bandwidth выставить 0 % или 0 Kbit\s идет страшная ругань pf по-поводу того, что сумма дочерних превышает занчение родительской по linkshare , хотя я в linkshare НИЧЕГО не менял. И инета нет , хотя пишет что линк на WAN-е поднят (у меня модем в бридже (ADSL) и pf поднимает pppoe сессию).

Подскажите, где я сплоховал ? Скрин Floating rules прилагаю.

tr_shap_2.0.JPG
tr_shap_2.0.JPG_thumb

goliy

покажи /tmp/rules.debug
если ты прочитал как работает шейпер, то должен понимать, что при брандвифе 0, ты обязан поставить линкшэйр в какое-нибудь, отличное от нуля значение. Причем суммы по всем полосам линкшэйр не должна превышать 100% от канала Root (т.е. заданную ширину всего канала) как в одну так и в другую сторону. А суммы по Реалтайму 90%. при привышении фаервол ругается. и это грозит тем, что все точно ляжет.
А где ты чекаешь життер? я, вот к примеру, находять в москве и проверяя канал на pingtest'e наблюдаю, как половина серваков вообще не хотят меня проверять, тогда как сервер istranet при проверке вообще вешает все мои браузеры, после обновления java, а сервер moskow(как ни странно), показывает ужасные результаты как по пингу так и по життеру, соответственно. и ближайший, нормально работающий, это, как ни странно, питерский. к тому же, какая у тебя уверенность, что пров выдает хороший канал? сначало убедить в этом, проведя все тесты, непосредственно через провод провайдера(без pfsense)
если у тебя есть linux под рукой, проверяй утилитой mtr (my trace route) значение stDev и есть життер. он более точный. сейчас я провел тест на pingtest с автопоиском ближайшего сервака, и он выдал мне пинг 14, життер 7, и не смог проверить потери пакетов, тогда как mtr до я.ру(в течении пары мин) ясно показывает средний пинг 5.8 життер 0.7 и 0.0% потерь.) счастливо живем

Tamriel

goliy попробовал выставить qlimit в текущий мой шейпер и нифига р2р трафик не перекрывается … (иногда speedtest забирает большую часть канала, но когда я пытаюсь посмотреть ролики с ютуба всё мрёт и пинги катастрофа)

Можешь объснить почему выставление qlimit позволяет выгружать трубу р2р и отдавать другим трубам ? (link share само по себе не работает ,я сколько раз пробовал, и параметры m1 d тоже мало чего делают )

спс

goliy

@Tamriel:

goliy попробовал выставить qlimit в текущий мой шейпер и нифига р2р трафик не перекрывается … (иногда speedtest забирает большую часть канала, но когда я пытаюсь посмотреть ролики с ютуба всё мрёт и пинги катастрофа)

Можешь объснить почему выставление qlimit позволяет выгружать трубу р2р и отдавать другим трубам ? (link share само по себе не работает ,я сколько раз пробовал, и параметры m1 d тоже мало чего делают )

спс

ЧИТАЙ ПО ССЫЛКАМ! RTFM! http://forum.pfsense.org/index.php/topic,9129.0.html - про qlimit'ы разговор. про шейпер написано ВЕЗДЕ. например тут http://www.probsd.net/pf/index.php/Hednod%27s_HFSC_explained . В рамках этой темы 3й раз ссылки пишу. прочитай ты уже все, что там написано и вникни в работу шейпера

werter

Quote from: goliy on Today at 06:05:51 am
покажи /tmp/rules.debug

И ещё, после отработки визарда шейпера реалтаймы в очередях вообще не создаются. Думаю , это стандартная конфигурация. И в очереди для всего остального трафика визард не ставит RED. Это тоже по-дефолту.

Мой /tmp/rules.dbg :

altq on pppoe1 hfsc bandwidth 512Kb queue { qACK, qDefault, qP2P, qOthersHigh, qOthersLow }
queue qACK on pppoe1 bandwidth 19.6% qlimit 500 hfsc ( ecn , linkshare 19.6% )
queue qDefault on pppoe1 bandwidth 9.8% qlimit 500 hfsc ( ecn , default )
queue qP2P on pppoe1 bandwidth 4.9% qlimit 2000 hfsc ( ecn , linkshare 4.9% )
queue qOthersHigh on pppoe1 bandwidth 9.8% qlimit 500 hfsc ( ecn , linkshare 9.8% )
queue qOthersLow on pppoe1 bandwidth 2% qlimit 2000 hfsc ( ecn , linkshare 2% )

altq on em0 hfsc queue { qLink, qInternet }
queue qLink on em0 bandwidth 20% qlimit 500 hfsc ( ecn , default )
queue qInternet on em0 bandwidth 15728.64Kb hfsc ( ecn , linkshare 15728.64Kb , upperlimit 15728.64Kb ) { qACK, qP2P, qOthersHigh, qOthersLow }
queue qACK on em0 bandwidth 19.6% qlimit 500 hfsc ( ecn , linkshare 19.6% )
queue qP2P on em0 bandwidth 4.9% qlimit 2000 hfsc ( ecn , linkshare 4.9% )
queue qOthersHigh on em0 bandwidth 9.8% qlimit 500 hfsc ( ecn , linkshare 9.8% )
queue qOthersLow on em0 bandwidth 2% qlimit 2000 hfsc ( ecn , linkshare 2% )

goliy

как ты дошел до таких значений, с десятыми процента? -) в чем проблема-то у тебя? життер? ну, тут трубки не причем, если он всегда такой. ты сделай сначало все, что я написал в предыдущем посту. (соединение без пф, с нормальной утилитой, например mtr. если там будет отличный результат - есть куда стремиться. если нет - проблема на уровень выше)
вообще, тема про буфер спэйс.
шейпер отлично настраивается после прочтения и пережевывания http://doc.pfsense.org/index.php/Traffic_Shaping_Guide при участии Other documentations (ссылки внизу. Если осмысленно въехать в то, что там написано, шейпер настраивается на раздва. если не понять - его никогда не настроить) если не умеете читать английский, Уважаемый dvserg перевел все на русский, даже рекомендации есть: http://forum.pfsense.org/index.php/topic,33870.0.html

goliy

есть еще у кого варианты? идея с увеличенным значение полосы пропускания на материнской трубке отпадает. снизил уже до немогу. До сих пор имеем потери и пинги за 20000 в некоторые странные точечные периоды. Вывожу статистику:
netstat -s -p tcp
tcp:
209778697 packets sent
97517566 data packets (4256116843 bytes)
324488 data packets (371366906 bytes) retransmitted
22175 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
100282788 ack-only packets (0 delayed)
0 URG only packets
279 window probe packets
8583013 window update packets
3409654 control packets
149312851 packets received
50143841 acks (for 4163762671 bytes)
2405915 duplicate acks
13469 acks for unsent data
85283125 packets (433147740 bytes) received in-sequence
457917 completely duplicate packets (289136740 bytes)
322 old duplicate packets
1677 packets with some dup. data (1213387 bytes duped)
11088092 out-of-order packets (3040949322 bytes)
120 packets (60 bytes) of data after window
60 window probes
764961 window update packets
7299 packets received after close
2927 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
793763 discarded due to memory problems
1188550 connection requests
1188335 connection accepts
0 bad connection attempts
0 listen queue overflows
52487 ignored RSTs in the windows
2344477 connections established (including accepts)
2376209 connections closed (including 93302 drops)
691567 connections updated cached RTT on close
692651 connections updated cached RTT variance on close
534912 connections updated cached ssthresh on close
1554 embryonic connections dropped
30514800 segments updated rtt (of 26003440 attempts)
402532 retransmit timeouts
5552 connections dropped by rexmit timeout
1010 persist timeouts
2 connections dropped by persist timeout
0 Connections (fin_wait_2) dropped because of timeout
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
7074305 correct ACK header predictions
82392641 correct data packet header predictions
1188908 syncache entries added
3218 retransmitted
3101 dupsyn
2822 dropped
1188335 completed
0 bucket overflow
0 cache overflow
300 reset
277 stale
0 aborted
0 badack
0 unreach
0 zone failures
1191730 cookies sent
4 cookies received
46850 SACK recovery episodes
68735 segment rexmits in SACK recovery episodes
96526480 byte rexmits in SACK recovery episodes
417122 SACK options (SACK blocks) received
11346326 SACK options (SACK blocks) sent
0 SACK scoreboard overflow

vmstat -z
ITEM SIZE LIMIT USED FREE REQUESTS FAILURES

UMA Kegs: 128, 0, 104, 16, 104, 0
UMA Zones: 480, 0, 104, 0, 104, 0
UMA Slabs: 64, 0, 869, 16, 2057, 0
UMA RCntSlabs: 104, 0, 2501, 15, 2501, 0
UMA Hash: 128, 0, 5, 25, 9, 0
16 Bucket: 76, 0, 66, 34, 85, 0
32 Bucket: 140, 0, 98, 14, 119, 0
64 Bucket: 268, 0, 141, 13, 191, 7
128 Bucket: 524, 0, 831, 2, 1934, 275
VM OBJECT: 128, 0, 30765, 465, 19971621, 0
MAP: 140, 0, 7, 21, 7, 0
KMAP ENTRY: 68, 57456, 23, 369, 21233, 0
MAP ENTRY: 68, 0, 1581, 995, 43122275, 0
DP fakepg: 72, 0, 0, 0, 0, 0
mt_zone: 1032, 0, 293, 127, 293, 0
16: 16, 0, 4281, 5260, 17668570, 0
32: 32, 0, 2430, 395, 9284507, 0
64: 64, 0, 5528, 3086, 1001506570, 0
128: 128, 0, 1014, 426, 428472, 0
256: 256, 0, 2975, 6145, 22098324, 0
512: 512, 0, 216, 64, 54641, 0
1024: 1024, 0, 52, 144, 13993528, 0
2048: 2048, 0, 361, 357, 190179, 0
4096: 4096, 0, 129, 80, 1403807, 0
Files: 76, 0, 789, 2311, 40924628, 0
TURNSTILE: 76, 0, 211, 77, 211, 0
umtx pi: 52, 0, 0, 0, 0, 0
PROC: 696, 0, 82, 58, 992445, 0
THREAD: 560, 0, 146, 64, 325, 0
UPCALL: 44, 0, 0, 0, 0, 0
SLEEPQUEUE: 32, 0, 211, 241, 211, 0
VMSPACE: 236, 0, 41, 87, 991946, 0
cpuset: 40, 0, 2, 182, 2, 0
audit_record: 856, 0, 0, 0, 0, 0
mbuf_packet: 256, 0, 732, 3108, 598589137, 0
mbuf: 256, 0, 3, 1287, 1151674234, 0
mbuf_cluster: 2048, 32768, 3842, 314, 242491157, 0
mbuf_jumbo_pagesize: 4096, 12800, 0, 423, 21203205, 0
mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0
mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0, 0
NetGraph items: 36, 4134, 0, 0, 0, 0
NetGraph data items: 36, 546, 0, 0, 0, 0
g_bio: 132, 0, 0, 3770, 10725147, 0
ata_request: 192, 0, 0, 980, 2561857, 0
ata_composite: 184, 0, 0, 0, 0, 0
cryptop: 60, 0, 0, 0, 0, 0
cryptodesc: 56, 0, 0, 0, 0, 0
VNODE: 276, 0, 31487, 335, 597279, 0
VNODEPOLL: 64, 0, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 48, 125831377, 0
S VFS Cache: 68, 0, 13437, 955, 367847, 0
L VFS Cache: 291, 0, 23, 29, 133, 0
DIRHASH: 1024, 0, 463, 53, 547, 0
NFSMOUNT: 560, 0, 0, 0, 0, 0
NFSNODE: 452, 0, 0, 0, 0, 0
pipe: 396, 0, 6, 44, 541296, 0
ksiginfo: 80, 0, 106, 950, 108, 0
itimer: 220, 0, 0, 36, 1, 0
KNOTE: 68, 0, 611, 2301, 178998840, 0
bridge_rtnode: 36, 0, 0, 0, 0, 0
socket: 416, 204804, 735, 2739, 3676524, 0
ipq: 32, 1130, 0, 0, 0, 0
udpcb: 180, 204820, 15, 95, 936745, 0
inpcb: 180, 204820, 954, 3182, 2378055, 0
tcpcb: 464, 204800, 691, 2581, 2378055, 0
tcptw: 52, 32256, 263, 1609, 1173516, 0
syncache: 104, 51208, 0, 185, 1192168, 0
hostcache: 76, 15400, 1876, 1824, 21483, 0
tcpreass: 20, 2197, 0, 676, 11118468, 0
sackhole: 20, 0, 0, 507, 65423, 0
sctp_ep: 816, 32770, 0, 0, 0, 0
sctp_asoc: 1436, 40000, 0, 0, 0, 0
sctp_laddr: 24, 80040, 0, 290, 7, 0
sctp_raddr: 400, 80000, 0, 0, 0, 0
sctp_chunk: 96, 400000, 0, 0, 0, 0
sctp_readq: 76, 400000, 0, 0, 0, 0
sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0
sctp_asconf: 24, 400055, 0, 0, 0, 0
sctp_asconf_ack: 24, 400055, 0, 0, 0, 0
ripcb: 180, 204820, 1, 87, 36036, 0
unpcb: 168, 204815, 27, 88, 325405, 0
rtentry: 124, 0, 68, 149, 1888, 0
pfsrctrpl: 124, 10013, 0, 0, 0, 0
pfrulepl: 844, 0, 3137, 3343, 97083, 0
pfstatepl: 284, 180012, 23740, 17280, 21127153, 0
pfaltqpl: 224, 0, 16, 86, 720, 0
pfpooladdrpl: 68, 0, 39, 185, 516, 0
pfrktable: 1240, 1002, 307, 80, 1388, 0
pfrkentry: 156, 200000, 129, 271, 4632, 0
pfrkentry2: 156, 0, 0, 0, 0, 0
pffrent: 16, 5075, 140, 2499, 27808559, 0
pffrag: 48, 0, 140, 2512, 14106469, 0
pffrcache: 48, 10062, 0, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0, 0
pfiaddrpl: 100, 0, 34, 83, 179, 0
pfospfen: 108, 0, 696, 132, 26448, 0
pfosfp: 28, 0, 407, 482, 15466, 0
SWAPMETA: 276, 121576, 0, 0, 0, 0
Mountpoints: 720, 0, 4, 6, 4, 0
FFS inode: 124, 0, 31360, 322, 597148, 0
FFS1 dinode: 128, 0, 0, 0, 0, 0
FFS2 dinode: 256, 0, 31360, 320, 597148, 0
md0: 512, 0, 298, 46, 298, 0

Есть идеи что переполняется и как этого избежать? логи полностью молчат. как вызвать этот перегруз и посомтреть статистику именно во время него пока не могу, ибо непонятно что является его катализатором. Overflow пустые, ерроров нет. Я Ломаю голову, что же не так \\ пока добавил upperlimit торрентам на Up и еще понизил значение wanRoot. Таки графики намекают, что скорее всего, фэйлы во время активного аплоада.

ping.png_thumb

sys.png_thumb

traff.png_thumb

packets.png_thumb

goliy

вообщем, проблема так и не решена, но запилена до минимума(выставлением upperlimit'a торрентам в 90%). уже рекордное время нет взлетов пингов (хотя они просто сильно уменьшились) Например, четко отслеживается, что проблема в отсылке пакетов От сервера. чето переполняется, но хер пойми что. В последний раз было четко заметно, как при запуске ntop'a, syslogd посылал инфу на локальный сервер, а инфа, видимо, шла сразу лихой пачкой, т.к. ntop , запускаясь ну прямо Всё про себя рассказывает, syslog послал в лог предупреждение о переполнении буффера. но пинги теперь взлетают только до 30мс, так что жить как-то можно. хотя, конечно, очень не приятно. еще и потери какието, уверен, в этом же ключе\\

traffic.png_thumb

quality.png_thumb

werter

Выражаю огромную благодарность ув. goliy за помощь! Немного разобрался с шейпером.
Теперь очередь с торрентами корректно и довольно быстро уступает очередям с более высоким приоритетом. Только вот пинг скачет все равно :'( Меньше уже, но скачет. Буду разбираться чуть попозже.

P.s. У ТС ,я так понял, стоит pf 1.2.3 Может стоит перейти на 2.0 и проблема с переполнением решится ?

P.s.s. Мои /tmp/debur/rules теперь:

altq on pppoe1 hfsc bandwidth 512Kb queue { qACK, qDefault, qP2P, qOthersHigh, qOthersLow }
queue qACK on pppoe1 qlimit 500 hfsc ( ecn , linkshare 19.6% )
queue qDefault on pppoe1 qlimit 500 hfsc ( ecn , default , linkshare 9.8% )
queue qP2P on pppoe1 qlimit 2000 hfsc ( red , ecn , linkshare 1Kb )
queue qOthersHigh on pppoe1 qlimit 500 hfsc ( ecn , linkshare 9.8% )
queue qOthersLow on pppoe1 qlimit 2000 hfsc ( red , ecn , linkshare 1Kb )

altq on em0 hfsc queue { qLink, qInternet }
queue qLink on em0 qlimit 500 hfsc ( ecn , default , linkshare 20% )
queue qInternet on em0 bandwidth 15728.64Kb hfsc ( ecn , linkshare 15728.64Kb , upperlimit 15728.64Kb ) { qACK, qP2P, qOthersHigh, qOthersLow }
queue qACK on em0 qlimit 500 hfsc ( ecn , linkshare 19.6% )
queue qP2P on em0 qlimit 2000 hfsc ( red , ecn , linkshare 1Kb )
queue qOthersHigh on em0 qlimit 500 hfsc ( ecn , linkshare 9.8% )
queue qOthersLow on em0 qlimit 2000 hfsc ( red , ecn , linkshare 1Kb )

goliy

это уже вопрос, стоит ли мучатся и получить новые проблемы с переписыванием всех правил, таблицы маков (на целый диапазон сети) и много другого, если всего и так полностью хватает.. Думаю, заняться этим, когда прижмет необходимость расширять канал за счет 2го Ван, а пока еще тут покавыряюсь. Дабы даже скрипт уже пашет для qlimit'ов =)
Буду пока криво смотреть в сторону сетевух за 300руб. А там и серв заменим и на 2.0 переедем)

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

werter

Еще, на русском - http://dreamcatcher.ru/2009/11/30/Использование-hierarchical-fair-service-curve-hfsc-в-openbsd/ . Может кому и пригодится.

Tamriel

такой вопрос
правка loader.conf и /etc/sysctl.conf (согласно 1-му посту автора топа)
возможна в nanobsd ?
спс

goliy

@Tamriel:

такой вопрос
правка loader.conf и /etc/sysctl.conf (согласно 1-му посту автора топа)
возможна в nanobsd ?
спс

Можно в nanobsd, в ee, в https://pfsense/edit.php из веб-интерфейса, и даже в православном vi! это же обычный текстовый файл =)