9.2.3. Stochastic Fairness Queueing
O algoritmo Stochastic Fairness Queuing (SFQ) – ou seja, Enfileiramento Estocástico Justo – é uma implementação simples da família de algoritmos de enfileiramento justo. Ele é menos preciso que os outros, mas ele requer também menos execução de cálculos ao tempo em que é quase perfeitamente justo.
A palavra chave em SFQ é conversação (ou fluxo), que normalmente corresponde a uma sessão TCP ou um fluxo UDP. O tráfego é dividido em um número de filas FIFO relativamente grande, uma para cada conversação. O tráfego é então enviado de um modo cíclico (roundrobin), permitindo mudanças a cada sessão a fim de transmitir dados em ordem.
Isso leva a um comportamento muito equilibrado e evita uma única conversação de roubar a saída do resto. O SFQ é ‘Estocástico’ porque ele realmente não aloca uma fila para cada sessão; ele possui um algoritmo que divide o tráfego em um número limitado de filas usando um algoritmo que executa a função hash.
Devido à função hash, múltiplas sessões podem terminar no mesmo balde, o que dividiria cada chance de envio de um pacote da sessão, mas dividindo a velocidade efetiva disponível. Para evitar essa situação de se tornar perceptível, normalmente o SFQ altera por completo o seu algoritmo hash de sorte que duas sessões colidindo somente funcionariam assim por um curto espaço de tempo na faixa de segundos.
É importante observar que o SFQ somente é útil no caso em que sua interface sainte esteja realmente cheia! Se não estiver então não haverá nenhuma fila em seu roteador Linux e consequentemente nenhum efeito. Adiante descreveremos como combinar o SFQ com outras qdiscs para conseguir uma situação melhor dos dois mundos.
Especificamente, configurar o SFQ na interface Ethernet amarrada ao seu roteador Cable Modem ou ADSL não faz sentido algum sem ajustes adicionais!
9.2.3.1. Parâmetros & Uso
O SFQ é quase auto ajustável:
perturb
Re-configura a função hash uma vez desse vários segundos. Se não definido, a função hash nunca será re-configurada. Não recomendado. O valor de 10 segundos é provavelmente um bom valor.
quantum
Quantidade de bytes que é permitido a uma stream serem des-enfileirada antes que a próxima fila consiga um ligar. É padronizado em 1 pacote máximo dimensionado (MTU dimensionado). Não configure o MTU inferior!
limit
O número total de pacotes que será enfileirado pelo SFQ (após isso ele começa a descartá-los).
9.2.3.2. Configuração Exemplo
Se você tiver um dispositivo que tenha velocidade idêntica de link e taxa real disponível, como um modem na linha telefônica, essa configuração ajudará a fazer justiça:
# tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)
O número 800c: é o número handle automaticamente atribuído, limit significa que 128 pacotes podem esperar nessa fila. Existem 1024 hashbuckets disponíveis para contagem, dos quais 128 podem estar ativos de uma só vez (nenhum pacote a mais entra na fila!). Uma vez a cada 10 segundos, as funções hash são re-configuradas.
9.3. Conselho para qual fila usar quando
Resumindo, essas são as filas simples que realmente gerenciam o tráfego, reordenando, deixando lento ou descartando pacotes.
As dicas seguintes podem ajudar na escolha sobre qual fila usar. Elas mencionam algumas qdiscs descritas no Capítulo 14.
• Para deixar lento o tráfego sainte puramente, use a disciplina Token Bucket Filter (TBF). Funciona até em largura de banda enorme se você escalar o balde;
• Se o seu link estiver cheio verdadeiramente e você não deseja garantir que nenhuma sessão única possa abocanhar a sua largura de banda sainte, use a disciplina Stochastical Fairness Queueing (SFQ);
• Se você tiver um backbone grande e sabe o que você está fazendo, considere o Random Early Drop (RED) – veja o Capítulo Avançado;
• Para ‘tratar’ o tráfego entrante que você não esteja encaminhando, use o Ingress Policer. O tratamento do tráfego entrante é chamado ‘policiamento’, por sinal, não é ‘tratado’;
• Se você *estiver* encaminhando-o, use um TBF na interface pela qual você esteja encaminhando os dados. A não ser que você deseje tratar o tráfego que pode seguir por várias interfaces, nesse caso o único fator comum é a interface entrante. Neste caso use o Ingress Policer;
• Se você não deseja tratar, mas somente deseja ver se sua interface está muito carregada que ela precisa enfileirar, então use a fila pfifo (e não pfifo_fast). Ela possui bandas internas, mas faz contagem do tamanho de seu backlog;
• Finalmente – você pode também fazer “shape-agem social”. Você não consegue ser capaz sempre de usar a tecnologia para conseguir o que você deseja. Usuários experimentam restrições técnicas muito hostis. Uma palavra amiga também pode lhe ajudar a conseguir que a sua largura de banda seja dividida perfeitamente!
Autores Originais dos textos:
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Nenhum comentário:
Postar um comentário