On Mar 16, 2011, at 10:44 AM, Eduardo Schoedler wrote: > Em 15/03/2011 08:47, Luiz Otavio O Souza escreveu: >> E que depende do tamanho máximo da fila, configurado aqui: >> >> # sysctl net.inet.ip.intr_queue_maxlen >> net.inet.ip.intr_queue_maxlen: 256 >> >> (256 me parece pouco para um ambiente de alto trafego, com várias >> placas/interfaces) > > Cuidado ao mexer com o tamanho das filas, existe um problema chamado > "Bufferbloat". > > Alguma referência: > > http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferbl > oat-in-home-routers-and-operating-systems/ > > http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-with > -your-switch/ > http://gettys.wordpress.com/2010/12/02/home-router-puzzle-piece-two-fun-with > -wireless/
Eduardo, Isso é mais comum no envio, onde você define um buffer muito grande e só começa trabalhar (enviar de fato) quando os dados atingem a metade do buffer (por exemplo). Mas nesse caso, trata-se de pacotes recebidos, a placa de rede já recebeu o pacote (já esta com ele na memória) e ele foi descartado pois a fila de processamento de pacotes para o protocolo 'IP' encheu... Como ele tem CPU sobrando e tinha drops nessa fila, eu apontei a sysctl que ele precisa alterar para evitar os drops. É de esperar alguma cautela por parte do 'operador', pois como já comentei, toda alteração que você faz e se distancia do 'GENERIC', seu risco aumenta, aqui não é diferente. Mas também é de se esperar que um sistema 'genérico' precise de alguns ajustes para se comportar bem em operações mais exigentes (como um router de alto trafego), a questão é entender e alterar só o que é preciso (e evitar criar novas mutações dos muitos bugs já existentes :)). []'s Luiz ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
