Helio Luchtenberg Junior wrote: [cut]
No Cisco, quanto maior o "peso", menos prioridade esse pacote vai ter.
No Dummynet, aparentemente o sentido e' inverso. Ou seja, o que tiver o maior
"weight" vai passar primeiro. Num caso o "weight" e' interpretado como
"custo", e no outro como "prioridade".
Alguem poderia confirmar isso?
[cut]
Não exatamente uma coisa, nem outra.
É apenas WF^2Q9. O “Worst-case Fair Weight Fair Queueing” funciona como seu nome indica que ele o faça. Quanto menor o peso menos pacotes são enfileirados em pról do fluxo em questão. Vale a pena revisar um pouco como funciona o controle do link implementado pelo Dummynet. É baseado em filas, à cada túnel é definido um tamanho padrão de fila, normalmente indicado em bytes ou buckets. Pouca gente considera a opção “queue” de cada “pipe”, com certa razão porque usar o padrão (omitindo a opcão) normalmente é o suficiente, mas em certos caso pode ser otimizado. Mas o controle do dummynet é todo implementado em filas. A limitação de banda funciona da seguinte forma.. cada vez que a fila “encher”, de origem e com destino ao fluxo identificado por uma túnel (pipe X all from ORIG to DST) a velocidade (config pipe X bw N) é obtida controlando o número de pacotes na fila, e de quanto em quanto tempo essa fila é “liberada”, ou seja seu fluxo é processado (e se torna consumo de link).
O comportamento usual de um pipe por si só, é FIFO, e esse comportamento só pode ser modificado mudando as filas. O controle é “droptail” onde os que chegarem quando a fila estiver cheia, se ainda não for hora de liberar seu fluxo, são omitidos. Mas não são dropados de verdade, vão pro buffer do SO, e assim que a fila é liberada entram nela (vazia), assim é raro quando é necessário a retransmissão do pacote (droptail dropa pro buffer).
O resto do comportamento do dummynet também é baseado nas filas. Por exemplo delay, altera a transmissao pacote à pacote que esteja na fila... plr (packet loss rate) dropa X pacotes a cada N que passarem, etc, etc. Tudo é fila, logo, o controle de fila é o que deve ser melhor entendido.
Se apenas uma fila compete (concorrência) por 1 túnel, não tem jeito, é droptail e é FIFO. Mas se mais de 1 fila compete pelo túnel (pipe) ai você pode modifcar os “pesos” das filas. Então chegamos onde realmente importa. A definição de pesos nesse cenário não pode ser interpretada como “prioridade”. Primeiro, toda fila ou conjunto de filas devem sempre estar conectadas à um pipe, um túnel, que por sua vez pode ter ainda tamanho customizado de sua fila.
O fluxo máximo desse túnel é considerado o total dos pacotes que podem ser transmitidos em um dado período de tempo, ou seja de forma clara, o limite da banda.. então, múltiplas filas vão competir por esse túnel como um todo, mais ou menos:
fila[pesoX] + fila[pesoY] ...+ fila[peso N] <= tamanho do pipe
Compartilhando esse fluxo em partes (fatias) iguais, o peso para cada fila indica quanto desse fluxo (quantas fatias) aquela fila tem o direito de usufruir. Pesos variam de 1 a 100. O dummynet cuida dos momentos de inicio e término dos fluxos, logo, se existe um fluxo com dado peso, mas sua demanda é menor do que aquilo, ou nulo, o fluxo que sobra é dividido. Sem nunca esquecer que mais pacotes podem entrar por este FIFO. Os pesos são distribuidos em fatias iguais, por exemplo, se uma dada fila tem por exemplo peso 1, e outra fila tem peso 2, a segunda fila será atendida duas vezes mais do que a primeira. Pensando nisso como pacotes em fila, compartilhando o mesmo túnel de escape, pode considerar assim, “um pacote” eu atendo você, “um, dois pacotes” eu atendo você. Veja que esse número de pacotes vão ser o necessário para se atingir as “fatias” do link. Sabemos que existem tamanhos máximos de pacotes, mas nem todos tem necessáriamente esse tamanho. Logo, se para distribuir “uma fatia pra você”, “uma, duas fatias pra você” o algorítimo tiver que atender mais pacotes na primeira (pacotes menores), ele o fará. A proporção é 0(log de N), e a formula para definir o tamanho das fatias é definido na abordagem do algorítimo, mas é racional e seguro que são “partes iguais”.
Vamos melhorar a abordagem. Então, se tiver 3 túneis, digamos, com peso 2, 4 e 5, será atentido “uma duas fatias iguais da banda total, para você”, e “uma, duas, três, quatro fatias iguais da banda total para você”, e por fim “uma duas tres quatro cinco fatias iguais da banda total para você” sendo então fila1[peso 2]+fila2[peso 4]+fila3[peso 5] = limite da banda (tamano do pipe).
Se você tem então duas filas compartilhando o túnel, é fácil calcular quanto tem de banda máxima disponível para cada, em caso de link (do pipe) saturado. Se você tem centenas de filas, mas com o mesmo peso, também continua sendo fácil saber quanto cada poderá consumir. Contudo, se você tem mais de duas com pesos distintos, ai você tem que fazer o inverso do mínimo multiplo denominador comum, ou seja aquela série de contas que a gente aprende na quinta série e acha que nunca vai usar pra nada.
Por exemplo, fila1, 2, 3, 4... N compartilhando o mesmo link = N,Y,Z,X/L
X Y Z N
--------------
LLogo, não vamos poder assumir o peso como prioridade. Imagine, em outra situacao, que A tem peso 1 e B tem peso 100. Se fosse prioridades, enquanto B necessitasse de banda, B teria preferência (prioridade) absoluta sobre o link; sendo B mais prioritário, A nunca seria atendido porque B sempre ocuparia todo o link. Mas não é prioridade, é peso, e mesmo sendo dois extremos, com certeza A sempre terá sua fatia de link atendida, ainda que seja 1/100 partes. É mesmo “peso”, como se você fosse colocar em uma balança N quilos, sendo 1 parte desse N para cada 100 partes do mesmo N.
Na página de manual do IPFW (DUMMYNET) não fala nada a esse respeito, nem na página do Luigi, porque é apenas a implementação de um algorítimo já conhecido. Fica à nosso cargo estudar “do que se trata isso que o dummynet implementa”. O carinha (dummynet) é muito mais poderoso do que parece.
Tem um PDF (WFQ_WF2Q+.pdf) sobre as definições do W(F^2)Q+ pelo próprio autor da política, posso te passar em pvt (posso mandar na lista se os outros moderadores concentirem, tem +/- 300k). Não tenho idéia da onde eu peguei o documento, senão poderia colar a URL.
-- Atenciosamente,
Patrick Tracanelli
FreeBSD Brasil LTDA. http://www.freebsdbrasil.com.br patrick @ freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"
_______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
