Потери пакетов при увеличении нагрузки_v2
-
Уже заказаны Intel pwla8391gt и E1G42ET. Но как могут создавать потери карты, которые фактически ничего умного не делают. Они же просто как "трубы".
Что интересно по фаерволу? ipfw в pfsense не используется только pf + шейпинг на altq. Тут все стандартно. Вот как сейчас устроен мой шейпинг:queue qwanRoot bandwidth 19Mb priority 0 hfsc { qwandef, qwanacks, qP2PUp, qGamesUp, qOthersUpH }
queue qlanRoot bandwidth 48Mb priority 0 hfsc { qlandef, qlanacks, qP2PDown, qGamesDown, qOthersDownH }
queue qwandef bandwidth 0% priority 2 qlimit 500 hfsc ( ecn default upperlimit 97% linkshare(0% 3000 33%) realtime(37% 3000 1Kb) )
queue qlandef bandwidth 0% priority 2 qlimit 500 hfsc ( ecn default upperlimit 97% 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 upperlimit 97% linkshare 1Kb )
queue qP2PDown bandwidth 0% priority 1 qlimit 2000 hfsc ( red ecn upperlimit 97% linkshare 1Kb )
queue qGamesUp bandwidth 0% priority 4 hfsc ( linkshare 20% realtime 6% )
queue qGamesDown bandwidth 0% priority 4 hfsc ( upperlimit 30% 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% )В трубках ack живет еще трафик tcp на 53ий порт(DNS). A в othersdownH/upH ICMP и UDP dns
-
pwla8391gt е стар 82541PI чипсет. Замени на карточка с 82574L ( EXPI9301CTBLK) . E1G42ET хорошая карточка с 82576 чипсет.На ети карточки можно балансират нагрузке :) (msi-x,interrupt moderation).
Попробаи ипфв шеипер и каптиве портал. -
для второй карточки только pci слот есть. так что 82574L не пойдет
что предполагается под ипфв шейпером?
При переезде на 2.0 попробую максимум шейпинга перенести на dummynet(для наконец-то реальной идеи из веб-интерфейса поделить полосу per host)
Captive portal опять же для чего? Нее, тут что-то со не то, я думаю что-то отконфигурено не правильно в ядре. Только вот что - понять не могу. Конечно может я и не кривой, а просто пров дает канал не А+ качества. Что еще предстоит проверить.. Но пока не так-то просто это сделать -
А с шейпером тоже потери?
-
Может вы имели ввиду "без шейпера"?
Так-то шейпер всегда включен. Не понимаю, как может с вкл. шейпингом теряться Меньше?новый аттач. сегодня чего-то поплохело
upd. Отключил шейпер. пинги бегают куда лучше. и потери нет. вроде как. Но надолго эксперимент затянуть не выйдет.
-
uberi pf sheipa.
Sheip na pf dlq qos,narezka na kanal/trafic ,net dlia na usera.
Poprobai sheip na limiter (ipfw/dummynet) . -
Тут как-то была подобная тема, хотя там было существенно больше пользователей. И все же не будет лишним проверить, что у вас не переполняется State table.
-
Да-да, моя тема была -)
Поэтому эта и называется "Потери пакетов при увеличении нагрузки_v2"
Но там при переполнении table states'ов у нас потери были 100% -
Поэтому эта и называется "Потери пакетов при увеличении нагрузки_v2"
Вот-вот, а посреди обсуждения выясняется, что должна называться "Потери пакетов при использовании шейпера", или по-другому "Пчёлы против мёда". :)
Шейпинг на уровне TCP/IP, особенно при отсутствии Random Early Detection, Explicit Congestion Notification и тупых клиентах, неизбежно вызывает потери пакетов при превышении лимита. А как вы хотели? В волшебство надеюсь не верите? -
Я усердно верю, что RRD графики таки меряются по пингам на оперделенный RRD-сервер. А пинги у нас в отдельной трубе, без потерь с задержек, как и весь остальной ICMP траффик. Так что я не думаю, что при текущих условиях потери распространяются и на них.
queue qOthersDownH on vr0 bandwidth 0 b priority 6 hfsc( red ecn realtime 480Kb linkshare 480Kb )
[ pkts: 7210 bytes: 707522 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ] -
У вас канал провайдера зарезан по полосе? Даже если не зарезан, такое случается при сильной загрузке одного из вышестоящих маршрутизаторов. Не все так бережно относятся к протоколу ICMP.
Ещё я бы обратил внимание на пингуемый хост - у него может превышаться лимит на зхо.
Для уверенности стоит по-тестировать канал ( iperf например) - возможно появится повод наехать на провайдера.
