1. Introdução

Este documento mostra a você como usar o HTB. Muitas seções tem exemplos, gráficos (com avaliação de dados) e discussão sobre problemas específicos.

Esta versão do HTB dispõe-se a ser também muito mais escalável. Veja comparação na home page do HTB.

Por favor leia: a ferramenta tc (não apenas HTB) utiliza atalhos para designar taxa de envio. kbps refere-se a kilobytes e kbit refere-se a kilobits! Este é o maior FAQ sobre o tc no linux.

HTB garante que o total de serviço provido para cada classe é no mínimo o total requerido por esta e conforme o que foi designado para cada classe. Quando uma classe requisita menos que o total a ela reservado, a largura de banda remanescente é destribuída para outras classes que requisitaram serviços.

Veja também documento sobre o funcionamento interno do HTB - nele é descrito o objetivo acima mencionado em maiores detalhes.

Nota: Na literatura, usar a largura de banda excedente é denominado de "borrowing" - tomar emprestado. Nós usaremos este termo neste documento em conformidade com a literatura. Entretanto parece-nos ser um termo não muito adequado por não existir nenhuma obrigação de devolver o recurso "tomado emprestado" anteriormente.

Os diferentes tipos de tráfego acima mencionados são representados por classes em HTB. Uma simples representação é exibida na figura acima.
Vamos ver quais comandos usaremos:

tc qdisc add dev eth0 root handle 1: htb default 12

Nota: Em geral (não apenas para HTB, mas para todos qdiscs e classes em tc), manipuladores são escritos em x:y onde x é um inteiro identificando um qdisc e y é um inteiro identificando uma classe pertencente ao qdisc. O manipulador para um qdisc necessita ter zero para seu valor y e o manipulador para uma classe necessita ter um valor diferente de zero para seu valor y. O "1:" acima é considerado como "1:0".

tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps 
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

A primeira linha cria uma classe "raiz", 1:1 embaixo do qdisc 1:. A definição de uma classe raiz é uma que tem o qdisc htb como seu pai. Uma classe raiz, tal como outras classes sob um qdisc htb permite suas filhas tomarem emprestado uma das outras, porém uma classe raiz não pode emprestar de outra. Nós poderíamos ter criado as outras três classes diretamente abaixo do qdisc htb, contudo a largura de banda execedente de uma não estaria disponível para as outras. Neste caso nós queremos permitir o "borrowing", então nós temos de criar uma classe extra para servir como a raiz e colocar as classes que irão realmente trasportar os dados sob aquela. Isto foi definido pelas três linhas subsequentes. O parâmetro ceil será descrito adiante.

Nota: Algumas pessoas vem me perguntando porque elas tem de repetir dev eth0 quando já utilizaram handle ou parent. A razão é que estes manipuladores são alocados para uma interface, ex., eth0 e eth1 podem ter, ambas, uma classe identificada como 1:1.

Nós também temos de definir quais pacotes pertencerão a qual classe. Isto não é realmente relacionado ao HTB qdisc. Veja a documentação do "tc filter" para detalhes. Os comandos serão algo semelhante a isto:

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
   match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
   match ip src 1.2.3.4 flowid 1:11

Nota: O classificador U32 tem um bug de projeto não documentado que provoca entradas duplicadas que podem ser listadas por "tc filter show" quando voce usar classificadores U32 com valores "prio" diferentes.

Você pode observar que nós não criamos um filtro para a classe 1:12. Se tivéssemos feito isto o exemplo poderia ser mais claro, porém desta forma ilustramos a utilização do padrão (default). Qualquer pacote não classificado pelas duas regras acima (qualquer pacote enviado que não seja oriundo do endereço 1.2.3.4) será controlado pela classe 1:12.

Agora nós podemos opcionalmente anexar regras de enfileiramento para as classes folha. Se nada for especificado o padrão é pfifo.

tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10

Inicialmente todas classes geram 90k. Considerando que isto é maior que qualquer uma das taxas especificadas, cada classe é limitada a sua taxa definida. No tempo 3 quando nós paramos de enviar pacotes da classe 0, a taxa alocada a esta classe é realocada para as outras duas classes porporcionalmente a suas taxas definidas, uma parte para a classe 1 e seis partes para a classe 2. (O crescimento na classe 1 é difícil de ver porque é de apenas 4 kbps.) Similarmente ao tempo 9 quando o tráfego da classe 1 é interrompido e sua largura de banda é realocada para as outras duas (e o incremento na classe 0 é semelhantemente ruim de ver.) No tempo 15 é fácil visualizar a redistribuição da classe 2 em três partes para a classe 0 e em uma parte para a classe 1. No tempo 18 ambas classes 1 e 2 são paradas então a classe 0 consegue todo tráfego de 90kbps que requisitou.

Agora chegou o momento de tocarmos no conceito de quantums (cotas). Quando muitas classes querem tomar emprestado largura de banda a classe pai fornece a cada uma delas um determinado número de bytes antes de servir as outras classes concorrentes. Este número é denominado cota. Você deveria observar que, quando diversas classes estiverem disputando pela largura de banda de seus pais a obterão proporcionalmente a suas cotas. É importante saber que para operações precisas as cotas necessitam ser o menor possível e maior que o MTU.
A via de regra você não precisa especificar cotas manualmente porque HTB escolhe valores precomputados. Ele calcula a cota da classe (quando você a adiciona ou a modifica) baseado na taxa desta dividida pelo parâmetro global r2q. Seu valor padrão é 10 e este valor é bom para taxas de 15kBps (120 kbit) por que o MTU típico é de 1500. Para taxas muito baixas especificar o r2k 1 quando o qdisc for criado - isto é bom para 12 kbit que deve ser suficiente. Se você precisar você pode especificar a cota manualmente quando acrescentar ou modificar uma classe. Você pode desprezar avisos no log se o valor precomputado vier parecer ruim. Quando você especificar a cota na linha de comando o r2q é ingnorado para aquela classe.

Notas: Regras de classificação de pacotes podem ser aplicadas para nós internos também. Então você tem que vincular outra lista de filtros para o nó interno. Finalmente você poderá alcançar classe folha ou especial 1:0. A taxa fornecida para uma classe pai será a soma das taxas de suas classes filhas.

Os comandos agora são os seguintes:

tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 40kbps ceil 100kbps
tc class add dev eth0 parent 1:2 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:2 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

O gráfico abaixo difere do anterior porque no tempo 3 (quando o tráfego WWW para) os outros de A são limitados a 20kbps. Consequentemente o cliente A consegue apenas 20kbps no total e os 20kbps não utilizados são alocados a B. A segunda diferença é quando o tráfego de B é interrompido no tempo 15. Sem o limite superior, toda a largura de banda de B seria destinada a A, mas agora só é permitido apenas 60kbps e os 40kbps restantes permanecem sem uso.

Esta característica pode ser útil para ISPs (provedores de serviço internet) porque eles provavelmente desejam limitar o total de serviços fornecidos a seus clientes quando outros clientes não estão utlizando suas respectivas cotas. (ISPs provalvemente querem que seus clientes paguem mais por serviços melhores.) Lembre-se que as classes raiz não tem permissão de tomar emprestado, então não é realmente essencial especificar limite para elas.

Se o cburst é pequeno (idealmente no tamanho de um pacote) ele forma rajadas para não execeder o ceil (taxa limite) da mesma maneira como peakrate do TBF faz (TBF é outro qdisc e peakrate um de seus parâmetros).

Quando você regula o burst para uma classe pai menor que para alguns filhos então você deveria esperar que a classe pai venha ficar impedida de prosseguir ocasionalmente (porque os filhos requisitam mais do que a classe pai pode manipular). HTB irá lembrar destes bursts negativos em até um minuto.

Você pode se questionar porque precisa de bursts. Bem, ele é o modo fácil e simples de melhorar tempos de resposta em links congestionados. Por exemplo o tráfego WWW é bursty (de rajada). Você solicita uma página, a recebe e então a lê. Durante o tempo de inatividade o burst "carregará" novamente.

Nota: Tanto o burst quanto o cburst de uma classe deve sempre ser, no mínimo, igual ao de seu filho que os tiver maiores.

No gráfico você pode ver o caso do capítulo anterior onde eu modifiquei o burst das classes vermelha e amarela (agência A) para 20kb porém cburst permaneceu padrão (cca 2 kb).
O pico verde no tempo 13 é devido ao burst configurado na classe SMTP. Classe A. Esta manteve-se abaixo do limite desde o tempo 9 e acumulado 20 kb de burst. O pico é até 20kbps (limitado pelo ceil porque ela tem cburst próximo ao tamanho do pacote).
O leitor atento pode questionar porque não há picos no vermelho e no amarelo no tempo 7. Isto acontece porque o amarelo ja está no limite superior e ele não tem mais espaço para rajadas.
Existe pelo menos um resultado indesejável - a cratera lilás no tempo 4. Isto é porque eu intencionamente "esqueci" de adicionar burst para o link da classe raiz (1:1). Ela recordou do pico do tempo 1 e quando no tempo 4 a classe azul necessitou tomar emprestado taxa da amarela ela negou e compensou ela mesma (a classe raiz).

Limitação: quando você opera com taxas altas em computador com temporizador de baixa resolução você precisa configurar burst e cburst mínimos para todas classes. A resolução do temporizador em sistemas i386 é de 10ms e em Alphas é de 1ms. O burst mínimo pode ser calculado como max_rate*timer_resolution. Então para 10Mbit em um modesto i386 você precisa de burst de 12kb.

Existe também o segundo aspecto do problema. É o atraso total do pacote. Este é relativamente difícil de medir em ethernet por ser muito rápida (o atraso é insignificante). Porém existe uma fácil solução. Nós podemos adicionar uma classe HTB simples com a taxa limitada a menos de 100 kbps e uma segunda classe HTB (a que nós mediremos) como filho. Então nós podemos simular um link lento com grandes atrasos.
Com o objetivo de simplificar usei um simples cenário com duas classes:

# qdisc para simulação de atraso
tc qdisc add dev eth0 root handle 100: htb
tc class add dev eth0 parent 100: classid 100:1 htb rate 90kbps

# qdisc realmente medido
tc qdisc add dev eth0 parent 100:1 handle 1: htb
AC="tc class add dev eth0 parent"
$AC 1: classid 1:1 htb rate 100kbps
$AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps prio 1
$AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps prio 1
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 2
tc qdisc add dev eth0 parent 1:11 handle 21: pfifo limit 2

O simulador é configurado para gerar 50 kbps para ambas classes executando no tempo 3s o comando:

tc class change dev eth0 parent 1:2 classid 1:10 htb \
 rate 50kbps ceil 100kbps burst 2k prio 0

# tc -s -d qdisc show dev eth0
 qdisc pfifo 22: limit 5p
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc pfifo 21: limit 5p
 Sent 2891500 bytes 5783 pkts (dropped 820, overlimits 0) 

 qdisc pfifo 20: limit 5p
 Sent 1760000 bytes 3520 pkts (dropped 3320, overlimits 0) 

 qdisc htb 1: r2q 10 default 1 direct_packets_stat 0
 Sent 4651500 bytes 9303 pkts (dropped 4140, overlimits 34251) 

tc -s -d class show dev eth0
class htb 1:1 root prio 0 rate 800Kbit ceil 800Kbit burst 2Kb/8 mpu 0b 
    cburst 2Kb/8 mpu 0b quantum 10240 level 3 
 Sent 5914000 bytes 11828 pkts (dropped 0, overlimits 0) 
 rate 70196bps 141pps 
 lended: 6872 borrowed: 0 giants: 0

class htb 1:2 parent 1:1 prio 0 rate 320Kbit ceil 4000Kbit burst 2Kb/8 mpu 0b 
    cburst 2Kb/8 mpu 0b quantum 4096 level 2 
 Sent 5914000 bytes 11828 pkts (dropped 0, overlimits 0) 
 rate 70196bps 141pps 
 lended: 1017 borrowed: 6872 giants: 0

class htb 1:10 parent 1:2 leaf 20: prio 1 rate 224Kbit ceil 800Kbit burst 2Kb/8 mpu 0b 
    cburst 2Kb/8 mpu 0b quantum 2867 level 0 
 Sent 2269000 bytes 4538 pkts (dropped 4400, overlimits 36358) 
 rate 14635bps 29pps 
 lended: 2939 borrowed: 1599 giants: 0

8. Compilando, encontrando bugs e enviando relatórios de erros

Para trabalhar com kernels mais antigos é necessário aplicar o patch e recompilá-los. Baixe os fontes do kernel e execute patch -p1 -i htb3_2.X.X.diff para aplicar o patch. Então execute make menuconfig;make bzImage como antes. Não esqueça de habilitar QOS e HTB.
Você também tem de utilizar a ferramenta tc com patch. O patch também está em downloads ou você pode baixar o binário precompilado.

Se você julga ter encontrado um erro eu irei avaliar o relatório de erro. Para oopses eu preciso da saída do ksysmoops. Para comportamentos estranhos do qdisc adicione o parâmetro debug 3333333 no seu tc qdisc add .... htb. Ele irá registrar muitos megabytes para o recurso do syslog kern level debug. Voce provavelmente desejará adicionar uma linha como:
kern.debug -/var/log/debug
no seu /etc/syslog.conf. Então compacte o log com o bzip e envie-o para mim por e-mail (até 10MB após o bzip) conjuntamente com a descrição do problema e o momento em que este ocorreu.

Postado por brain em fevereiro 8, 2004 10:08 AM