Compreendendo a Weighted Fair Queuing em ATM

Opções de download

PDF (225.9 KB)
Ver no Adobe Reader em vários dispositivos
ePub (99.4 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (106.1 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:5 de outubro de 2006

ID do documento:10049

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Este documento fornece uma introdução ao enfileiramento de tráfego que usa a tecnologia WFQ (Weighted Fair Queuing).

O WFQ foi introduzido para permitir enlaces de velocidade lenta, como enlaces seriais, para proporcionar um tratamento justo para todos os tipos de tráfego. Para fazer isso, o WFQ classifica o tráfego em diferentes fluxos (também conhecidos como conversas) com base nas informações das camadas três e quatro, como endereços IP e portas TCP. Ele faz isso sem a exigência de você para definir listas de acesso. Isso significa que o tráfego de baixa largura de banda tem efetivamente prioridade sobre o tráfego de alta largura de banda porque o tráfego de alta largura de banda compartilha a mídia de transmissão proporcionalmente ao peso atribuído.

Mas o WFQ tem certas limitações:

Não é escalável se a quantidade de fluxo aumentar consideravelmente.
O WFQ nativo não está disponível em interfaces de alta velocidade como as interfaces ATM.

O CBWFQ (Enfileiramento moderado ponderado baseado em classe) fornece uma solução para essas limitações.

A contrário do WFQ padrão, o CBWFQ permite definir classes de tráfego. Você também pode aplicar parâmetros, como largura de banda e limites de fila, a eles. A largura de banda atribuída a uma classe é usada para calcular o peso dessa classe. O peso de cada pacote que atende aos critérios de classe também é calculado a partir disso. O WFQ é então aplicado às classes, que podem incluir vários fluxos, em vez dos próprios fluxos.

Consulte estes documentos para obter mais informações sobre como configurar o CBWFQ:

As interfaces ATM não suportam WFQ baseado em fluxo nativo configurado diretamente em uma interface com o comando fair-queue. Mas, com o software que suporta CBWFQ, você pode configurar o WFQ baseado em fluxo dentro da classe padrão, como mostrado neste exemplo:

policy-map test
 class class-default
  fair-queue
!         
interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 pvc A/B 
  service-policy output test

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Diagrama de Rede

Use esta configuração para ilustrar como o WFQ funciona:

Nessa configuração, os pacotes podem ser armazenados em uma destas duas filas:

A fila de hardware first in first out (FIFO) no adaptador de porta e no módulo de rede
A fila no ^software Cisco IOS^®, na memória de entrada/saída [E/S] do roteador, onde os recursos de Qualidade de Serviço (QoS), como CBWFQ, podem ser aplicados

A fila de FIFO no adaptador de porta armazena os pacotes que eles sejam segmentados em células para transmissão. Quando a fila está cheia, o adaptador de porta ou o módulo de rede sinaliza para o software IOS que a fila está congestionada. Esse mecanismo é chamado de contrapressão. Ao receber esse sinal, o roteador para de enviar pacotes para a fila FIFO da interface e armazena os pacotes no software IOS até que a fila fique descongestionada novamente. Quando os pacotes são armazenados no IOS, o sistema pode aplicar a QoS.

Como definir o limite de toque de transmissão

Um problema com esse mecanismo de enfileiramento é que, quanto maior a fila de FIFO na interface, maior o atraso antes que os pacotes do final dessa fila possam ser transmitidos. Isso pode causar problemas sérios de desempenho no tráfego sensível a retardos, como tráfego de voz.

O comando tx-ring-limit do Circuito Virtual Permanente (PVC) possibilita reduzir o tamanho da fila de FIFO.

interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 PVC A/B 
  tx-ring-limit  
       

  service-policy output test

O <tamanho> que você pode especificar aqui é um número de pacotes, para os roteadores Cisco 2600 e 3600, ou uma quantidade de partículas, para os roteadores Cisco 7200 e 7500.

A redução do tamanho do anel de transmissão tem dois benefícios:

Reduz a quantidade de tempo que os pacotes aguardam na fila FIFO antes de serem segmentados.
Acelera o uso do QoS no software IOS.

Impacto da transmissão de limite de anel

Examine o impacto do limite do anel de transmissão que usa a configuração mostrada no diagrama de rede anterior. Considere estes:

O gerador de tráfego envia tráfego (pacotes de 1.500 bytes) para o dispositivo de coleta e esse tráfego sobrecarrega o PVC 0/102 entre o roteador 1 e o roteador 2.
O Roteador 3 tenta o ping para o Roteador 1.
O WFQ está habilitado no roteador 2.

Examine duas configurações que usam diferentes limites do anel de transmissão para ver o impacto que isso tem.

Exemplo A

Neste exemplo, você define o anel de transmissão como três (tx-ring-limit=3). Isso é o que você vê ao fazer ping no roteador 1 a partir do roteador 3:

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 100000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms   

router2#show queue atm 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1  
   
!--- ping 
   

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 
   
!--- This is traffic from the traffic generator.

Exemplo B

Neste exemplo, você define o anel de transmissão como 40 (tx-ring-limit=40). Isso é o que você vê quando usa o mesmo ping do Exemplo A:

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 10000
Datagram size [100]: 36
Timeout in seconds [2]: 10
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
!!!!!!!!!!!!.
Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488 ms

Como você pode observar aqui, quanto maior o limite do anel de transmissão, maior será o tempo de RTT (ping round trip). Você pode deduzir disso que um grande limite de anel de transmissão pode levar a atrasos significativos na transmissão.

Como calcular o peso

Na saída show queue atm no Exemplo A, você vê que um peso é atribuído a cada conversação. Veja isso com mais detalhes:

router2#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1    

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Ao usar o WFQ, você pode calcular o peso de cada conversação com o uso desta fórmula:

weight=32384/(precedence+1) - para o Cisco IOS Software Release 12.0(5)T e posterior.
weight=4096/(precedence+1) - para Cisco IOS Software Releases anteriores a 12.0(5)T.

Como calcular o tempo de agendamento

Agora você pode usar esses pesos para calcular o tempo de agendamento de cada pacote, quando o pacote é encaminhado da fila do IOS para o adaptador de porta ou a fila FIFO do módulo de rede.

Você pode calcular o tempo de programação de saída com o uso desta fórmula, em que queue_tail_time é o tempo de programação atual:

output scheduling time= queue_tail_time + pktsize*weight

Como funciona o WFQ

Esta seção explica como o WFQ funciona. O princípio do WFQ é que os pacotes com um peso pequeno, ou pacotes pequenos, devem ter prioridade quando são enviados.

Crie um fluxo que inclua dez pacotes grandes e quatro pacotes menores (de 82 bytes) que usem um gerador de tráfego para verificar isso.

Neste exemplo, o roteador 2 é um roteador Cisco 7200 com um PA-A3 (adaptador de porta ATM). Isso é importante porque o tamanho da fila FIFO de saída no adaptador de porta é expresso em partículas e não em pacotes. Consulte o que é uma partícula? para obter mais informações.

O que é uma partícula?

Em vez da alocação de uma parte da memória contígua para um buffer, o buffer de partículas aloca pedaços de memória não contíguos (dispersos), chamados de partículas, e os une para formar um buffer de pacote lógico. Isso é chamado de um buffer de partícula. Em tal esquema, um pacote pode então se espalhar em várias partículas.

No roteador 7200, o tamanho da partícula é de 512 bytes.

Use o comando show buffers para verificar se os roteadores Cisco 7200 usam partículas:

router#show buffers
[snip]
Private particle pools: 
FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
  0 in free list (0 min, 400 max allowed)
  400 hits, 0 fallbacks
  400 max cache size, 271 in cache
ATM2/0 buffers, 512 bytes (total 400, permanent 400): 
  0 in free list (0 min, 400 max allowed)
  400 hits, 0 fallbacks
  400 max cache size, 0 in cache

Teste A

Estes são alguns testes para ilustrar a funcionalidade WFQ. Neste primeiro teste, verifique se a largura de banda pode ser compartilhada entre diferentes conversações.

Neste teste, você fez com que o gerador de tráfego enviasse o tráfego com rapidez suficiente para sobrecarregar o PVC 0/102 entre o roteador 1 e o roteador 2. Execute um ping do roteador 3 para o roteador 1 através do mesmo PVC:

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 100000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
......... (WFQ is enabled here)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.[break]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

Como você pode ver na saída mostrada, até que o WFQ seja ativado na interface, o tráfego impede que outro tráfego passe e a linha chegue à frente. Assim que o WFQ for habilitado, o ping será bem-sucedido.

Você pode ver a partir disso que, com o uso do WFQ, a largura de banda pode ser compartilhada entre diferentes conversas sem que uma bloqueie as outras.

Teste B

É assim que a largura de banda é compartilhada.

O fluxo que o gerador de tráfego envia é um burst composto de dez pacotes grandes, seguido por quatro pacotes menores de 82 bytes. Você envia isso a 100 Mbps para o roteador 2. Quando você envia a intermitência, a fila de saída na interface ATM do roteador 2 está vazia. O Roteador 2 envia esses pacotes através de um PVC de 10 KB (este é um PVC muito lento) para garantir que o congestionamento ocorra na fila de saída.

Faça este teste em várias etapas para simplificar este processo:

Estágio 1

O grande tráfego compreende dez pacotes de 482 bytes. Como as partículas em PA-A3 são de 512 bytes, cada pacote, seja grande ou pequeno, deve pegar uma partícula quando for armazenado na fila de saída do adaptador da porta. O roteador possui um limite de anel de transmissão de três (limite de anel de TX=3). Este é um exemplo do que você pode ver no dispositivo de dissipação:

   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 482, rcvd 4 
   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

   
!--- Congestion occurs at this point. 


   .Nov  7 15:39:15.512: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.516: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.816: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

Você pode ver os quatro pacotes de 482 bytes enviados antes dos pacotes de 82 bytes, que normalmente devem ter a prioridade. É por isso que isto acontece.

Como a intermitência é composta principalmente por 10 pacotes de 482 bytes, eles atingem o primeiro roteador, seguido pelo pacote de 82 bytes. Como os pacotes de 482 bytes chegam a um momento em que não há congestionamento, como não há tráfego, um pacote é imediatamente enfileirado para que o SAR (Port Adaptor Segmentation and Reassembly, segmentação e remontagem do adaptador de porta) seja dividido em células e enviado no fio. Em outras palavras, o anel de transmissão ainda está vazio.

Você pode calcular que o tempo necessário para enviar um pacote de 482 bytes é maior que o tempo necessário para o gerador de tráfego para enviar a intermitência total. Portanto, você pode supor que, quando o primeiro pacote de 482 bytes é enfileirado no adaptador de porta, mais pacotes de 482 bytes da intermitência já estão presentes no roteador. Portanto, mais pacotes de 482 bytes podem ser colocados em fila para o anel de transmissão. Mais três pacotes de 482 bytes são enfileirados com o uso das três partículas livres presentes ali.

Observação: os pacotes são enfileirados no anel de transmissão assim que há uma partícula livre, mesmo que precisem armazenar mais de uma partícula.

Nesse ponto há congestionamento, já que as três partículas estão cheias. Portanto, o enfileiramento se inicia no IOS. Quando os quatro pacotes de 82 bytes finalmente chegam ao roteador, há congestionamento. Esses quatro pacotes são enfileirados e o WFQ é utilizado nos dois fluxos. Examine a fila ATM que usa o comando show queue ATM para ver isso:

router2#show queue ATM 4/0.102 vc 0/102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 10/512/64/0 (size/max total/threshold/drops) 
     Conversations  2/4/16 (active/max active/max total)    
     Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/total drops/no-buffer drops/interleaves) 4/32384/0/0/0    
   Conversation 6, linktype: ip, length: 82 
   source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255    

(depth/weight/total drops/no-buffer drops/interleaves) 6/32384/0/0/0    
   Conversation 15, linktype: ip, length: 482 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Você pode ver nas depurações que os quatro primeiros pacotes de 482 bytes são seguidos pelos pacotes de 82 bytes. Esses pequenos pacotes saem do roteador antes dos pacotes grandes. Isso indica que, assim que ocorrer um congestionamento, pacotes pequenos terão prioridade sobre pacotes grandes.

Use as fórmulas de peso e tempo de programação fornecidas na seção Cálculo do peso para verificar isso.

Estágio 2

Se você aumentar o limite do anel de transmissão para cinco e os pacotes grandes forem de 482 bytes então, de acordo com a saída anterior, você verá seis pacotes de 482 bytes antes de ocorrer congestionamento, seguidos por quatro pacotes de 82 bytes, e então outros quatro pacotes de 482 bytes:

   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:57.841: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.845: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.797: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.801: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.840: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:00.844: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.796: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.800: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

Como podem ver aqui, isto é realmente o que acontece.

Estágio 3

O tamanho da partícula é de 512 bytes. Portanto, se o anel de transmissão for expresso em partículas, e você usar pacotes um pouco maiores que o tamanho da partícula, cada um toma duas partículas. Isso é ilustrado pelo uso de pacotes de 582 bytes e um anel de transmissão de três. Com esses parâmetros, você deve ver três pacotes de 582 bytes. Um é enviado sem tráfego na interface ATM, que deixa três partículas livres. Portanto, mais dois pacotes podem ser enfileirados, seguidos por quarto pacotes de 82 bytes e, em seguida, por sete pacotes de 528 bytes.

   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.388: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

Estágio 4

Pegue um tamanho de pacote de 1482 (três partículas) e defina um anel de transmissão de cinco. Se o anel de transmissão estiver definido em partículas, você verá algo semelhante:

Um pacote transmitido imediatamente
Um pacote que toma três das cinco partículas
Um pacote enfileirado porque duas partículas estão livres

   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:47.371: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:47.375: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:48.763: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:48.767: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:54.415: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:54.419: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

Summary

A partir dos testes realizados, você pode concluir estes:

Em PVCs lentos sem WFQ, o tráfego em massa afeta o pequeno tráfego, como os pings que estão sendo instalados até que o WFQ esteja ativado.
O tamanho do anel de transmissão (tx-ring-limit) determina a rapidez com que o mecanismo de enfileiramento começa a realizar seu trabalho. Você pode ver o impacto disso com o aumento do RTT do ping quando o limite do anel de transmissão aumenta. Por isso, se o WFQ ou o LLQ precisarem ser implementados, é recomendável que você reduza o limite do anel de transmissão.
O WFQ que usa CBWFQ efetivamente prioriza os pequenos tráfegos em relação ao tráfego em massa.