Потери пакетов при увеличении нагрузки_v2
-
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 например) - возможно появится повод наехать на провайдера.
