Banda larga a cabo : Cable Modem Termination Systems (CMTS)

Configuração de modo do agendador de upstream para o uBR CMTS de Cisco

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento discute a configuração de modo de agendador de upstream para a série do Universal Broadband Router de Cisco (uBR) de Cable Modem Termination Systems (CMTS).

Este documento focaliza nos pessoais que trabalham com o projeto e a manutenção das redes de cabo de dados de alta velocidade que utilizam a latência e serviços upstream Jitter-sensíveis, por exemplo, Voz ou vídeo sobre o IP.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Sistemas do Data Over Cable Service Interface Specification (DOCSIS)

  • As séries Cisco uBR de CMTS

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • UBR CMTS de Cisco

  • Trens de versão de software 12.3(13a)BC e 12.3(17a)BC do ½ do ¿  de Cisco IOSïÂ

Nota: Para obter informações sobre das mudanças em umas liberações mais atrasadas do Cisco IOS Software, refira os Release Note apropriados disponíveis na site da Web Cisco.com.

Convenções

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

Informações de Apoio

Em uma rede do Data-over-Cable Service Interface Specifications (DOCSIS), o CMTS controla o sincronismo e a taxa de todas as transmissões fluxo acima que o Modems a cabo faz. Muitos tipos diferentes dos serviços com latência, tremor e requisitos de throughput diferentes são executado simultaneamente em uma rede de DOCSIS moderna rio acima. Consequentemente, você deve compreender como o CMTS decide quando um modem a cabo pode fazer transmissões fluxo acima em nome destes tipos de serviços diferentes.

Este White Paper inclui:

  • Visão geral de modos de programação de upstream no DOCSIS, incluindo o melhor esforço, o Unsolicited Grant Service (UG) e o serviço de polling do tempo real (RTP)

  • A operação e a configuração do planificador do em conformidade com DOCSIS para o uBR CMTS de Cisco

  • A operação e a configuração do planificador novo do low latency queueing para o uBR CMTS de Cisco

Programação ascendente no DOCSIS

Um em conformidade com DOCSIS CMTS pode fornecer modos de agendamento de upstream diferentes para correntes de pacote de informação diferentes ou aplicativos com o conceito de um fluxo de serviço. Um fluxo de serviço representa um fluxo ascendente ou a jusante dos dados, que um fluxo de serviço ID (SFID) identifica excepcionalmente. Cada fluxo de serviço pode ter seus próprios parâmetros do Qualidade de Serviço (QoS), por exemplo, throughput máximo, throughput mínimo garantido e prioridade. No caso dos fluxos de serviço fluxo acima, você pode igualmente especificar um modo da programação.

Você pode ter mais de um fluxo de serviço fluxo acima para que cada modem a cabo acomode tipos diferentes de aplicativos. Por exemplo, a Web e o email podem usar um fluxo de serviço, a Voz sobre IP (VoIP) pode usar outro, e jogos de Internet pode usar-se contudo um outro fluxo de serviço. A fim poder proporcionar um tipo de serviço apropriado para cada um destes aplicativos, as características destes fluxos de serviço devem ser diferentes.

O modem a cabo e o CMTS podem dirigir os tipos de tráfego corretos nos fluxos de serviço apropriados com o uso dos classificadores. Os classificadores são filtros especiais, como as listas de acesso, que combinam propriedades do pacote tais como o UDP e os números de porta de TCP para determinar o fluxo de serviço apropriado para que os pacotes viajem completamente.

Em figura 1 um modem a cabo tem três fluxos de serviço fluxo acima. O primeiro fluxo de serviço é reservado para o tráfego de voz. Este fluxo de serviço tem um baixo throughput máximo mas é configurado igualmente para fornecer uma garantia da latência baixa. O fluxo de serviço seguinte é para o tráfego do web geral e do email. Este fluxo de serviço tem um throughput elevado. O fluxo de serviço final é reservado para que o par espreite o tráfego (P2P). Este fluxo de serviço tem um throughput máximo mais restritivo a estrangular suporta a velocidade deste aplicativo.

Figura 1 – Um modem a cabo com três fluxos de serviço fluxo acima

/image/gif/paws/69704/upstrm_sch_config_01.gif

Os fluxos de serviço estão estabelecidos e ativados quando um modem a cabo vem primeiramente em linha. Provision os detalhes dos fluxos de serviço no arquivo de configuração DOCSIS que você se usa para configurar o modem a cabo. Provision pelo menos um fluxo de serviço para o tráfego ascendente, e um fluxo do outro serviço para o tráfego a jusante em um arquivo de configuração DOCSIS. Os primeiros fluxos de serviço do fluxo acima e fluxo abaixo que você especifica no arquivo de configuração DOCSIS são chamados os fluxos de serviço principais.

Os fluxos de serviço podem igualmente dinamicamente ser criados e ativado depois que um modem a cabo vem em linha. Esta encenação aplica-se geralmente a um fluxo de serviço, que corresponda aos dados que pertencem a uma chamada telefônica de VoIP. Tal fluxo de serviço está criado e ativado quando uma conversa telefônica começa. O fluxo de serviço então está desativado e suprimido quando o atendimento termina. Se o fluxo de serviço existe somente quando necessário, você pode salvar recursos da largura de banda fluxo acima e carga de CPU e memória do sistema.

O Modems a cabo não pode fazer transmissões fluxo acima a qualquer momento. Em lugar de, o Modems deve esperar instruções do CMTS antes que possa enviar dados, porque somente um modem a cabo pode transmitir dados em um canal upstream em um momento. Se não, as transmissões podem passar e corromper-se. As instruções para quando um modem a cabo puder fazer uma transmissão vir do CMTS sob a forma de uma mensagem do mapa de alocação de largura de banda. Cisco CMTS transmite uma mensagem do MAPA cada 2 milissegundos para dizer o Modems a cabo quando pode fazer uma transmissão do tipo. Cada mensagem do MAPA contém a informação que instruir o Modems exatamente quando fazer uma transmissão, quanto tempo a transmissão pode durar, e que tipo de dados pode transmitir. Assim, as transmissões de dados do modem a cabo não colidem um com o otro, e evitam o corrompimento de dados. Esta seção discute algumas das maneiras em que um CMTS pode determinar quando conceder uma permissão do modem a cabo fazer uma transmissão no ascendente.

O melhor esforço

A melhor programação do esforço é apropriada para aplicativos de Internet clássicos sem o requisito estrito na latência ou no tremor. Os exemplos destes tipos de aplicativos incluem o email, a navegação na web ou transferência de arquivo peer-to-peer. A melhor programação do esforço não é apropriada para os aplicativos que exigem a latência garantida ou tremem, por exemplo, Voz ou vídeo sobre o IP. Isto é porque nas condições congestionadas nenhuma tal garantia pode ser feita no melhor modo do esforço. Os sistemas do DOCSIS 1.0 permitem somente este tipo de programação.

Os fluxos de serviço de melhor esforço são geralmente fornecida no arquivo de configuração DOCSIS associado com um modem a cabo. Consequentemente, os fluxos de serviço de melhor esforço são geralmente ativos assim que o modem a cabo vier em linha. O fluxo de serviço fluxo acima preliminar, isso é o primeiro fluxo de serviço fluxo acima a ser fornecida no arquivo de configuração DOCSIS, deve ser um melhor fluxo de serviço do estilo do esforço.

Estão aqui os parâmetros os mais de uso geral que definem um fluxo de serviço de melhor esforço no modo DOCSIS 1.1/2.0:

  • Taxa de tráfego sustentado máxima (R)

    A taxa de tráfego sustentado máxima é a taxa máxima em que o tráfego pode se operar sobre este fluxo de serviço. Este valor é expressado dentro nos bit por segundo.

  • Intermitência máxima de tráfego (b)

    A intermitência máxima de tráfego refere o tamanho de intermitência nos bytes que se aplica ao limitador da taxa de token bucket que reforça limites do throughput de upstream. Se nenhum valor é especificado, o valor padrão de 3044 aplica-se, que é o tamanho de dois frames da Ethernet completos. Para grandes taxas de tráfego sustentado máxima, ajuste este valor para ser pelo menos a taxa de tráfego sustentado máxima dividida por 64.

  • Prioridade de tráfego

    Este parâmetro refere a prioridade do tráfego em um fluxo de serviço que varia de 0 (o mais baixo) a 7 (o mais alto). No ascendente todo o tráfego pendente para fluxos de serviço prioritários é programado para a transmissão antes do tráfego para fluxos de serviço de baixa prioridade.

  • Taxa reservada mínima

    Este parâmetro indica um throughput mínimo garantido nos bit por segundo para o fluxo de serviço, similares a uma taxa de informação comprometida (CIR). As taxas reservadas mínimas combinadas para todos os fluxos de serviço em um canal não devem exceder a largura de banda disponível nesse canal. Se não é impossível garantir as taxas reservadas mínimas prometidas.

  • Intermitência máxima concatenada

    A intermitência máxima concatenada é o tamanho nos bytes da transmissão a maior dos frames concatenados que um modem pode fazer em nome do fluxo de serviço. Enquanto este parâmetro implica, um modem pode transmitir frames múltiplos em uma explosão da transmissão. Se este valor não é especificado, os Cable Modem DOCSIS 1.0 e um Modems mais velho do DOCSIS 1.1 supõem que não há nenhum conjunto limitado explícito no tamanho da intermitência concatenada. O em conformidade com modems com mais revisões recentes do DOCSIS 1.1 ou umas especificações mais atrasadas usam um valor de 1522 bytes.

Quando um modem a cabo tem os dados a transmitir em nome de um fluxo de serviço de melhor esforço ascendente, o modem não pode simplesmente enviar os dados na rede de DOCSIS sem o atraso. O modem deve atravessar um processo onde o modem peça o tempo de transmissão fluxo acima exclusivo do CMTS. Este processo do pedido assegura-se de que os dados não colidam com as transmissões de um outro modem a cabo conectado ao mesmo canal upstream.

Às vezes o CMTS programa determinados períodos em que o CMTS permite que o Modems a cabo transmita os mensagens especiais chamados requisições de largura de banda. A requisição de largura de banda é um quadro muito pequeno que contenha detalhes da quantidade de dados que o modem quer transmitir, mais um identificador de serviço (SID) que corresponda ao fluxo de serviço fluxo acima que precisa de transmitir os dados. O CMTS mantém uma tabela interna que combina números de SID aos fluxos de serviço fluxo acima.

O CMTS programa oportunidades da requisição de largura de banda quando nenhum outro evento é programado no ascendente. Ou seja o planificador fornece oportunidades da requisição de largura de banda quando o agendador de upstream não planejou para uma melhor concessão do esforço, ou os UG concedem ou algum outro tipo de concessão a ser colocada em um ponto particular. Consequentemente, quando um canal upstream é utilizado pesadamente, menos oportunidades existem para que o Modems a cabo transmita requisições de largura de banda.

O CMTS assegura-se de sempre que um pequeno número de oportunidades da requisição de largura de banda estejam programadas regularmente, não importa como congestionado o canal upstream se torna. O Modems a cabo múltiplo pode transmitir requisições de largura de banda ao mesmo tempo, e corromper transmissões de cada um. A fim reduzir o potencial de colisões que pode corromper requisições de largura de banda, do “um algoritmo escritório e da nova tentativa” é no lugar. As seções subsequente deste documento discutem este algoritmo.

Quando o CMTS recebe uma requisição de largura de banda de um modem a cabo, o CMTS executa estas ações:

  1. O CMTS usa o número de SID recebido na requisição de largura de banda examinar o fluxo de serviço com que a requisição de largura de banda é associada.

  2. O CMTS usa então o algoritmo de token bucket. Este algoritmo ajuda o CMTS a verificar se o fluxo de serviço exceda a taxa mantida máxima prescrita se o CMTS concede a largura de banda pedida. Está aqui a computação do algoritmo de token bucket:

    Máximo (T) = T * (R/8) + B

    em que:

    • Máximo (T) indica o máximo número de bytes que pode ser transmitido no fluxo de serviço ao longo do tempo T.

    • T representa o tempo nos segundos.

    • R indica a taxa de tráfego sustentado máxima para o fluxo de serviço nos bit por segundo

    • B é a intermitência máxima de tráfego para o fluxo de serviço nos bytes.

  3. Quando o CMTS verifica que a requisição de largura de banda está dentro dos limites da taxa de transferência, o CMTS enfileira os detalhes da requisição de largura de banda ao agendador de upstream. O agendador de upstream decide quando conceder a requisição de largura de banda.

    O uBR CMTS de Cisco executa dois algoritmos de agendador de upstream, chamados o planificador do em conformidade com DOCSIS e o planificador do low latency queueing. Veja o planificador do em conformidade com DOCSIS secionar e a seção do planificador do low latency queueing deste documento para mais informação.

  4. O CMTS inclui então estes detalhes na mensagem periódica seguinte do mapa de alocação de largura de banda:

    • Quando o modem a cabo puder transmitir.

    • Durante quanto tempo o modem a cabo pode transmitir.

Escritório da requisição de largura de banda e algoritmo da nova tentativa

O mecanismo da requisição de largura de banda emprega do “um algoritmo simples escritório e da nova tentativa” para reduzir-se, mas para eliminar não totalmente, o potencial de colisões entre o Modems a cabo múltiplo que transmite requisições de largura de banda simultaneamente.

Um modem a cabo que decida transmitir uma requisição de largura de banda deve primeiramente esperar um número aleatório de oportunidades da requisição de largura de banda de passar antes que o modem faça a transmissão. Este tempo de espera ajuda a reduzir a possibilidade de colisões que ocorre devido às transmissões simultâneas das requisições de largura de banda.

Dois parâmetros chamaram o começo do escritório dos dados e a extremidade do escritório dos dados determina o período de espera aleatório. O Modems a cabo aprende estes parâmetros como parte dos índices da mensagem periódica do descritor de canal upstream (UCD). O CMTS transmite o mensagem de UCD em nome de cada canal upstream ativo cada dois segundos.

Estes parâmetros de recuo são expressados como uma “potência de dois” valores. O Modems usa estes parâmetros como potências de dois calcular quanto tempo esperar antes que transmita requisições de largura de banda. Ambos os valores têm uma escala de 0 a 15 e a extremidade do escritório dos dados deve ser superior ou igual a começo do escritório dos dados.

A primeira vez que um modem a cabo quer transmitir um pedido da largura de banda específica, o modem a cabo deve primeiramente escolher um número aleatório entre 0 e 2 à potência do começo do escritório dos dados menos 1. por exemplo, se o começo do escritório dos dados é ajustado a 3, o modem deve escolher um número aleatório entre 0 e (23 – 1) = (8 – 1) = 7.

O modem a cabo deve então esperar o número aleatório selecionado de oportunidades de transmissão da requisição de largura de banda passar antes que o modem transmita uma requisição de largura de banda. Assim, quando um modem não puder transmitir uma requisição de largura de banda na oportunidade disponível seguinte devido a este atraso forçado, a possibilidade de uma colisão com transmissão de um outro modem reduz-se.

Naturalmente mais alto o valor do começo do escritório dos dados, é mais baixo a possibilidade de colisões entre a requisição de largura de banda. Os valores maiores do começo do escritório dos dados igualmente significam que o Modems potencialmente tem que esperar mais por muito tempo para transmitir requisições de largura de banda, e aumentos tão ascendentes da latência.

O CMTS inclui um reconhecimento no mensagem MAP de alocação seguinte da largura de banda transmitida. Este reconhecimento informa o modem a cabo que a requisição de largura de banda esteve recebida com sucesso. Este reconhecimento pode:

  • qualquer um indica exatamente quando o modem pode fazer a transmissão

    OU

  • indique somente que a requisição de largura de banda esteve recebida e que um momento para a transmissão estará decidido em um mensagem MAP futuro.

Se o CMTS não inclui um reconhecimento da requisição de largura de banda na mensagem seguinte do MAPA, o modem pode concluir que a requisição de largura de banda não esteve recebida. Esta situação pode ocorrer devido a uma colisão, ou ao ruído ascendente, ou porque o fluxo de serviço excede a taxa prescrita do throughput máximo se o pedido é concedido.

Em qualquer dos casos, a próxima etapa para o modem a cabo é ao escritório, e tenta transmitir outra vez a requisição de largura de banda. O modem aumenta a escala sobre que um valor aleatório é escolhido. Para fazer assim, o modem adiciona um ao valor do começo do escritório dos dados. Por exemplo, se o valor do começo do escritório dos dados é 3, e o CMTS não recebe uma transmissão da requisição de largura de banda, o modem espera um valor aleatório entre 0 e 15 oportunidades da requisição de largura de banda antes da retransmissão. Está aqui o cálculo: 23+1 – 1 = 24 – 1 = 16 – 1 = 15

A escala maior dos valores reduz a possibilidade de uma outra colisão. Se o modem perde umas requisições de largura de banda mais adicionais, o modem continua a incrementar o valor usado como a potência de dois para cada retransmissão até que o valor esteja igual à extremidade do escritório dos dados. A potência de dois não deve vir seja maior do que o valor do fim do escritório dos dados.

O modem retransmite uma requisição de largura de banda até 16 vezes, depois do qual o modem rejeita a requisição de largura de banda. Esta situação ocorre somente extremamente em condições congestionadas.

Você pode configurar os valores do fim do escritório do começo e dos dados do escritório dos dados pelo cabo rio acima em um uBR CMTS de Cisco com este comando cable interface:

fim de recuo de dados ascendente do início de recuo de dados do DATA-escritório rio acima-porta-identificação do cabo

Cisco recomenda que você retém os valores padrão para os parâmetros do início de recuo de dados e do fim de recuo de dados, que são 3 e 5. A natureza disputa-baseada do melhor sistema de agendamento do esforço significa que para fluxos de serviço de melhor esforço, é impossível fornecer um nível determinística ou garantido da latência ou do tremor ascendente. Além, as condições congestionadas podem fazê-la impossível garantir um nível particular de throughput para um fluxo de serviço de melhor esforço. Contudo, você pode usar propriedades do fluxo de serviço como a prioridade e a taxa reservada mínima. Com estas propriedades, o fluxo de serviço pode conseguir o nível desejado da taxa de transferência nas condições congestionadas.

Exemplo do algoritmo do escritório e da nova tentativa

Este exemplo compreende quatro Modems a cabo nomeados A, B, C e D, conectados ao mesmo canal upstream. No mesmo instante chamado t0, o Modems A, B e o C decidem transmitir alguns dados no ascendente.

Aqui, o começo do escritório dos dados é ajustado a 2 e a extremidade do escritório dos dados é ajustada a 4. A escala dos intervalos de que o Modems escolhe um intervalo antes que tente primeiramente transmitir uma requisição de largura de banda está entre 0 e 3. Está aqui o cálculo:

(22 – 1) = (4 – 1) = 3 intervalos.

Está aqui o número de oportunidades da requisição de largura de banda que os três Modems escolhem para esperar do tempo t0.

  • Modem A: 3

  • Modem B: 2

  • C do modem: 3

Observe que o modem A e o C do modem escolhem o mesmo número de oportunidades de esperar.

O modem B espera duas oportunidades da requisição de largura de banda que aparecem depois que o modem B t0. a seguir transmite a requisição de largura de banda, que o CMTS recebe. O modem A e o C do modem esperam 3 oportunidades da requisição de largura de banda de passar após o Modems A t0. e o C a seguir transmitem requisições de largura de banda ao mesmo tempo. Estas duas requisições de largura de banda colidem e tornam-se corrompidas. Em consequência, nenhum pedido alcança com sucesso o CMTS. Figura 2 mostra esta sequência de evento.

Figura 2 – Parte de exemplo 1 da requisição de largura de banda

upstrm_sch_config_02.gif

A haste cinza na parte superior do diagrama representa uma série de oportunidades da requisição de largura de banda disponíveis ao Modems a cabo após o tempo t0. As setas coloridas representam as requisições de largura de banda que o Modems a cabo transmite. A caixa colorida dentro da haste cinza representa uma requisição de largura de banda que alcance o CMTS com sucesso.

A transmissão seguinte da mensagem do MAPA do CMTS contém uma concessão para o modem B mas as nenhumas instruções de modems A e o C. Isto indica ao Modems A e ao C que precisam de retransmitir suas requisições de largura de banda.

Na segunda tentativa, o modem A e o C do modem precisam de incrementar a potência de dois usar-se quando calcula a escala dos intervalos de que para escolher. Agora, o modem A e o C do modem escolhem um número aleatório de intervalos entre 0 e 7. Está aqui a computação:

(22+1 -1) = (23 – 1) = (8 – 1) = intervalos 7.

Supõe que o tempo quando o modem A e o C do modem realizarem a necessidade de retransmitir é T1. Igualmente supõe que um outro modem chamado o modem D decide transmitir alguns dados ascendentes no mesmo instante, T1. O modem D está a ponto de fazer pela primeira vez uma transmissão da requisição de largura de banda. Consequentemente, o modem D usa o valor original para o começo do escritório dos dados e a extremidade do escritório dos dados, a saber entre 0 e 3 [(22 – 1) = (4 – 1) = 3 intervalos].

Os três Modems escolhem este o número aleatório de oportunidades da requisição de largura de banda de esperar do T1 do tempo.

  • Modem A: 5

  • C do modem: 2

  • Modem D: 2

Espera do C e D do Modems para duas oportunidades da requisição de largura de banda que aparecem após o T1 do tempo. O C do Modems e D transmitem então requisições de largura de banda ao mesmo tempo. Estas requisições de largura de banda colidem e consequentemente não alcançam o CMTS. O modem A permite cinco oportunidades da requisição de largura de banda de passar. Então, o modem A transmite a requisição de largura de banda, que o CMTS recebe. Figura 3 mostra a colisão entre o C da transmissão de modems e o D, e o recebimento bem-sucedido da transmissão de modem A. A referência das horas inicial para esta figura é T1.

Figura 3 – Parte de exemplo 2 da requisição de largura de banda

upstrm_sch_config_03.gif

A transmissão seguinte da mensagem do MAPA do CMTS contém uma concessão para o modem A mas nenhuns C das instruções de modems e D. Modems C e D realizam a necessidade de retransmitir as requisições de largura de banda. O modem D é agora aproximadamente transmitir pela segunda vez a requisição de largura de banda. Consequentemente, começo do escritório dos dados dos usos do modem D + 1 como a potência de dois usar-se no cálculo da escala dos intervalos para esperar. O modem D escolhe um intervalo entre 0 e 7. Está aqui o cálculo:

(22+1 – 1) = (23 – 1) = (8 – 1) = intervalos 7.

O C do modem está a ponto de transmitir pela terceira vez a requisição de largura de banda. Consequentemente, começo do escritório dos dados dos usos do C do modem + 2 como a potência de dois no cálculo da escala dos intervalos esperar. O C do modem escolhe um intervalo entre 0 e 15. Está aqui o cálculo:

(22+2 – 1) = (24 – 1) = (16 – 1) = 15 intervalos.

Note que a potência de dois é aqui a mesma como o valor do fim do escritório dos dados, que é quatro. Este é o mais alto que a potência do valor dois pode ser para um modem neste canal upstream. No ciclo seguinte da transmissão da requisição de largura de banda, os dois Modems escolhem estes número de oportunidades da requisição de largura de banda de esperar:

  • C do modem: 9

  • Modem D: 4

O modem D pode transmitir a requisição de largura de banda porque o modem D espera quatro oportunidades da requisição de largura de banda de passar. Além, o C do modem pode igualmente transmitir a requisição de largura de banda, porque o C do modem adia agora a transmissão para nove oportunidades da requisição de largura de banda.

Infelizmente, quando o C do modem faz uma transmissão, uma grande explosão do ruído de ingresso interfere com a transmissão, e o CMTS não recebe a requisição de largura de banda (veja figura 4). Em consequência, mais uma vez, o C do modem não vê uma concessão na mensagem seguinte do MAPA que o CMTS transmite. Isto faz a tentativa do C do modem uma quarta transmissão da requisição de largura de banda.

Figura 4 – Parte 3 do exemplo da requisição de largura de banda

upstrm_sch_config_04.gif

O C do modem tem alcançado já o valor do fim do escritório dos dados de 4. C do modem não pode aumentar a escala usada para escolher um número aleatório de intervalos para esperar. Consequentemente, o C do modem usa mais uma vez 4 como a potência de dois calcular a escala aleatória. O C do modem ainda usa os intervalos da escala 0 a 15 conforme este cálculo:

(24 – 1) = (16 – 1) = 15 intervalos.

Na quarta tentativa, o C do modem pode fazer uma transmissão bem sucedida da requisição de largura de banda na ausência da disputa ou propalá-la.

O C múltiplo das retransmissões de modem da requisição de largura de banda neste exemplo demonstra o que pode acontecer em um canal upstream congestionado. Este exemplo igualmente demonstra os problemas potenciais envolvidos com o melhor modo de agendamento de empenho e porque a melhor programação do esforço não é apropriada para os serviços que exigem níveis restritamente controlados da latência de pacote e tremem.

Prioridade de tráfego

Quando o CMTS tem múltiplo durante requisições de largura de banda de diversos fluxos de serviço, o CMTS olha a prioridade de tráfego de cada fluxo de serviço para decidir qual conceder primeiramente a largura de banda.

O CMTS concede o tempo de transmissão a todos os pedidos pendentes dos fluxos de serviço com uma prioridade mais alta antes das requisições de largura de banda dos fluxos de serviço com uma baixa prioridade. Em circunstâncias ascendentes congestionadas, isto conduz geralmente ao throughput elevado para os fluxos de serviço prioritários comparados aos fluxos de serviço de baixa prioridade.

Um fato importante a notar é que quando um fluxo de serviço de melhor esforço prioritário for mais provável receber rapidamente a largura de banda, o fluxo de serviço é ainda sujeito à possibilidade de colisões da requisição de largura de banda. Por este motivo quando a prioridade de tráfego puder aumentar a taxa de transferência e as características de latência de um fluxo de serviço, a prioridade de tráfego não é ainda uma maneira apropriada de fornecer uma garantia do serviço para os aplicativos que exigem um.

Taxa reservada mínima

Os fluxos de serviço de melhor esforço podem receber uma taxa reservada mínima com que para seguir. O CMTS assegura-se de que um fluxo de serviço com uma taxa reservada mínima especificada receba a largura de banda de preferência a todos fluxos de serviço de melhor esforço restantes, apesar da prioridade.

Este método é uma tentativa de fornecer um tipo do serviço do estilo da taxa de informação comprometida (CIR) análogo a uma rede do Frame Relay. O CMTS tem os mecanismos de controle de admissão a assegurar-se de que isso em um detalhe rio acima a taxa reservada mínima combinada de todos os fluxos de serviço conectados não possa exceder a largura de banda disponível do canal upstream, ou uma porcentagem disso. Você pode ativar estes mecanismos com o este pelo comando da porta upstream:

max-reservation-limit ascendente do controle de admissão rio acima-porta-identificação do cabo do [no]

O parâmetro do max-reservation-limit tem uma escala do 10 a 1000 por cento para indicar o nível da assinatura em relação à taxa de transferência crua disponível do canal upstream que os serviços do estilo CIR podem consumir. Se você configura um max-reservation-limit de maior de 100, os serviços ascendentes do estilo do oversubscribe CIR da lata pelo limite de porcentagem especificado.

O CMTS não permite os fluxos de serviço novos da taxa reservada mínima sejam estabelecidos se fariam com que a porta upstream excedesse a porcentagem configurada do max-reservation-limit da largura de banda de canal de fluxo acima disponível. Os fluxos de serviço da taxa reservada mínima são ainda sujeitos aos colisões potenciais das requisições de largura de banda. Como tal, os fluxos de serviço da taxa reservada mínima não podem fornecer uma garantia verdadeira de um throughput particular, especialmente extremamente em condições congestionadas. Ou seja o CMTS pode somente garantir que um fluxo de serviço da taxa reservada mínima pode conseguir um throughput de upstream garantido detalhe se o CMTS pode receber todos os pedidos da largura de banda requerida do modem a cabo. Esta exigência pode ser conseguida se você faz ao fluxo de serviço um fluxo de serviço do serviço de polling do tempo real (RTP) em vez de um fluxo de serviço de melhor esforço. Veja a seção do serviço de polling do tempo real (RTP) para mais informação.

Requisições de largura de banda do reboque

Quando um fluxo de serviço de melhor esforço ascendente transmite quadros em uma taxa alta, é possível às requisições de largura de banda do reboque em frames de dados ascendentes um pouco do que tem a transmissão separada das requisições de largura de banda. Os detalhes do pedido seguinte para a largura de banda são adicionados simplesmente ao encabeçamento de um pacote de dados que está sendo transmitido no ascendente ao CMTS.

Isto significa que a requisição de largura de banda não é sujeita à disputa e tem consequentemente uma possibilidade muito mais alta que o pedido alcança o CMTS. O conceito de requisições de largura de banda do reboque reduz o tempo que um frame da Ethernet toma para alcançar o equipamento da premissa do cliente (CPE) do utilizador final, porque o tempo que o quadro recolhe a transmissão fluxo acima se reduz. Isto é porque o modem não precisa de atravessar o escritório e de experimentar de novo o processo da transmissão da requisição de largura de banda, que pode ser sujeito aos atrasos.

O reboque das requisições de largura de banda ocorre tipicamente nesta encenação:

Quando o modem a cabo esperar para transmitir um quadro, diga X, no ascendente, o modem recebe um outro quadro, dizem Y, de um CPE transmitir no ascendente. O modem a cabo não pode adicionar os bytes do quadro novo Y sobre à transmissão, porque aquele envolve o uso de um tempo mais ascendente do que o modem é concedido. Em lugar de, o modem preenche um campo no cabeçalho de DOCSIS do quadro X para indicar a quantidade de tempo de transmissão exigida para o quadro Y.

O CMTS recebe o quadro X e igualmente os detalhes de uma requisição de largura de banda em nome do Y. com base na Disponibilidade, o CMTS concedem ao modem um tempo de transmissão mais adicional em nome do Y.

Nos termos muito conservadores, tão curtos como os milissegundos 5 decorrem entre a transmissão de uma requisição de largura de banda e o recibo da alocação de largura de banda assim como TRAÇAM o reconhecimento que atribui a hora para a transmissão de dados. Isto significa aquele rebocando ocorra, o modem a cabo precisa de receber quadros do CPE dentro de menos do que 5ms de se.

Isto é notável porque, um codec típico de VoIP como G.711 usa geralmente um período do inter-quadro de 10 ou de 20ms. Um córrego típico de VoIP que se opere sobre um fluxo de serviço de melhor esforço não pode aproveitar-se do reboque.

Concatenação

Quando um fluxo de serviço de melhor esforço ascendente transmite quadros em uma taxa alta, o modem a cabo pode juntar-se a alguns dos quadros junto e pedi-los a permissão transmitir de uma vez os quadros. Isto é chamado concatenação. O modem a cabo precisa de transmitir somente uma requisição de largura de banda em nome de todos os quadros em um grupo de frames concatenados, que melhore a eficiência.

A concatenação tende a ocorrer nas circunstâncias similares ao reboque salvo que a concatenação exige frames múltiplos ser enfileirada dentro do modem a cabo quando o modem decide transmitir uma requisição de largura de banda. Isto implica que a concatenação tende a ocorrer em umas taxas de frame médio mais altas do que rebocando. Também, ambos os mecanismos trabalham geralmente junto para melhorar a eficiência do tráfego de melhor esforço.

O campo da intermitência máxima concatenada que você pode configurar para um fluxo de serviço limita o tamanho máximo de um frame concatenado que um fluxo de serviço possa transmitir. Você pode igualmente usar o comando cable default-phy-burst limitar o tamanho de um frame concatenado e do tamanho de intermitência máxima no perfil de modulação do canal upstream.

A concatenação é permitida à revelia nas portas upstream das séries Cisco uBR de CMTS. Contudo, você pode controlar a concatenação em uma base da por-rio acima-porta com o comando cable interface ascendente da concatenação rio acima-porta-identificação [docsis10] do cabo do [no].

Se você configura o parâmetro docsis10, o comando aplica-se somente ao Modems a cabo que se opera no modo do DOCSIS 1.0.

Se você faz mudanças a este comando, o Modems a cabo deve registrar novamente no CMTS para que as mudanças tomem o efeito. O Modems no ascendente afetado deve ser restaurado. Um modem a cabo aprende se a concatenação está permitida no ponto onde o modem executa o registro como parte do processo de vinda em linha.

Fragmentação

Os grandes quadros tomam um muito tempo transmitir no ascendente. Este tempo de transmissão é sabido como o retardo de serialização. Os quadros ascendentes especialmente grandes podem tomar tão por muito tempo para transmitir que podem prejudicial atrasar os pacotes que pertencem aos serviços sensíveis ao tempo, por exemplo, VoIP. Isto é especialmente verdadeiro para grandes frames concatenados. Por este motivo, a fragmentação foi introduzida no DOCSIS 1.1 de modo que os grandes quadros pudessem ser rachados em quadros menores para a transmissão em explosões separadas essa cada tomada menos hora de transmitir.

A fragmentação permite os quadros pequenos, sensíveis ao tempo a ser intercalados entre os fragmentos de grandes quadros um pouco do que tendo que esperar a transmissão do grande quadro inteiro. A transmissão de um quadro como fragmentos múltiplos é levemente menos eficiente do que a transmissão de um quadro em um estourado devido ao grupo extra de cabeçalhos de DOCSIS que precisam de acompanhar cada fragmento. Contudo, a flexibilidade que a fragmentação adiciona ao canal upstream justifica as despesas gerais extra.

O Modems a cabo que se opera no modo do DOCSIS 1.0 não pode executar a fragmentação.

A fragmentação é permitida à revelia nas portas upstream das séries Cisco uBR de CMTS. Contudo, você pode permitir ou desabilitar a fragmentação em uma base da por-rio acima-porta com o comando cable interface ascendente da fragmentação rio acima-porta-identificação do cabo do [no].

Você não precisa de restaurar o Modems a cabo para que o comando tome o efeito. Cisco recomenda que você tem sempre a fragmentação permitida. A fragmentação ocorrer normalmente quando as crenças CMTS que um grande frame de dados pode interferir com a transmissão de quadros sensíveis ao tempo pequenos ou de determinados eventos periódicos do Gerenciamento DOCSIS.

Você pode forçar o Modems a cabo DOCSIS 1.1/2.0 para fragmentar todos os grandes quadros com o comando cable interface ascendente do [threshold number-of-fragments] do fragment-force rio acima-porta-identificação do cabo do [no].

À revelia, esta característica é desabilitada. Se você não especifica valores para o ponto inicial e o número de fragmentos na configuração, o ponto inicial está ajustado a 2000 bytes e o número de fragmentos é ajustado a 3. O comando do fragment-force compara o número de bytes que um fluxo de serviço pede para a transmissão com o parâmetro do limiar especificado. Se o tamanho do pedido é maior do que o ponto inicial, o CMTS concede a largura de banda ao fluxo de serviço nas peças ingualmente feitas sob medida do “número de fragmentos”.

Por exemplo, supõe que isso para um fragment-force ascendente do detalhe está permitido com um valor de 2000 bytes de limiar e os 3 para o número de fragmentos. Supõe então que um pedido transmitir uma explosão de 3000 bytes chega. Porque 3000 bytes são maiores do que o ponto inicial de 2000 bytes, a concessão deve ser fragmentada. Porque o número de fragmentos é ajustado a 3, o tempo de transmissão é três concessões ingualmente feitas sob medida de 1000 bytes cada um.

Ciao para assegurar-se de que os tamanhos de fragmentos individuais não excedam a capacidade da placa de linha de cabo datilografem dentro o uso. Para placas de linha do MC5x20S, o fragmento individual o maior não deve exceder 2000 bytes, e para outras placas de linha, incluindo o MC28U, o MC5x20U e o MC5x20H, o fragmento individual o maior não deve exceder 4000 bytes.

Unsolicited Grant Service (UG)

O Unsolicited Grant Service (UG) fornece concessões periódicas para um fluxo de serviço fluxo acima sem a necessidade para que um modem a cabo transmita requisições de largura de banda. Este tipo de serviço é apropriado para os aplicativos que gerenciem quadros do tamanho fixo em intervalos regulares e é intolerante da perda de pacotes. A Voz sobre o IP é o exemplo clássico.

Compare o sistema de agendamento UG a um timeslot em um sistema da multiplexação de divisão de tempo (TDM) tal como um circuito do T1 ou E1. Os UG fornecem uma taxa de transferência e uma latência garantidas, que forneça por sua vez o fluxo contínuo de intervalos periódicos fixos para transmitir sem a necessidade para que o cliente peça ou afirme periodicamente para a largura de banda. Este sistema é perfeito para VoIP porque o tráfego de voz é transmitido geralmente como um fluxo contínuo de dados periódicos do tamanho fixo.

Os UG foram concebidos devido à falta das garantias para a latência, o tremor e a taxa de transferência no melhor modo de agendamento de empenho. O melhor modo de agendamento de empenho não oferece a garantia que um quadro particular pode ser transmitido em uma estadia particular, e em um sistema congestionado não há nenhum acreditação que um quadro particular pode ser transmitido de todo.

Note que embora os fluxos de serviço do estilo UG sejam o fluxo o mais apropriado do tipo de serviço para transportar o tráfego de portador de VoIP, não estão considerados ser apropriados para aplicativos de Internet clássicos tais como a Web, o email ou o P2P. Isto é porque os aplicativos de Internet clássicos não gerenciem dados em intervalos periódicos fixos e podem, de fato, passar os períodos significativos que não transmitem dados de todo. Se um fluxo de serviço UG é usado para transportar o tráfego do Internet clássico, o fluxo de serviço pode ir não utilizado pelos períodos significativos em que o aplicativo para momentaneamente transmissões. Isto conduz aos UG não utilizados as concessões que representam um desperdício de recursos da largura de banda fluxo acima que não seja desejável.

Os fluxos de serviço UG estão estabelecidos geralmente dinamicamente quando são exigidos um pouco do que sendo fornecida no arquivo de configuração DOCSIS. Um modem a cabo com portas integradas de VoIP pode geralmente pedir o CMTS para criar um fluxo de serviço apropriado UG quando o modem detecta que uma chamada telefônica de VoIP é em andamento.

Cisco recomenda que você não configura um fluxo de serviço UG em um arquivo de configuração DOCSIS porque esta configuração mantém o fluxo de serviço UG ativo para enquanto o modem a cabo é em linha mesmo se todos os serviços o usam. Esta configuração desperdiça a largura de banda fluxo acima porque um fluxo de serviço UG reserva constantemente o tempo de transmissão fluxo acima em nome do modem a cabo. É distante melhor permitir que o fluxo de serviço UG seja criado e suprimido dinamicamente de modo que os UG sejam ativos se necessário.

Estão aqui os parâmetros os mais de uso geral que definem um fluxo de serviço UG:

  • Tamanho de concessão não solicitado (g) — O tamanho de cada concessão periódica nos bytes.

  • Intervalo de concessão nominal (i) — O intervalo nos microssegundos entre concessões.

  • Tremulação de concessão tolerada (J) — A variação permitida nos microssegundos das concessões exatamente periódicas. Ou seja esta é a deriva que o CMTS tem quando o CMTS tenta programar uma concessão UG no tempo.

Quando um fluxo de serviço UG é ativo, cada (i) milissegundos, o CMTS oferece uma possibilidade para que o fluxo de serviço transmita em bytes do tamanho de concessão não solicitado (g). Embora idealmente o CMTS ofereça à concessão exatamente cada (i) milissegundos, pode estar atrasado por até (J) milissegundos.

A figura 5 mostra um período que demonstre como as concessões UG podem ser atribuídas com um tamanho concedido dado, um intervalo da concessão e um tremor tolerado.

Figura 5 – O período que mostra UG periódicos concede

/image/gif/paws/69704/upstrm_sch_config_05.gif

Os blocos modelados verde representam o tempo onde o CMTS dedica o tempo de transmissão fluxo acima a um fluxo de serviço UG.

Serviço de polling do tempo real (RTP)

O serviço de polling do tempo real (RTP) fornece oportunidades NON-disputa-baseadas periódicas da requisição de largura de banda de modo que um fluxo de serviço dedique a hora de transmitir requisições de largura de banda. Somente o fluxo de serviço RTP é permitido usar esta oportunidade da requisição de largura de banda do unicast. O outro Modems a cabo não pode causar uma colisão da requisição de largura de banda.

Os RTP são apropriados para os aplicativos que gerenciem quadros do comprimento variável em uma base semi-periódica e exigem uma taxa de transferência mínima garantida trabalhar eficazmente. A telefonia de vídeo sobre o IP ou os multi jogos de videogame on-line são exemplos típicos.

Os RTP são usados igualmente para o tráfego de sinalização voip. Quando o tráfego de sinalização voip não precisar de ser transmitido extremamente com - a latência baixa ou o tremor, VoIP precisam de ter uma semelhança alta de poder alcançar o CMTS em uma quantidade razoável de tempo. Se você usa RTP um pouco do que melhor o esforço que programa você pode ser assegurado que a sinalização de voz não está atrasada significativamente ou deixado cair devido às colisões repetidas da requisição de largura de banda.

Um fluxo de serviço RTP possui tipicamente estes atributos:

  • Intervalo de polling nominal — O intervalo nos microssegundos entre oportunidades da requisição de largura de banda do unicast.

  • Retardo de sincronismo de eleição tolerado — A variação permitida nos microssegundos das votações exatamente periódicas. Põe uma outra maneira, isto é a deriva que o CMTS tem ao tentar programar uma oportunidade da requisição de largura de banda do unicast RTPS no tempo.

Figure que 6 mostra um período que demonstre como as votações RTP são atribuídas com um intervalo de polling nominal e um retardo de sincronismo de eleição tolerado dados.

Figura 6 – Período que mostra a vatação periódica RTP

/image/gif/paws/69704/upstrm_sch_config_06.gif

Verde pequeno os blocos modelados representam o tempo onde o CMTS oferece a um fluxo de serviço RTP uma oportunidade da requisição de largura de banda do unicast.

Quando o CMTS recebe uma requisição de largura de banda em nome de um fluxo de serviço RTP, o CMTS processa a requisição de largura de banda da mesma forma como um pedido " best effort " de um fluxo de serviço. Isto significa que além do que os parâmetros acima, propriedades como a taxa de tráfego sustentado máxima e a prioridade de tráfego devem ser incluídas em uma definição de fluxo de serviço RTP. Um fluxo de serviço RTP geralmente igualmente contém uma taxa de tráfego reservado mínima a fim assegurar-se de que o tráfego associado com o fluxo de serviço possa receber uma garantia de largura de banda comprometida.

Unsolicited Grant Service com detecção de atividade (UGS-AD)

O Unsolicited Grant Service com detecção de atividade (UGS-AS) atribuir o tempo de transmissão do estilo UG a um fluxo de serviço somente quando necessidades UGS-AS realmente de transmitir pacotes. Quando o CMTS detecta que o modem a cabo não tem frames transmitido por um determinado período, o CMTS oferece oportunidades da requisição de largura de banda do estilo RTP em vez das concessões do estilo UG. Se o CMTS detecta subseqüentemente que o fluxo de serviço faz requisições de largura de banda, o CMTS reverte o fluxo de serviço de volta a oferecer o estilo UG concede e para de oferecer oportunidades da requisição de largura de banda do estilo RTP.

O UGS-AD é usado tipicamente em uma situação onde o tráfego voip que usou a detecção de atividade da Voz (VAD) esteja sendo transportado. A detecção de atividade da Voz faz com que o ponto final de VoIP pare a transmissão de quadros de VoIP se o UGS-AD detecta uma pausa no discurso do usuário. Embora este comportamento possa salvar a largura de banda, pode causar problemas com Qualidade de voz, especialmente se o mecanismo da detecção de atividade VAD ou UGS-AD ativa levemente depois que o partido da extremidade começa recomeçar falar. Isto pode conduzir a um som de estalo ou de clique enquanto um usuário recomeça falar após o silêncio. O UGS-AD não é distribuído por este motivo extensamente.

Emita o comando de configuração de CMTS global de ponto-em-segundos do inatividade-ponto inicial do fluxo do serviço de cabo ajustar o período depois do qual o CMTS comuta um fluxo de serviço inativo UGS-AD do modo de UGS ao modo RTPS.

O valor padrão para o parâmetro de ponto-em-segundos é os segundos 10. UGS-AD dos fluxos de serviço legiões geralmente os atributos de um fluxo de serviço UG e do intervalo de polling nominal e do atributo do retardo de sincronismo de eleição tolerado associado com os fluxos de serviço RTP.

Não serviço de polling do tempo real (nRTPS)

Não o modo da programação do serviço de polling do tempo real (nRTPS) é essencialmente o mesmo que RTP salvo que nRTPS é associado geralmente com os serviços não interativos tais como transferências de arquivo. Não o componente do tempo real pode implicar que o intervalo de polling nominal para oportunidades da requisição de largura de banda do unicast não é exatamente regular ou pode ocorrer a uma taxa menos de um de por segundo.

Alguns operadores de rede de cabo podem optar para usar o nRTPS em vez dos fluxos de serviço RTP para transportar o tráfego de sinalização de voz.

Algoritmos de escalonamento

Antes de uma discussão nos específicos do planificador do em conformidade com DOCSIS e do planificador do low latency queueing, você deve compreender as trocas que você precisa de fazer a fim determinar as características de um agendador de upstream. Embora o exame dos algoritmos de agendador se centre principalmente no modo de programação de UGS a discussão aplica-se ingualmente aos serviços do estilo RTP também.

Quando você decide como programar fluxos de serviço UG não há muitas opções flexíveis. Você não pode fazer o planificador mudar o intervalo do tamanho concedido ou da concessão de fluxos de serviço UG, porque tal mudança faz com que as chamadas VoIP falhem completamente. Contudo, se você muda o tremor, os atendimentos trabalham, embora possivelmente com latência aumentada no atendimento. Além, a alteração do número máximo de atendimentos permitidos em um ascendente não impacta os atendimentos da qualidade para serviços gerais e individuais. , Considere consequentemente estes dois fatores principais quando você programa um grande número fluxos de serviço UG:

  • Tremulação

  • Capacidade de fluxo de serviço UG por rio acima

Tremulação

Um tremulação de concessão tolerada é especificado como um dos atributos do fluxo de serviço UG ou RTP. Contudo, o suporte simultâneo de alguns fluxos de serviço com tremor tolerado muito baixo e de outro com muito grandes quantidades de tremor pode ser incapaz. Geralmente, você deve fazer uma escolha uniforme a respeito do tipo de tremor que os fluxos de serviço experimentam em um ascendente.

Se os níveis baixos do tremor são exigidos, o planificador precisa de ser inflexível e rígido quando programa concessões. Consequentemente, o planificador precisa de colocar limitações no número de fluxos de serviço UG apoiados em um ascendente.

Os níveis do Jitter não precisam sempre de ser extremamente - baixos para o consumidor normal VoIP porque a tecnologia do buffer do tremor pode compensar níveis altos do tremor. Os bufferes adaptáveis modernos do tremor de VoIP podem compensar mais do que 150ms do tremor. Contudo, uma rede voip adiciona a quantidade de proteção que ocorre à latência de pacotes. Os níveis altos da latência podem contribuir a VoIP uma experiência mais deficiente.

Capacidade de fluxo de serviço UG por rio acima

Os atributos da camada física tais como a força da largura do canal, do esquema de modulação e da correção de erros determinam a capacidade física de um ascendente. Contudo, o número de fluxos de serviço simultâneos UG que o ascendente pode apoiar igualmente depende do algoritmo de agendador.

Se extremamente - os níveis do tremulação baixa não são necessários, você pode relaxar a rigidez do planificador e cobrir um número mais alto de fluxos de serviço UG que o ascendente pode simultaneamente apoiar. Você pode conseguir uma eficiência mais alta não do tráfego de voz no ascendente se você relaxa as exigências do tremor.

Nota: Os algoritmos de escalonamento diferentes podem permitir que um canal upstream particular apoie vários números de fluxos de serviço UG e RTP. Contudo, tais serviços não podem utilizar 100% da potencialidade de upstream em um sistema de DOCSIS. Isto é porque o canal upstream deve dedicar uma parcela ao tráfego de gerenciamento DOCSIS tal como as mensagens da manutenção inicial que o Modems a cabo se usa para fazer a contato inicial com o CMTS, e o tráfego de keepalive da manutenção de estação usado para se assegurar de que o Modems a cabo possa manter a Conectividade ao CMTS.

O planificador do em conformidade com DOCSIS

O planificador do em conformidade com DOCSIS é o sistema padrão para programar serviços upstream em um uBR CMTS de Cisco. Este planificador foi projetado minimizar o tremor que os fluxos de serviço UG e RTP experimentam. Contudo, este planificador ainda permite que você mantenha algum grau de flexibilidade a fim aperfeiçoar o número de atendimentos simultâneos UG por rio acima.

O planificador do em conformidade com DOCSIS PRE-atribui a hora ascendente adiantado para fluxos de serviço UG. Antes que todas as outras alocações de largura de banda estejam programadas, o CMTS reservou a hora no futuro para as concessões que pertencem aos fluxos de serviço ativos UG para se assegurar de que nenhuns dos outros tipos de fluxos de serviço ou de tráfego desloquem as concessões UG e causem o tremor significativo.

Se o CMTS recebe requisições de largura de banda em nome do melhor esforço denomina fluxos de serviço, o CMTS deve programar o tempo de transmissão para os fluxos de serviço de melhor esforço em torno dos UG PRE-atribuídos concede para não impactar na programação oportuna de cada concessão UG.

Configuração

O planificador do em conformidade com DOCSIS é o único algoritmo de agendador de upstream disponível para Cisco IOS Software Release 12.3(9a)BCx e Anterior. Consequentemente, este planificador não exige nenhum comando configuration para a ativação.

Para Cisco IOS Software Release 12.3(13a)BC e Mais Recente, o planificador do em conformidade com DOCSIS é um de dois algoritmos de agendador alternativo, mas é ajustado como o planificador do padrão. Você pode permitir o planificador do em conformidade com DOCSIS para um, todos ou alguns estes tipos de programação:

  • UGS

  • RTPS

  • NRTPS

Você pode explicitamente permitir o planificador do em conformidade com DOCSIS para cada um destes tipos de programação com o tipo de programação da porta upstream do cabo rio acima [nrtps | rtps | comando cable interface do docsis do modo do ugs].

O uso do planificador do em conformidade com DOCSIS é parte da configuração padrão. Consequentemente, você precisa de executar este comando somente se você muda para trás do algoritmo de agendador não-padrão do low latency queueing. Veja a seção do planificador do low latency queueing para mais informação.

Controle de admissão

Uma grande vantagem do planificador do em conformidade com DOCSIS é que este planificador se assegura de que os fluxos de serviço UG sobre não subscrevam o ascendente. Se um fluxo de serviço novo UG deve ser estabelecido, e o planificador descobre que uma PRE-programação das concessões não é possível porque nenhuma sala é saida, o CMTS rejeita o fluxo de serviço novo UG. Se os fluxos de serviço UG que transportam o tráfego voip são permitidos ao oversubscribe um canal upstream, a qualidade de todas as chamadas VoIP torna-se degradada severamente.

A fim demonstrar como o planificador do em conformidade com DOCSIS se assegura de que UG dos fluxos de serviço o oversubscribe nunca o ascendente, refira as figuras nesta seção. Figura 7, 8 e linhas de tempo da alocação de largura de banda da mostra 9.

Em todas estas figuras, as seções modeladas na cor mostram ao tempo onde o Modems a cabo recebe concessões em nome de seus fluxos de serviço UG. Nenhuma outra transmissão fluxo acima do outro Modems a cabo pode ocorrer durante esse tempo. O cinza parte da linha de tempo é até agora largura de banda unallocated. O Modems a cabo usa este tempo transmitir requisições de largura de banda. O CMTS pode mais tarde usar este tempo programar outros tipos de serviços.

Figura 7 – PRE-programações do planificador do em conformidade com DOCSIS três fluxos de serviço UG

/image/gif/paws/69704/upstrm_sch_config_07.gif

Adicionar dois mais fluxos de serviço UG do mesmo intervalo do tamanho concedido e da concessão. Ainda, o planificador não tem nenhuma PRE-programação do problema eles.

Figura 8 – PRE-programações do planificador do em conformidade com DOCSIS cinco fluxos de serviço UG

/image/gif/paws/69704/upstrm_sch_config_08.gif

Se você vai adiante e adiciona dois mais fluxos de serviço UG, você enche acima toda a largura de banda fluxo acima disponível.

Figura 9 – Os fluxos de serviço UG consomem toda a largura de banda fluxo acima disponível

/image/gif/paws/69704/upstrm_sch_config_09.gif

Claramente, o planificador não pode admitir nenhuns fluxos de serviço mais adicionais UG aqui. Consequentemente se um outro fluxo de serviço UG tenta se tornar ativo, o planificador do em conformidade com DOCSIS realiza que não há nenhuma sala para umas concessões mais adicionais, e impede o estabelecimento desse fluxo de serviço.

Nota: É impossível encher completamente um ascendente com os fluxos de serviço UG como visto nesta série de figuras. O planificador precisa de acomodar outros tipos de tráfego importantes por exemplo, Keepalives da manutenção de estação e o melhor tráfego de dados do esforço. Também, a garantia para evitar a sobreassinatura com o planificador do em conformidade com DOCSIS aplica-se somente se todos os modos da programação do fluxo de serviço, a saber UG, RTP e nRTPS, usam o planificador do em conformidade com DOCSIS.

Embora a configuração de controle de admissão explícita não seja necessária quando você usa o planificador do em conformidade com DOCSIS, Cisco recomenda que você se assegura de que a utilização do canal de upstream não aumente aos níveis que podem negativamente impactar o tráfego de melhor esforço. Cisco igualmente recomenda que a utilização do canal de upstream do total não deve exceder 75% para quantidades significativas de tempo. Este é o nível da utilização de upstream onde os serviços best effort começam experimentar muitas alta latência e taxa de transferência mais lenta. Os serviços UG ainda funcionam, apesar da utilização de upstream.

Se você quer limitar a quantidade de tráfego admitida em um detalhe rio acima, configurar o controle de admissão para UG, RTP, NRTPS, UGS-AD ou fluxos de serviço de melhor esforço com o global, pela interface de cabo ou pelo comando ascendente. O parâmetro o mais importante é o exclusivo-ponto-por cento coloca.

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

Estão aqui os parâmetros:

  • [upstream <upstream-number>]: Especifique este parâmetro se você quer aplicar rio acima o comando a um detalhe um pouco do que uma interface de cabo ou globalmente.

  • <UGS|AD-UGS|RTPS|NRTPS|BE>: Este parâmetro especifica o modo da programação de fluxos de serviço a que você quer aplicar o controle de admissão.

  • <minor-threshold-percent>: Este parâmetro indica a porcentagem da utilização de upstream pelo tipo de programação configurado em que um alarme menor é enviado a uma estação de gerenciamento de rede.

  • <major-threshold-percent>: Este parâmetro especifica a porcentagem da utilização de upstream pelo tipo de programação configurado em que um alarme principal é enviado a uma estação de gerenciamento de rede. Este valor deve ser mais alto do que o valor você ajustado para o parâmetro do <minor-threshold-percent>.

  • <exclusive-threshold-percent>: Este parâmetro representa a porcentagem da utilização de upstream reservada exclusivamente para o tipo de programação especificado. Se você não especifica o valor para o <non-excl-threshold-percent>, este valor representa o limite máximo na utilização para este tipo de fluxo de serviço. Este valor deve ser maior do que o valor do <major-threshold-percent>.

  • <non-excl-threshold-percent>: Este parâmetro representa a porcentagem da utilização de upstream acima do <exclusive-threshold-percent> que este tipo de programação pode usar, enquanto um outro tipo de programação já não o usa.

Por exemplo, supõe que você quer limitar os fluxos de serviço UG a 60% da largura de banda fluxo acima disponível total. Igualmente supõe que você tem as estações de gerenciamento de rede notificadas que se a porcentagem da utilização de upstream devido aos fluxos de serviço UG aumentou sobre 40%, um alarme menor devem ser enviadas e sobre 50%, um alarme principal deve ser enviado. Emita este comando:

cabografe o exclusive principal 60 dos 50 pés do tipo de programação da nos-largura de banda do controle de admissão 40 UGS secundários

Tráfego de melhor esforço de programa usando a fragmentação

O planificador do em conformidade com DOCSIS programa simplesmente o tráfego de melhor esforço em torno das concessões PRE-atribuídas UG ou RTP. As figuras nesta seção demonstram este comportamento.

Figura 10 – O melhor esforço concede durante a programação

/image/gif/paws/69704/upstrm_sch_config_10.gif

A figura 10 mostra que o ascendente tem três fluxos de serviço UG com o mesmo intervalo do tamanho concedido e da concessão pré-programado. Ascendente recebe requisição de largura de banda em nome de três separado fluxo de serviço, A, o fluxo de serviço A B e C. pede uma quantidade de tempo de transmissão média, o fluxo de serviço B pede uma quantidade pequena de tempo de transmissão e o C do fluxo de serviço pede uma grande quantidade de tempo de transmissão.

Prioridade de igualdade do acordo a cada um dos fluxos de serviço de melhor esforço. Também, supõe que o CMTS recebe as requisições de largura de banda para cada um destas concessões na ordem A então B, e então C. O CMTS atribui primeiramente o tempo de transmissão para as concessões na mesma ordem. Figura 11 mostra como o planificador do em conformidade com DOCSIS atribui aquelas concessões.

Figura 11 – As melhores concessões do esforço programadas em torno das concessões fixas do fluxo de serviço UG

/image/gif/paws/69704/upstrm_sch_config_11.gif

O planificador pode espremer junto as concessões para A e B na diferença entre os primeiros dois blocos de concessões UG. Contudo, a concessão para o C é mais grande do que toda a diferença disponível. Consequentemente, o planificador do em conformidade com DOCSIS fragmenta a concessão para o C em torno do terceiro bloco de concessões UG em duas concessões menores chamadas C1 e C2. A fragmentação impede atrasos para concessões UG, e assegura-se de que estas concessões não sejam sujeitas tremer que causas do tráfego de melhor esforço.

A fragmentação aumenta levemente as despesas gerais de protocolo DOCSIS associadas com a transmissão de dados. Para cada fragmento extra transmitido, um grupo extra de cabeçalhos de DOCSIS deve igualmente ser transmitido. Contudo, sem fragmentação o planificador não pode eficientemente intercalar as melhores concessões do esforço entre concessões fixas UG. A fragmentação não pode ocorrer para o Modems a cabo que se opera no modo do DOCSIS 1.0.

Prioridade

O planificador do em conformidade com DOCSIS coloca as concessões que estão esperando a atribuição no as filas baseadas na prioridade do fluxo de serviço a que a concessão pertence. Há oito prioridades de DOCSIS com zero como o mais baixo e sete como o mais alto. Cada um destas prioridades tem uma fila associada.

O planificador do em conformidade com DOCSIS usa um mecanismo de filas da prioridade estrita para determinar quando as concessões da prioridade diferente são atribuídas tempo de transmissão. Ou seja todas as concessões armazenadas nas filas de alta prioridade devem ser servidas antes das concessões nas filas de baixa prioridade.

Por exemplo, supõe que o planificador do em conformidade com DOCSIS recebe cinco concessões em um período curto na ordem A, B, C, D, E e F. As filas de planificador cada um das concessões acima na fila que corresponde à prioridade do fluxo de serviço da concessão.

Figura 12 – Concessões com prioridades diferentes

upstrm_sch_config_12.gif

Concessões do esforço das programações do planificador do em conformidade com DOCSIS as melhores em torno das concessões pré-programados UG que aparecem como blocos modelados em figura 12. A primeira ação as tomadas do planificador do em conformidade com DOCSIS é verificar a fila a mais prioritária. Neste caso a fila da prioridade 7 tem as concessões prontas para programar. O planificador vai adiante e atribui o tempo de transmissão para as concessões B e E. Observe que a concessão E precisa a fragmentação de modo que a concessão não interfira com o sincronismo das concessões PRE-atribuídas UG.

Figura 13 – Concessões da prioridade de agendamento 7

/image/gif/paws/69704/upstrm_sch_config_13.gif

O planificador certifica-se de que todas as concessões da prioridade 7 recebem o tempo de transmissão. Então, o planificador verifica a fila da prioridade 6. Neste caso, a fila da prioridade 6 está vazia assim que os movimentos do planificador ligada à fila da prioridade 5 que contém o C da concessão.

Figura 14 – Concessões da prioridade de agendamento 5

/image/gif/paws/69704/upstrm_sch_config_14.gif

O planificador continua então de forma semelhante através das filas de baixa prioridade até que todas as filas estejam vazias. Se há um grande número concessões a programar, as requisições de largura de banda novas podem alcançar o CMTS antes que o planificador do em conformidade com DOCSIS termine a atribuição do tempo de transmissão a todas as concessões pendentes. Supõe que o CMTS recebe uma requisição de largura de banda G da prioridade 6 neste momento no exemplo.

Figura 15 – Uma prioridade 6 Grant é enfileirada

/image/gif/paws/69704/upstrm_sch_config_15.gif

Mesmo que conceda a espera A, F e D mais por muito tempo do que a concessão recentemente enfileirada G, o planificador do em conformidade com DOCSIS deve em seguida atribuir o tempo de transmissão a G porque G tem a prioridade mais alta. Isto significa que as alocações de largura de banda seguintes do planificador do em conformidade com DOCSIS serão G, A então D (veja figura 16).

Figura 16 – Prioridade de agendamento 6 e concessões da prioridade 2

/image/gif/paws/69704/upstrm_sch_config_16.gif

A concessão seguinte a ser programada é F, se você supõe que nenhuma concessão da prioridade mais alta incorpora o sistema de enfileiramento no entretanto.

O planificador do em conformidade com DOCSIS tem duas mais filas que não foram mencionadas nos exemplos. A primeira fila é a fila usada para programar o tráfego de keepalive periódico da manutenção de estação a fim manter o Modems a cabo em linha. Esta fila é usada para programar oportunidades para que o Modems a cabo envie ao CMTS o tráfego de keepalive periódico. Quando o planificador do em conformidade com DOCSIS é ativo, esta fila está servida primeiramente antes de todas filas restantes. O segundo é uma fila para as concessões atribuídas aos fluxos de serviço com uma taxa reservada mínima (CIR) especificada. O planificador trata esta fila CIR porque uma fila da prioridade 8 a fim se assegurar de que os fluxos de serviço com uma taxa comprometida recebam a taxa de transferência mínima exigida.

Concessões do DOCSIS 1.0 do não-fragmentável

Dos exemplos na seção anterior, as concessões precisam às vezes de ser fragmentadas em partes múltiplas a fim assegurar-se de que o tremor não esteja induzido em concessões PRE-atribuídas UG. Este pode ser um problema para o Modems a cabo que se opera no modo do DOCSIS 1.0 em segmentos ascendentes com uma quantidade significativa de UG trafica, porque um Cable Modem DOCSIS 1.0 pode pedir para transmitir um quadro que seja demasiado grande caber na oportunidade de transmissão disponível seguinte.

Está aqui um outro exemplo, que suponha que o planificador recebe novo concede A e B nessa ordem. Igualmente supõe que ambas as concessões têm a mesma prioridade mas que a concessão B é para um modem a cabo que se opere no modo do DOCSIS 1.0.

Figura 17 – Concessões pendentes do DOCSIS 1.1 e do DOCSIS 1.0

/image/gif/paws/69704/upstrm_sch_config_17.gif

O planificador tenta atribuir primeiramente a hora para a concessão A. Então o planificador tenta atribuir a oportunidade de transmissão disponível seguinte conceder o B. Contudo, não há nenhuma sala para a concessão B permanecer não-fragmentado entre A e o bloco seguinte de concessões UG (veja figura 18).

Figura 18 – DOCSIS 1.0 Grant B adiado

upstrm_sch_config_18.gif

Por este motivo, a concessão B é atrasada até depois o segundo bloco de concessões UG onde há uma sala para a concessão B caber. Observe que esteja agora o espaço não utilizado antes que o segundo bloco de concessões UG. O Modems a cabo usa este tempo transmitir requisições de largura de banda ao CMTS, mas este representa um uso incapaz da largura de banda.

Revisite este exemplo e adicionar dois fluxos de serviço extra UG ao planificador. Quando a concessão A puder ser fragmentada, não há nenhuma oportunidade para a concessão B do não-fragmentável de ser programado porque a concessão B é demasiado grande caber entre blocos de concessões UG. Esta situação sae do modem a cabo associado com a concessão B incapaz de transmitir grandes quadros no ascendente.

Figura 19 – O DOCSIS 1.0 Grant B não pode ser programado

/image/gif/paws/69704/upstrm_sch_config_19.gif

Você pode permitir que o planificador elimine simplesmente, ou atrase levemente um bloco de concessões UG a fim fazer a sala para a concessão B mas as causas desta ação tremem no fluxo de serviço UG. No momento se você supõe que você quer minimizar o tremor, esta é uma solução inaceitável.

A fim superar periodicamente esta edição com grandes concessões do DOCSIS 1.0 do não-fragmentável, os blocos das PRE-programações do planificador do em conformidade com DOCSIS de tempo ascendente tão grandes quanto o quadro o maior que um Cable Modem DOCSIS 1.0 pode transmitir. O planificador faz assim antes que todos os fluxos de serviço UG estejam programados. Esta vez é tipicamente o equivalente de aproximadamente 2000 bytes da transmissão fluxo acima, e é chamada do “o bloco não-fragmentável” ou “o bloco livre UG”.

O planificador do em conformidade com DOCSIS não coloca nenhuns UG ou RTP as concessões do estilo que nos tempos atribuídos ao não-fragmentável traficam para se assegurar de que haja sempre uma oportunidade para que as grandes concessões do DOCSIS 1.0 estejam programadas. Neste sistema, a reserva da hora para o tráfego do DOCSIS 1.0 do não-fragmentável reduz o número de fluxos de serviço UG que o ascendente pode simultaneamente apoiar.

Figura 20 mostra o bloco do não-fragmentável no azul e quatro fluxos de serviço UG com o mesmo intervalo do tamanho concedido e da concessão. Você não pode adicionar um outro fluxo de serviço UG do mesmo intervalo do tamanho concedido e da concessão a este rio acima porque as concessões UG não são permitidas ser programadas na região azul do bloco do não-fragmentável.

Figura 20 – O bloco do não-fragmentável: Nenhuma concessão mais adicional UG pode ser admitida

/image/gif/paws/69704/upstrm_sch_config_20.gif

Mesmo que o bloco do não-fragmentável seja programado menos frequentemente do que o período das concessões UG, este bloco tende a causar um espaço da largura de banda unallocated tão grande quanto próprio entre todos os blocos de concessões UG. Isto fornece a oportunidade ampla para que as grandes concessões do não-fragmentável sejam programadas.

Retorne ao exemplo da concessão A e do DOCSIS 1.0 Grant B, você pode ver que com o bloco do não-fragmentável no lugar, o planificador do em conformidade com DOCSIS pode agora com sucesso programar a concessão B depois que o primeiro bloco de concessões UG.

Figura 21 – Concessões de programa com o uso do bloco do não-fragmentável

/image/gif/paws/69704/upstrm_sch_config_21.gif

Embora a concessão B do DOCSIS 1.0 seja programada com sucesso, há ainda uma diferença pequena da concessão A do espaço não utilizado no meio e do primeiro bloco de concessões UG. Esta diferença representa um uso suboptimal da largura de banda e demonstra porque você deve usar o Modems a cabo do modo do DOCSIS 1.1 quando você distribui serviços UG.

Default-phy-burst do cabo

À revelia em um uBR CMTS de Cisco, a explosão a maior que um modem a cabo pode transmitir é 2000 bytes. Este valor para o tamanho o maior da intermitência fluxo acima é usado para calcular o tamanho do bloco do não-fragmentável como os usos do planificador do em conformidade com DOCSIS.

Você pode mudar o tamanho de intermitência o maior com a MAX-byte-permitir-em-explosão do default-phy-burst do cabo pelo comando cable interface.

O parâmetro do <max-bytes-allowed-in-burst> tem uma escala de 0 a 4096 bytes e de um valor padrão de 2000 bytes. Há algumas limitações importantes em como você deve ajustar este valor se você quer mudar o valor do valor padrão.

Para interfaces de cabo na placa de linha do MC5x20S, não ajuste este parâmetro acima do padrão de 2000 bytes. Para todos tipos restantes da placa de linha, incluindo as placas de linha MC28U, MC5x20U e MC5x20H, você pode ajustar este parâmetro tão altamente quanto 4000 bytes.

Não ajuste o parâmetro do <max-bytes-allowed-in-burst> mais baixo do que o tamanho do único frame da Ethernet o maior que um modem a cabo pode precisar de transmitir incluir as despesas gerais DOCSIS ou 802.1q. Isto significa que este valor deve ser não mais baixo do que aproximadamente 1540 bytes.

Se você ajusta o <max-bytes-allowed-in-burst> ao valor especial de 0, o CMTS não usa este parâmetro para restringir o tamanho de uma intermitência fluxo acima. Você precisa de configurar outras variáveis a fim restringir o tamanho da intermitência fluxo acima a um limite razoável, tal como o ajuste da intermitência máxima concatenada no arquivo de configuração DOCSIS, ou o comando ascendente do fragment-force do cabo.

Quando você altera o default-phy-burst do cabo para mudar o tamanho da intermitência máxima de fluxo, o tamanho do bloco livre UG está alterado igualmente em conformidade. Figura 22 mostra que se você reduz o default-phy-burst do cabo que se ajusta, o tamanho do bloco livre UG se reduz, e consequentemente o planificador do em conformidade com DOCSIS pode reservar mais UG chama um ascendente. Neste exemplo, reduza o default-phy-burst do cabo da configuração padrão de 2000 a um ajuste mais baixo de 1600 para permitir a sala para que um mais fluxo de serviço UG torne-se ativo.

Figura 22 – O default-phy-burst reduzido diminui o tamanho de bloco do não-fragmentável

/image/gif/paws/69704/upstrm_sch_config_22.gif

Redução do máximo - o tamanho de intermitência permissível com o comando cable default-phy-burst pode levemente diminuir a eficiência do ascendente para o tráfego de melhor esforço, porque este comando reduz o número de quadros que podem ser concatenados dentro de um estourado. Tal redução pode igualmente conduzir aos níveis aumentados da fragmentação quando o ascendente tem um número maior de fluxos de serviço UG ativos.

Os tamanhos reduzidos da intermitência concatenada podem impactar a velocidade da transferência de arquivo pela rede dos dados em um fluxo de serviço de melhor esforço. Isto é porque a transmissão dos frames múltiplos é imediatamente mais rápida do que a transmissão de uma requisição de largura de banda para cada quadro. Os níveis reduzidos da concatenação podem igualmente potencialmente impactar a velocidade das transferências devido a uma capacidade diminuída do modem a cabo para concatenar um grande número pacotes de ACK TCP que viajam na direção de upstream.

Às vezes, o tamanho de intermitência máxima como configurado no IUC “longo” do perfil de modulação do cabo aplicado a um ascendente, pode determinar o tamanho o maior da intermitência fluxo acima. Isto pode ocorrer se o tamanho de intermitência máxima no perfil de modulação é menos do que o valor do default-phy-burst do cabo nos bytes. Este é um cenário raro. Contudo, se você aumenta o parâmetro do default-phy-burst do cabo do padrão de 2000 bytes, verifique o tamanho de intermitência máxima na configuração do IUC “longo” para assegurar-se de que não limite explosões.

A outra limitação ao tamanho da intermitência fluxo acima é que um máximo de 255 minislots pode ser transmitido em um estourado. Este pode transformar-se um fator se o tamanho de minislot é ajustado ao mínimo de 8 bytes. Um minislot é a unidade a menor de transmissão fluxo acima em uma rede de DOCSIS e é geralmente equivalente a 8 ou 16 bytes.

Jitter do entalhe do não-fragmentável

Uma outra maneira à emenda o planificador do em conformidade com DOCSIS a fim permitir um número mais alto de UG simultâneos flui em um ascendente é permitir que o planificador deixe grandes explosões do tráfego de melhor esforço do não-fragmentável introduzir quantidades pequenas de tremor aos fluxos de serviço UG. Você pode fazer assim com o comando cable interface val do limite do unfrag-entalhe-Jitter do rio acima-número do cabo rio acima.

Neste comando, o <val> é especificado nos microssegundos e tem um valor padrão de zero, assim que significa que o comportamento padrão para o planificador do em conformidade com DOCSIS é não permitir que as concessões do não-fragmentável causem o tremor para fluxos de serviço UG e RTP. Quando um tremor positivo do entalhe do não-fragmentável é especificado, o planificador do em conformidade com DOCSIS pode atrasar concessões UG até por microssegundos do <val> de quando a concessão UG deve idealmente ser programada, e daqui por tremor da causa.

Isto tem o mesmo efeito que a redução do tamanho de bloco do não-fragmentável por um comprimento equivalente ao número de microssegundos especificados. Por exemplo, se você mantém o valor padrão para o default-phy-burst (2000 bytes) e se você especifica um valor de 1000 microssegundos para o tremor do entalhe do não-fragmentável, o bloco do não-fragmentável se reduz (veja figura 23).

Figura 23 – O Jitter diferente de zero do entalhe do não-fragmentável diminui o tamanho de bloco do não-fragmentável

/image/gif/paws/69704/upstrm_sch_config_23.gif

Nota: O número de bytes a que o tempo 1000-microsecond corresponde depende de como o canal upstream é configurado rapidamente para se operar através dos ajustes da largura do canal e do esquema de modulação.

Nota: Com um tremor que diferente de zero do entalhe do não-fragmentável o planificador do em conformidade com DOCSIS pode aumentar o número de UG concede que apoios ascendentes de forma semelhante a ter um default-phy-burst reduzido.

Nota: Retorne ao exemplo com uma grande concessão A do DOCSIS 1.1 seguida por uma grande concessão B do DOCSIS 1.0 do não-fragmentável para programar em um ascendente. Você ajustou o tremor do entalhe do não-fragmentável a 1000 microssegundos. O planificador do em conformidade com DOCSIS comporta-se segundo as indicações das figuras nesta seção.

Nota: Primeiramente, o planificador atribui o tempo de transmissão para a concessão A. Para fazer assim, o planificador fragmenta a concessão no A1 e no A2 das concessões de modo que as concessões cabidas antes e depois de que o primeiro bloco de concessões UG. A fim programar a concessão B, o planificador tem que decidir se o planificador pode caber o bloco do não-fragmentável no espaço livre depois que A2 da concessão sem um atraso ao bloco seguinte de concessões UG por mais do que o tremor configurado do entalhe do não-fragmentável de 1000 microssegundos. Estas figuras mostram que se os lugares do planificador concedem B ao lado do A2 da concessão, o bloco seguinte de tráfego UG está atrasado, ou empurrado para trás, em mais de 1500 microssegundos. Consequentemente o planificador não pode colocar a concessão B diretamente após o A2 da concessão.

Figura 24 – Grant B incapaz de ser programado ao lado do A2 de Grant.

/image/gif/paws/69704/upstrm_sch_config_24.gif

A próxima etapa para o planificador do em conformidade com DOCSIS é considerar se a diferença disponível seguinte pode acomodar a concessão B. Figura 25 mostra que se a concessão B dos lugares do planificador depois que o segundo bloco de concessões UG, o terceiro bloco não está atrasado por mais do que o tremor configurado do entalhe do não-fragmentável de 1000 microssegundos.

Figura 25 – Grant B programado depois que o segundo bloco de concessões UG

/image/gif/paws/69704/upstrm_sch_config_25.gif

Com o conhecimento que a inserção da concessão B neste momento não causa o tremor inaceitável às concessões UG, a concessão B das inserções do planificador do em conformidade com DOCSIS e atrasa levemente o seguinte bloco de concessões UG.

Figura 26 – O não-fragmentável Grant B é programado e as concessões UG são atrasadas

/image/gif/paws/69704/upstrm_sch_config_26.gif

saída do comando show

Você pode usar o comando do rio acima-número do agendador de mac do número de interface do cabo de interface da mostra calibrar o status atual do planificador do em conformidade com DOCSIS. Está aqui um exemplo da saída deste comando como considerado em um uBR7200VXR de Cisco com uma placa de linha MC28U.

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

Esta seção explica cada linha da saída deste comando. Note que esta seção do documento supõe que você é já bastante familiar com os conceitos de programação de upstream de DOCSIS gerais.

  • Agendador de MAC do DOCSIS 1.1 para Cable3/0/U0

    A primeira linha da saída do comando indica a porta upstream a que os dados pertencem.

  • Enfileire o [Rng Polls] 0/128, as gotas 0, max1

    Esta linha mostra o estado da fila qual alimenta o Keepalives ou as oportunidades de ajuste de alcance da manutenção de estação no planificador do em conformidade com DOCSIS. 0/128 indicam que há atualmente zero fora de um máximo das oportunidades de ajuste de alcance 128 pendentes na fila.

    As gotas contrárias indicam que o número de vezes uma oportunidade de ajuste de alcance não poderia ser enfileirado acima de porque esta fila estava já completa (isto é, oportunidades de ajuste de alcance 128 pendentes). As gotas aqui somente ocorreriam provavelmente em um ascendente com extremamente um número grande de Modems a cabo em linha e se havia um grande número fluxos de serviço UG ou RTP ativos. Esta fila está prestada serviços de manutenção com a prioridade mais alta quando o planificador da conformidade de DOCSIS é executado. Consequentemente, as gotas nesta fila são altamente improváveis mas indicam muito provavelmente uma assinatura em excesso grave do canal upstream.

    O contador máximo indica o número máximo de presente dos elementos e nesta fila desde que o comando do agendador de mac do cabo de interface da mostra era última corrida. Idealmente isto deve permanecer tão perto a zero como possível.

  • Enfileire o [CIR Grants] 0/64, as gotas 0, 0 máximo

    Esta linha mostra o estado da fila qual controla concessões para fluxos de serviço com uma taxa de tráfego reservado mínima especificada. Ou seja esta fila presta serviços de manutenção a concessões para fluxos de serviço da taxa de informação comprometida (CIR). 0/64 indicam que há atualmente zero fora de um máximo de 64 concessões pendentes na fila.

    As gotas contrárias indicam que o número de vezes uma concessão CIR não poderia ser enfileirado acima de porque esta fila estava já completa (isto é, 64 concessões na fila). As gotas podem acumular aqui se os UG, os RTP e o CIR denominam o oversubscribe dos fluxos de serviço o ascendente, e podem indicar a necessidade para um controle de admissão mais restrito.

    O contador máximo indica o número máximo de concessões nesta fila desde que o comando do agendador de mac do cabo de interface da mostra era última corrida. Esta fila tem a segunda prioridade mais alta assim que o planificador do em conformidade com DOCSIS atribui a hora para elementos desta fila antes dos serviços de programador que o melhor esforço se enfileira.

  • Enfileire o [BE(w) Grants] x/64, gotas y, z máximo

    As oito entradas seguintes mostram o estado das filas que controlam concessões para a prioridade 7 com os fluxos de serviço 0. Os campos nestas entradas têm o mesmo significado que os campos na entrada de fila CIR. A primeira fila a ser servida neste grupo é a fila SER (7) e o último a ser servido é as 0) filas SER (.

    As gotas podem ocorrer nestes fluxos de serviço das filas se um nível mais prioritário do tráfego consome toda a largura de banda fluxo acima ou se sobreassinatura do ascendente com UG, do estilo RTP e CIR ocorrem. Isto pode indicar a necessidade de reavaliar as prioridades de DOCSIS para fluxos de serviço do volume alto ou uma necessidade para um controle de admissão mais restrito no ascendente.

  • Entalhes 36356057 do req

    Esta linha indica o número de oportunidades da requisição de largura de banda que foram anunciadas desde que o ascendente foi ativado. Este número deve estar continuamente em um aumento.

  • Req/entalhes 185165 dos dados

    Embora o nome sugira que este campo mostre o número de oportunidades do pedido ou dos dados anunciadas no ascendente, este campo mostra realmente o número de períodos que o CMTS anuncia a fim facilitar a funcionalidade da gerência avançada do spectrum. Este contador é esperado incrementar para upstreams em placas de linha do estilo MC28U e MC520.

    As oportunidades do pedido/dados são as mesmas que oportunidades da requisição de largura de banda salvo que o Modems a cabo pode igualmente transmitir explosões pequenas dos dados nestes períodos. As séries Cisco uBR CMTS não programam atualmente oportunidades reais do pedido/dados.

  • Init Mtn entalha 514263

    Esta linha representa o número de oportunidades da manutenção inicial que foram anunciadas desde que o ascendente foi ativado. Este número deve estar continuamente na elevação. Modems a cabo que faz tentativas inicial de estabelecer a Conectividade às oportunidades da manutenção inicial do uso CMTS.

  • Stn Mtn entalha 314793

    Esta linha indica o número de keepalive ou de oportunidades de ajuste de alcance da manutenção de estação oferecido no ascendente. Se há Modems a cabo em linha no ascendente, este número deve estar continuamente na elevação.

  • A concessão breve entalha 12256, os slots de concessão longos 4691

    Esta linha indica o número de concessões de dados oferecidas no ascendente. Se há o Modems a cabo que transmite dados ascendentes, estes números devem estar continuamente na elevação.

  • A concessão breve ATDMA entalha 0, os slots de concessão longos 0 ATDMA, os entalhes 0 ATDMA UG Grant

    Esta linha representa o número de concessões de dados oferecidas em modo avançado do acesso múltiplo de divisão de tempo (ATDMA) no ascendente. Se há o Modems a cabo que se opera no modo do DOCSIS 2.0, e nelas transmite dados ascendentes, estes números devem estar continuamente na elevação. Note que o ATDMA esclarece separadamente o tráfego UG.

  • Slots awacs 277629

    Esta linha mostra o número de períodos dedicados à gerência avançada do spectrum. Para que a gerência avançada do spectrum ocorra, o CMTS precisa de programar periodicamente épocas onde cada modem a cabo deve fazer uma breve transmissão de modo que a função interna da análise de espectro possa avaliar a qualidade de sinal de cada modem.

  • Contagem de fragmentação 41

    Esta linha mostra o número total de fragmentos que a porta upstream é programada para receber. Por exemplo, um quadro que fosse fragmentado em três porções causaria este ao contrário do incremento por três.

  • Teste da fragmentação desabilitado

    Esta linha indica que o comando de fragmentação do cabo do teste não esteve invocado. Não use este comando em uma rede de produção.

  • Utilização do canal de upstream do médio: 26%

    Esta linha mostra a utilização do canal de upstream atual por transmissões de dados ascendentes. Isto abrange as transmissões feitas com curto, longo, o ATDMA curto, o ATDMA longo e concessões ATDMA UG. O valor é calculado cada segundo como uma média do rolamento. Cisco recomenda que este valor não exceder 75% em uma base prolongada durante o tempo de pico de uso. Se não os utilizadores finais podem começar observar problemas de desempenho com tráfego de melhor esforço.

  • Slots de contenção do percentagem média: 73%

    Esta linha mostra a porcentagem do tempo ascendente dedicada às requisições de largura de banda. Isto iguala à quantidade de período livre no ascendente, e reduz-se consequentemente enquanto a porcentagem da utilização do canal de upstream do médio aumenta.

  • Slot de ajuste do alcance inicial do percentagem média: 2%

    Esta linha indica a porcentagem do tempo ascendente dedicada às oportunidades do alcance inicial que o Modems a cabo usa quando faz tentativas de estabelecer a conectividade inicial com o CMTS. Este valor deve sempre permanecer um baixo porcentagem de utilização total.

  • Minislots do percentagem média perdidos em mapas atrasados: 0%

    Esta linha indica a porcentagem do tempo ascendente que não foi programado porque o CMTS era incapaz de transmitir a tempo uma mensagem do mapa de alocação de largura de banda ao Modems a cabo. Este parâmetro deve sempre ser próximo a zero mas pode começar mostrar valores maiores nos sistemas que têm uma carga de CPU extremamente alta.

  • Rsv-estado da tabela de Sched: Concessões 0, Reqpolls 0

    Esta linha mostra o número de fluxos de serviço dos fluxos de serviço do estilo UG (concessões) ou do estilo RTP (Reqpolls) que têm as concessões PRE-atribuídas para elas no planificador do em conformidade com DOCSIS, mas ativado não ainda. Isto ocorre quando você move um modem a cabo com UG ou RTP de um fluxos de serviço existentes rio acima para outro com o Balanceamento de carga. Note que esta figura se aplica somente às concessões que usam o planificador do em conformidade com DOCSIS, e não ao agendador LLQ.

  • Estado de ADM de tabela programada: Concede 6, Reqpolls 0, Util 27%

    Esta linha indica que o número de fluxos de serviço do estilo UG (concessões) ou os RTP denominam os fluxos de serviço (Reqpolls) que têm as concessões PRE-atribuídas para elas no planificador do em conformidade com DOCSIS para este rio acima. O Util é a utilização calculada da largura de banda fluxo acima disponível total por estes fluxos de serviço. Note que esta figura se aplica somente às concessões que usam o planificador do em conformidade com DOCSIS, e não ao agendador LLQ.

  • <Scheduling-type>: x SID, Reserva-nível em bps y

    Esta linha indica o número de fluxos de serviço do <Scheduling-type> ou de SID que estam presente no ascendente, e a quantidade de largura de banda em bits por segundo que estes fluxos de serviço reservaram. Para o melhor esforço e os RTP denomine fluxos de serviço, largura de banda é reservado somente se o fluxo de serviço tem uma taxa reservada mínima configurada.

Vantagens e desvantagem do planificador do em conformidade com DOCSIS

O objetivo do planificador do em conformidade com DOCSIS é minimizar o tremor para UG e RTP denomina fluxos de serviço e igualmente acomoda explosões do DOCSIS 1.0 do não-fragmentável. As trocas que o planificador do em conformidade com DOCSIS faz a fim conseguir estes objetivos são que o número máximo de fluxos de serviço UG apoiados por rio acima é menos do que a teórica máxima que um DOCSIS rio acima pode fisicamente apoiar, e que o tráfego de melhor esforço pode ser sujeito a um grau de fragmentação.

Quando o planificador do em conformidade com DOCSIS apoiar levemente menos do que a teórica máxima de número de fluxos de serviço simultâneos UG em um ascendente, e quando algumas outras aplicações de programa puderem apoiar mais fluxos de serviço UG por rio acima, você deve centrar-se sobre as trocas.

Por exemplo, nenhum planificador pode apoiar os fluxos de serviço jitterless UG que consomem perto de 100% a largura de banda de um canal upstream e apoiam simultaneamente grandes frames concatenados do não-fragmentável do Modems do DOCSIS 1.0. Com respeito ao projeto do planificador do em conformidade com DOCSIS há dois pontos importantes a compreender.

  • 75% é a utilização de upstream desejável máxima.

    Cisco encontrou que quando um ascendente é executado consistentemente na utilização maior de 75%, incluindo o valor de utilização aos fluxos de serviço UG, o desempenho do tráfego de melhor esforço começa obter visivelmente afetado. Isto significa que se os UG e a sinalização voip consomem mais de 75% do ascendente, todo o tráfego IP normal transportado por fluxos de serviço de melhor esforço começa a sofrer da latência adicionada que causa visivelmente o throughput mais baixo e o tempo de resposta. Esta degradação de desempenho a níveis de utilização mais altos é uma propriedade que a maioria de parte moderna dos sistemas da rede de multi-acesso, por exemplo, Ethernet ou Sem fio LAN.

  • Quando a largura de canal fluxo acima tipicamente distribuída de 3.2MHz é usada, o planificador do em conformidade com DOCSIS permite que os fluxos de serviço UG utilizem até aproximadamente 75% do canal upstream. Estes fluxos de serviço transportam chamadas VoIP de G.711.

Estes dois pontos dão alguma introspecção nas considerações de projeto que foram levadas em consideração quando o planificador do em conformidade com DOCSIS foi construído. O planificador do em conformidade com DOCSIS foi projetado de modo que para fluxos de serviço típicos UG (G.711) e com a largura do canal o mais geralmente distribuída de 3.2MHz, o atendimento por limites ascendentes começa aplicar-se ao redor da marca da utilização de 75%. Isto significa que o planificador minimiza com sucesso o tremor e igualmente permite um número razoável de fluxos de serviço UG no ascendente.

Ou seja o planificador do em conformidade com DOCSIS foi projetado operar-se corretamente em redes de DOCSIS da produção, e não permitir que os fluxos de serviço UG usem-se acima fantasiosamente de um alto percentual da largura de banda fluxo acima. Esta encenação pode ocorrer em uma encenação maquinada do teste de laboratório.

Você pode emenda o planificador do em conformidade com DOCSIS acomodar um número aumentado de UG chama por rio acima, embora ao detrimento do tremor UG e da eficiência do tráfego de melhor esforço. Para isto, você deve reduzir o parâmetro do default-phy-burst do cabo à configuração recomendada mínima de 1540 bytes. Se você exige uma densidade de chamadas mais adicional, ajuste o unfrag-entalhe-Jitter ascendente do cabo a um valor tal como 2000 microssegundos. Contudo, Cisco não recomenda estes ajustes geralmente para uma rede de produção.

Uma outra vantagem do planificador do em conformidade com DOCSIS é que não há nenhum requisito compulsório que os operadores CMTS configuram explicitamente o controle de admissão para UG e RTP denominam fluxos de serviço. Isto é porque, o método da programação da PRE-atribuição elimina a possibilidade de assinatura em excesso acidental. Mesmo que isto seja o caso Cisco ainda sugere que os operadores se assegurem de que utilização de upstream do total para não exceder 75% por períodos extendido durante horas de pico. Consequentemente, Cisco recomenda a configuração do controle de admissão como um melhor prática.

Um inconveniente do planificador do em conformidade com DOCSIS é que o de posição fixa de concessões UG pode exigir a fragmentação das melhores concessões do esforço quando a utilização de UGS é alta. Geralmente, a fragmentação não causa problemas de desempenho visíveis, mas condu-los a um leve aumento na latência para o tráfego de melhor esforço e a um aumento na carga adicional de protocolo atual no canal upstream.

Um outro inconveniente é que quando os Cable Modem DOCSIS 1.0 querem fazer grandes transmissões fluxo acima do não-fragmentável pode haver um atraso antes que uma diferença apropriada entre blocos de concessões pré-programados UG apareça. Isto pode igualmente conduzir à latência aumentada para o tráfego ascendente do DOCSIS 1.0 e a um uso menos-do que-ótimo do tempo de transmissão fluxo acima disponível.

Finalmente, o planificador do em conformidade com DOCSIS é projetado trabalhar melhor nos ambientes onde todos os fluxos de serviço UG compartilham do mesmo intervalo do tamanho concedido e da concessão. Isto é, onde todas as chamadas VoIP compartilham do mesmo codec, tal como 10ms ou 20ms o empacotamento G.711 que ocorreria em um sistema baseado de Packetcable 1.0 típicos. Quando os intervalos disparado de concessão e os tamanhos estam presente, a capacidade do planificador do em conformidade com DOCSIS apoiar um alto número de fluxos de serviço UG reduz-se em um ascendente. Além, muito uma quantidade pequena do tremor (menos do que 2ms) pode ocorrer para algumas concessões enquanto o planificador tenta intercalar fluxos de serviço UG com períodos e tamanhos diferentes.

Enquanto as redes dos multimédios do PacketCable (PCMM) se tornam mais predominantes pode tornar-se mais comum para uma variedade de codecs de VoIP com vários intervalos de pacotização para estar na operação simultânea. Este tipo de ambiente pode emprestar-se ao planificador do low latency queueing.

O planificador do low latency queueing

O planificador do low latency queueing (LLQ) foi introduzido no Cisco IOS Software Release 12.3(13a)BC. O LLQ é o método alternativo para programar serviços upstream em um uBR CMTS de Cisco. Este planificador foi projetado maximizar o número fluxos de serviço que do estilo UG e RTP um ascendente pode apoiar simultaneamente e igualmente aumentar a eficiência do tráfego de melhor esforço na presença dos fluxos de serviço UG. As trocas são o agendador LLQ não fazem nenhumas garantias com respeito ao tremor para fluxos de serviço UG e RTP.

Enquanto a seção do planificador do em conformidade com DOCSIS discute, o planificador do em conformidade com DOCSIS PRE-atribuem o tempo de transmissão adiantado para UG e os RTP denominam fluxos de serviço. Isto é similar à maneira que um sistema da multiplexação de divisão de tempo do legado (TDM) atribui a largura de banda a um serviço para garantir determinados níveis da latência e do tremor.

Em redes com base em pacotes modernas, o low latency queueing é o método que o Roteadores se usa para assegurar que os pacotes associados com os serviços prioritários, por exemplo Voz e vídeo, podem ser entregados em uma rede antes de outros pacotes da baixa prioridade. Este é igualmente o método que os roteadores de modem se usam para assegurar que a latência e o tremor estão minimizados para o tráfego importante.

O uso da palavra “garantia” para o sistema com base em TDM e “minimizou” para o sistema baseado em LLQ com relação ao tremor e à latência. Quando uma garantia para a latência e o tremor zero for desejável, as trocas são que tal sistema é geralmente inflexível, difícil de reconfigurar e geralmente incapaz de se adaptar facilmente às mudanças nas condições de rede.

Um sistema que minimize a latência e o tremor, um pouco do que fornecendo uma garantia restrita, pode fornecer a flexibilidade a fim aperfeiçoar-se continuamente face às mudanças nas condições de rede. O planificador do low latency queueing comporta-se em uma maneira similar ao sistema pacote-roteador-baseado LLQ. Em vez do sistemas pré-programados de atribuição para concessões UG, esta programações de sistema as concessões “o mais cedo possível” no ponto onde precisam de ser programados.

A aproximação que concede para fluxos de serviço UG deve ser atribuída o mais cedo possível mas não necessariamente com periodicidade perfeita, comércios deste sistema fora das garantias de tremulação restritas para a potencialidade de UGS aumentada e menos melhor fragmentação dos dados do esforço.

Configuração

Para Cisco IOS Software Release 12.3(13a)BC e Mais Recente, o agendador LLQ é um de dois algoritmos de agendador alternativo. Você pode permitir o LLQ para um, o toda a ou as algumas estes modos da programação:

  • UGS

  • RTPS

  • NRTPS

O agendador LLQ não é permitido à revelia. Você deve explicitamente girar o agendador LLQ sobre para os tipos de programação ascendentes exigidos. Use o tipo de programação ascendente da porta upstream do cabo [nrtps | rtps | comando cable interface do llq do modo do ugs].

Geralmente, você pode permitir o agendador LLQ para todos os modos listados da programação se este é o modo de programa desejado. Está aqui um exemplo de uma situação onde você queira permitir a programação LLQ para somente um tipo de modo da programação mas reter o planificador do em conformidade com DOCSIS para outro:

Os fluxos de serviço RTP não mandam nenhum requisito estrito para o tremor mas os fluxos de serviço UG fazer. Neste caso, você pode permitir o agendador LLQ para fluxos de serviço RTP, e retém o planificador do em conformidade com DOCSIS para UG.

Operação de agendador LLQ

O agendador LLQ trabalha da mesma forma como a função das filas de prioridade do planificador do em conformidade com DOCSIS com a adição de uma fila de latência baixa especial (LLQ), que tome a precedência sobre todas filas restantes.

O agendador LLQ começa um temporizador em nome de todos os fluxos de serviço ativos do estilo UG (e RTP). O temporizador é ajustado para apagar-se uma vez que cada da “intervalo concessão”. Sempre que o temporizador expira, uma concessão UG é enfileirada na fila LLQ. Enquanto esta concessão é colocada na fila LLQ que tem a prioridade máxima, a concessão é programada no próximo possível momento onde há o espaço livre.

Os diagramas nesta seção mostram um exemplo de um sistema com três fluxos de serviço ativos UG com o mesmo intervalo da concessão. Figura 27 mostra os temporizadores para os fluxos de serviço UG à esquerda, etiquetados UGS-1 com UGS-3. A seta amarela viaja em um sentido horário. Quando a seta do amarelo aponta para cima para o ponto vermelho, uma concessão UG está adicionada à fila LLQ. Você pode igualmente ver as oito filas de prioridade familiares 0 completamente a 7 e a uma fila nova LLQ que tome a prioridade sobre todo. Finalmente, à direita, é a linha de tempo da alocação de largura de banda que descreve como as concessões são programadas no ascendente. Para a claridade adicionada a linha de tempo da alocação de largura de banda inclui um ponteiro das “horas atual”. Este ponteiro move-se para a frente ao longo do período enquanto o exemplo continua.

Figura 27 – O sistema do low latency queueing

upstrm_sch_config_27.gif

O primeiro evento que ocorre é que o temporizador de UGS-1 no esquerdo superior expira. Uma concessão correspondente é enfileirada na fila LLQ. Ao mesmo tempo, uma melhor concessão do esforço chamada A com prioridade 2 é enfileirada.

Figura 28 – O Grant para UGS-1 e a prioridade 2 Grant A são enfileirados

/image/gif/paws/69704/upstrm_sch_config_28.gif

O agendador LLQ atribui agora o tempo de transmissão às concessões pendentes no ordem de prioridade. A primeira concessão para receber o tempo de transmissão é a concessão para UGS-1 que espera na fila LLQ. Grant A segue.

Figura 29 – Grant UGS-1 e Grant A são atribuídos tempo de transmissão

/image/gif/paws/69704/upstrm_sch_config_29.gif

O evento seguinte a ocorrer é que o temporizador de UGS-2 expira e faz com que uma concessão para que o fluxo de serviço de UGS-2 esteja enfileirado na fila LLQ. Ao mesmo tempo, uma concessão B da prioridade 0 é enfileirada e o C da concessão da prioridade 6 é enfileirado.

Figura 30 – O temporizador de UGS-2 expira. As concessões B e o C são enfileirados

/image/gif/paws/69704/upstrm_sch_config_30.gif

O agendador LLQ atribui mais uma vez o tempo de transmissão na ordem de prioridade da concessão, assim que significa que primeiramente o planificador atribui a hora à concessão para UGS-2, a seguir para o C da concessão, e finalmente para a concessão B.

Figura 31 – As concessões UGS-2, o C e B são atribuídos tempo de transmissão

/image/gif/paws/69704/upstrm_sch_config_31.gif

Supõe que nenhuma melhor concessão do esforço entra no planificador por um tempo. Os temporizadores UGS cada um expiram algumas vezes mais. Você pode agora ver o tipo do período com que o planificador atribui concessões aos fluxos de serviço UG. Parecem ser espaçados uniformemente. Supõe que quando as concessões aparecerem esta maneira com relação a se no período da alocação de largura de banda, não experimentam nenhum tremor significativo.

Figura 32 – UGS-1, UGS-2 e UGS-3 recebem um número de concessões. Grant D é enfileirado

/image/gif/paws/69704/upstrm_sch_config_32.gif

Figura 32 indica a posição ideal para a concessão seguinte de UGS-2. Se UGS-2 pode ter a concessão colocada neste ponto, UGS-2 não experimentará nenhum tremor para a concessão. Observe que há ainda uma hora para que a concessão seguinte de UGS-2 esteja enfileirada na fila LLQ.

Figura 32 igualmente indica que uma concessão muito grande D da prioridade 0 apenas entrou na fila da prioridade 0. A ação seguinte as tomadas do agendador LLQ é programar o tempo de transmissão para a concessão D.

Figura 33 indica esta encenação. Enrole o pulso de disparo para a frente um pouco ao ponto onde a concessão seguinte para UGS-2 é enfileirada.

Figura 33 – Grant D recebe o tempo de transmissão. Grant para UGS-2 é enfileirado

/image/gif/paws/69704/upstrm_sch_config_33.gif

Grant D parece ser programado no momento em que a concessão seguinte de UGS-2 deve ser programada para o tremor zero. Agora a pergunta é porque o agendador LLQ permite que a concessão D seja programada nesse ponto e não atrasa a concessão D até depois da concessão para UGS-2 ou porque D não é fragmentado. A resposta é que o agendador LLQ PRE-não atribui o tempo de transmissão para fluxos de serviço UG. Consequentemente, o agendador LLQ não está ciente adiantado onde as concessões UG serão colocadas na linha de tempo da alocação de largura de banda. O agendador LLQ não sabe sobre concessões UG até que estejam enfileirados na fila LLQ. Neste exemplo, antes que a concessão para UGS-2 obtiver na fila, a concessão D é programada já.

O agendador LLQ programa a concessão para UGS-2 na oportunidade disponível seguinte, mas esta concessão é atrasada levemente da posição ideal, que significa por definição que esta concessão particular experimenta algum tremor.

Figura 34 – Grant para UGS-2 é atrasado e as experiências tremem

/image/gif/paws/69704/upstrm_sch_config_34.gif

Quando o planificador do em conformidade com DOCSIS poderia ter evitado este tremor, o agendador LLQ evita um atraso ou uma fragmentação da concessão D às expensas somente de uma quantidade pequena de tremor. Um buffer do tremor em um ponto final de VoIP pode facilmente compensar este tremor.

A outra situação onde o tremor pode ocorrer está quando o temporizador LLQ para fluxos do serviço múltiplo expira ao mesmo tempo e concessão UG espera atrás de outras concessões UG enfileiradas dentro da fila LLQ. O agendador LLQ foi projetado minimizar a possibilidade desta ocorrência. O planificador espalha automaticamente para fora o tempo de expiração para os temporizadores do fluxo de serviço.

Conforme o planificador do em conformidade com DOCSIS, o agendador LLQ tem duas mais filas que os exemplos não mencionam. Estão aqui as filas:

  1. A primeira fila é usada para programar o tráfego de keepalive periódico da manutenção de estação a fim manter o Modems a cabo em linha. Esta fila é servida imediatamente depois da fila LLQ.

  2. O segundo é uma fila para as concessões atribuídas aos fluxos de serviço com uma taxa reservada mínima (fluxos de serviço CIR). Esta fila CIR é tratada enquanto uma “prioridade 8" fila a fim se assegurar de que os fluxos de serviço com uma taxa comprometida recebam sua taxa de transferência mínima exigida.

Controle de admissão

Ao contrário do planificador do em conformidade com DOCSIS, o agendador LLQ não usa um sistema da PRE-programação que pare a assinatura em excesso acidental de um ascendente com fluxos de serviço UG e RTP. Eis porque você deve explicitamente configurar o controle de admissão ascendente rio acima naquele usa o agendador LLQ. Esta configuração assegura-se de que a largura de banda fluxo acima total de fluxos de serviço UG não exceda limites sãos.

Cisco sugere geralmente que você não permita que a utilização de um canal upstream exceda 75% por períodos extendido durante períodos do pico de USO. Por exemplo, se o tráfego UG consome mais de 75% da largura de banda fluxo acima, os melhores dados do esforço começam sofrer dos problemas da latência excessiva e de desempenho da taxa de transferência de dados.

Naturalmente se um operador CMTS pode aceitar as consequências negativas para o tráfego de melhor esforço, você pode deixar os fluxos de serviço UG consumir mais altamente de 75% da largura de banda fluxo acima disponível. Contudo, você deve igualmente considerar o impacto no tráfego de gerenciamento da camada 2 no canal upstream. Você deve reservar a hora para a Mensagem da inicial e da manutenção de estação (Keepalives do modem a cabo). Se você não leva em conta este, e tráfego UG consomem perto de 100% da largura de banda, o Modems a cabo não pode vir em linha nem pode cair off line.

Está aqui um exemplo de configuração para o controle de admissão. Este exemplo restringe fluxos de serviço UG em um detalhe rio acima a 50% da largura de banda disponível do ascendente. Este formulário do comando igualmente transmite o SNMP traps a todas as estações de gerenciamento da rede configurada quando os pontos iniciais menores e principais da utilização de 30% e de 40% são alcançados. O comando é:

cabografe 50 pés UGS secundários do exclusive do major 40 do tipo de programação ascendente da nos-largura de banda do controle de admissão do rio acima-número 30

Veja a seção de controle de admissão sob a seção do planificador do em conformidade com DOCSIS deste documento para que como configure o controle de admissão.

saída do comando show

Emita o comando do rio acima-número do agendador de mac do número de interface do cabo de interface da mostra calibrar o status atual do agendador LLQ.

Está aqui um exemplo da saída deste comando. As partes do comando output de que seja diferente quando o planificador do em conformidade com DOCSIS é operacional está no texto em negrito:

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

Para uma explicação das linhas do texto simples nesta saída, veja a seção do show command output (resultado do comando show) para o planificador do em conformidade com DOCSIS.

Estão aqui as descrições para as linhas em negrito do show command output (resultado do comando show):

  • Enfileire o [LLQ Grants] 0/64, as gotas 0, 3 máximos

    Esta linha mostra o estado da fila LLQ, que controla concessões para os tipos do fluxo de serviço especificados no tipo de programação ascendente do cabo [nrtps | rtps | comando do llq do modo do ugs]. 0/64 indicam que há atualmente zero fora de um máximo de 64 concessões pendentes na fila.

    As gotas contrárias indicam que o número de vezes o planificador era incapaz de enfileirar uma concessão UG ou os RTP votam porque esta fila estava já completa (ou seja quando 64 concessões estão na fila). Se as gotas ocorrem nesta fila, a explicação mais provável é que o ascendente é oversubscribed com fluxos de serviço UG ou RTP e você deve aplicar um controle de admissão mais restrito.

    O contador máximo indica o número máximo de concessões que estão nesta fila desde que o comando do agendador de mac do cabo de interface da mostra era última corrida. Quando o presente, esta fila tiver a prioridade mais alta de todas as filas listadas.

  • r4k tiquetaqueia em 1ms 600000

    Este campo representa uma variável da cronometragem interna que os usos do agendador LLQ a fim se assegurar de que as concessões estejam colocadas na fila LLQ com precisão alta.

  • Eventos totais 5009 da programação

    Esta linha indica que o número de vezes que o agendador LLQ tenta enfileirar uma concessão desde que a última vez o comando do agendador de mac do cabo de interface da mostra foi executado para este rio acima. Este contador é restaurado cada vez que o comando show é executado.

  • Nenhuma busca foi precisada 5009

    Depois que as filas de agendador LLQ uma concessão, o agendador LLQ tentam restaurar o temporizador do fluxo de serviço para se preparar para a próxima vez que uma concessão está enfileirada. Se não há nenhum problema com uma restauração do temporizador, incrementos deste contador. Este contador deve idealmente ter o mesmo valor como o contador de eventos total da programação.

  • A entrada anterior livra 0, a entrada seguinte livre 0

    Nenhuns destes contadores incrementam nunca nas versões atual do Cisco IOS Software. Estes contadores permanecem sempre em zero.

  • Não podia programar 0, a recuperação falhou 0

    Esta linha indica que o número de vezes o agendador LLQ era incapaz de arranjar para o temporizador da concessão de um fluxo de serviço a ser ajustado corretamente. Isto deve somente ocorrer se o agendador LLQ segura extremamente um número grande de concessões com intervalos muito baixos da concessão. Estes contadores são altamente pouco suscetíveis de incrementar nunca em uma rede de produção. Um incremento destes contadores pode indicar que os fluxos de serviço UG e RTP consomem mais largura de banda do que está fisicamente disponível no ascendente. Nesta encenação, você precisa de executar comandos admission control apropriados.

  • Entrada 61 do tempo 1341 de Curr

    Esta linha mostra temporizadores internos para o agendador LLQ medido nos milissegundos. Quando a “entrada” alistada aqui iguala o campo da “entrada” alistado no por estatísticas de fluxo de serviço, uma concessão está enfileirada na fila LLQ.

Estas estatísticas são repetidas para cada fluxo de serviço que os punhos do agendador LLQ. Neste exemplo há três tais fluxos de serviço.

  • Entrada 188, escaninho 13

    Quando o valor da “entrada” é igual ao campo da “entrada” no item anterior, o temporizador para este fluxo de serviço expira e uma concessão entra na fila LLQ. Restaurações deste campo cada vez que o fluxo de serviço tem uma concessão enfileirada.

  • SID: 416

    O identificador de serviço (SID) para o fluxo de serviço cujas concessões o agendador LLQ programa.

  • IUC: 5

    O código de utilização do intervalo anunciado em uma mensagem do MAPA para as concessões que pertencem a este fluxo de serviço. Este é quase sempre 5 para “dados curtos”, 6 para “dados longos” ou 11 para “PHY avançado UG” quando um fluxo de serviço do estilo UG está no uso. Para RTP denomine o fluxo de serviço, este valor é sempre 1 para o “pedido”.

  • size_ms: size_byte 17: 232

    O tamanho da concessão nos minislots, seguido pelo tamanho da concessão nos bytes. Um minislot é a unidade a menor de transmissão fluxo acima em uma rede de DOCSIS e é geralmente equivalente a 8 ou 16 bytes.

  • Frag: N

    Indica se a concessão é fragmentable. Este valor é ajustado presentemente sempre ao N.

  • Inval: 20

    A concessão ou o intervalo de polling nos milissegundos.

  • tipo 8

    8 indicam este fluxo de serviço é UG, 10 indica que os RTP e 11 indicam o NRTPS.

  • referência perfeita 188 do tempo

    O tempo ideal em que esta concessão deve ter sido programada. Este é normalmente o mesmo como a “entrada” na parte superior. Se não, há uma indicação do congestionado pesadamente rio acima que precisa um controle de admissão mais restrito.

  • enviesamento da referência 0

    A diferença entre quando esta concessão for programada e quando a concessão idealmente dever ter sido programada. Esta é a diferença entre a “entrada” e “a referência perfeita do tempo”. Consequentemente, este valor deve normalmente ser zero.

  • prioridade 10

    Nas versões atual do Cisco IOS Software, este valor é ajustado sempre ao 10, mas podido variar no futuro.

  • posição 188, escaninho 13

    Estes campos devem ser os mesmos como a “entrada, escaninho” na parte superior desta lista.

Vantagens e desvantagem do agendador LLQ

O objetivo do agendador LLQ é aumentar UG e potencialidade de RTPS para os canais upstream, e aumentar a eficiência do tráfego de melhor esforço. As trocas que o agendador LLQ faz a fim conseguir estes objetivos são que este planificador não dá explicitamente garantias para tremor do fluxo de serviço UG e RTP. Um pouco, as concessões das programações UG do agendador LLQ e as votações RTP tão perto ao tempo ideal como possível com o propósito de minimizam o tremor.

O agendador LLQ pode igualmente segurar melhor fluxos de serviço múltiplos UG com intervalos e tamanhos concedidos diferentes da concessão do que o planificador do em conformidade com DOCSIS. Esta característica pode ser útil em um ambiente PCMM onde os tipos diferentes de chamadas VoIP e possivelmente outros aplicativos sejam todos servidos simultaneamente no um canal upstream.

O agendador LLQ programa o tráfego de melhor esforço mais eficientemente porque o agendador LLQ reduz a probabilidade da fragmentação das concessões. Quando as explosões do DOCSIS 1.0 do não-fragmentável são programadas, o agendador LLQ não cria diferenças da largura de banda não utilizada na frente das concessões UG ou as votações RTP como o planificador do em conformidade com DOCSIS fazem às vezes. Isto conduz melhor o uso do tempo ascendente disponível.

Embora o tremor UG seja geralmente mais alto quando você usar o agendador LLQ do que quando você usar o planificador do em conformidade com DOCSIS, no DOCSIS típico ou em redes PacketCable-baseadas, níveis do tremor do agendador LLQ está bem dentro da capacidade de tecnologia de buffer de tremulação de ponto final de VoIP. Isto significa que não há nenhum impacto visível na qualidade da chamada VoIP quando você usa o agendador LLQ em uma rede voip corretamente projetada.

Você pode limitar o tremor que elevara fora das grandes intermitências fluxo acima. Para isto, assegure-se de que você mantenha o parâmetro do default-phy-burst do cabo no valor padrão de 2000 bytes ou de menos. Se um sistema usa um canal upstream particularmente lento, diga com uns 800 kHz ou largura do canal menor, você pode conseguir umas reduções mais adicionais no tremor se você força grandes explosões para ser fragmentado nas menores com o comando do fragment-force do cabo rio acima.

Quando o agendador LLQ está no uso, você deve configurar o controle de admissão do cabo a fim impedir a possibilidade de assinatura em excesso do canal upstream. Uns fluxos de serviço mais ativos UG do que ascendentes podem fisicamente segurar, conduzem à qualidade de voz deficiente através de todos os fluxos de serviço UG no ascendente. Em casos extremos, isto igualmente significa que o Modems a cabo autônomo e novo da queda do Modems a cabo é incapaz de vir em linha. Cisco recomenda que os operadores CMTS configuram o controle de admissão tais que a utilização de upstream total em nenhuma porta upstream não está acima de 75% por períodos de tempo extendido.

Conclusões

As séries Cisco uBR de Produtos do DOCSIS CMTS fornecem dois algoritmos de escalonamento ascendentes da alternativa, e assim que podem cobrir uma variedade de condições de rede.

O planificador do em conformidade com DOCSIS, que é aperfeiçoado para o tremulação baixa, são seridos mais para sistemas de voz típicos de Packetcable 1.x com um codec uniforme de VoIP no lugar e onde níveis padrão da utilização do canal de upstream por fluxos de serviço UG é desejado.

O planificador do low latency queueing é projetado apoiar níveis alto-do que-normais da utilização de upstream por fluxos de serviço UG, pela eficiência aumentada do tráfego de melhor esforço, e pelos sistemas que usam fluxos de serviço UG e RTP com uma variedade de intervalos e tamanhos concedidos da concessão.

Apêndice A: Minislots

Um minislot é a unidade a menor de transmissão no DOCSIS rio acima. Quando um modem a cabo transmite uma requisição de largura de banda ao CMTS pedir o tempo de transmissão fluxo acima, o modem pergunta nas unidades de minislots um pouco do que nos bytes ou nos milissegundos. Além, quando uma mensagem do mapa de alocação de largura de banda informa o Modems de quando pode transmitir e durante quanto tempo, a mensagem contém a informação nas unidades de minislots.

O número máximo de minislots que um modem pode pedir transmitir em um estourado é 255. O tamanho de minislot é especificado nas unidades chamadas tiquetaques DOCSIS. Um tiquetaque DOCSIS é o equivalente de 6.25 microssegundos a tempo.

Para ajustar o tamanho de minislot nos tiquetaques para uma porta upstream, emita o tamanho de minislot ascendente [1 do <upstream-number> do cabo | 2 | 4 | 8 | 16 | 32 | 64 | comando cable interface 128].

Somente determinados tamanhos de minislot são permitidos com larguras de canal fluxo acima particulares. Esta tabela mostra tamanhos de minislot válidos contra larguras de canal fluxo acima DOCSIS, e igualmente mostra o comprimento em símbolos do esquema de modulação de um minislot com ajustes válidos.

Nota: Uma marca X significa uma combinação inválida.

  Largura do canal 200 kHz 400 kHz 800 kHz 1.6 megahertz 3.2 megahertz 6.4 megahertz
Tamanho de minislot nos tiquetaques              
1   X X X X X 32
2   X X X X 32 64
4   X X X 32 64 128
8   X X 32 64 128 256
16   X 32 64 128 256 X
32   32 64 128 256 X X
64   64 128 256 X X X
128   128 256 X X X X

Para calcular o número de bytes transmitido pelo minislot, multiplique os símbolos pelo minislot pelo número de bit pelo símbolo para o esquema de modulação configurado. Os esquemas de modulação diferentes transmitem números diferentes de bit pelo símbolo segundo as indicações desta tabela:

Esquemas de modulação do DOCSIS 1.1 TDMA Bit pelo símbolo
QPSK 2
16-QAM 4

Esquemas de modulação do DOCSIS 2.0 ATDMA Bit pelo símbolo
8-QAM 3
32-QAM 5
64-QAM 6

Por exemplo, com uma largura do canal 1.6 megahertz e um tamanho de minislot de 4 tiquetaques, você pode usar a primeira tabela para chegar em uma figura de 32 símbolos pelo minislot. Use a segunda tabela para converter esta figura em bytes, porque um símbolo QPSK contém 2 bit. Um minislot neste exemplo é equivalente a 32 símbolos pelo minislot * 2 bit pelo símbolo = 64 bit pelo minislot = 8 bytes pelo minislot.

Recorde que o número máximo de minislots que um modem a cabo pode pedir para transmitir é 255. Consequentemente, neste exemplo rio acima a explosão a maior nos bytes que um modem pode fazer é 255 minislots * 8 bytes pelo minislot = 2040 bytes.

Note que esta figura nos bytes é a correção de erros de encaminhamento do cargo e a figura da carga adicional de camada física do cargo. A correção de erros e a outra camada DOCSIS PHY aéreas adicionam sobre o 10 a 20 por cento ao comprimento de um frame da Ethernet enquanto passa através do canal upstream. Para derivar a figura precisa, use o perfil de modulação aplicado à porta upstream.

Esta discussão é significativa porque uma seção mais adiantada deste documento indica que um dos limites no tamanho de intermitência máxima de um modem a cabo é o valor configurado no comando cable default-phy-burst. Se o comando cable default-phy-burst é ajustado a 4000 bytes no contexto deste exemplo, o fator limitante ou o tamanho de intermitência são o limite do minislot 255 (menos bytes 2040 aéreo) um pouco do que o valor do default-phy-burst do cabo.

Você pode observar expressões diferentes do tamanho de minislot para um ascendente com o comando ascendente do rio acima-número do número de interface do cabo do controlador da mostra. Aqui está um exemplo:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

Cisco recomenda que você ajusta o tamanho de minislot tais que um minislot é equivalente a 16 bytes ou ao valor permissível o mais próximo. Um tamanho de minislot de 16 bytes dá a Modems a cabo a capacidade para gerar uma explosão do cargo FEC de até 255 * 16 = 4096 bytes.

Apêndice B: Avanço map

O CMTS gerencie periodicamente um mensagem especial chamado um mapa de alocação de largura de banda que informe o Modems a cabo de uma época precisa em que o Modems puder fazer transmissões no canal upstream. Os sinais bondes que transportam a mensagem do MAPA tomam uma quantidade de tempo finita para propagar fisicamente através da rede do co-axial da fibra híbrida (HFC) do CMTS a todos os Cable Modem conectado. Em consequência, a mensagem do MAPA precisa de ser transmitida cedo bastante para que o Modems receba a mensagem e possa fazer suas transmissões fluxo acima de modo que alcancem o CMTS no tempo designado.

O tempo do avanço map ou o tempo anticipar do MAPA representam a diferença entre o tempo em que o CMTS gerencie a mensagem do MAPA e o tempo em que a primeira transmissão pedida pelo MAPA precisa de ser recebida pelo CMTS. Esta vez representa uma combinação destes atrasos atuais em um sistema de DOCSIS:

  • O tempo a que o CMTS toma para construir a mensagem do MAPA no software e para que a mensagem seja enfileirada e processada pelos circuitos a jusante da transmissão. O valor deste componente é específico às Plataformas e às arquiteturas diferentes e é geralmente um valor fixo.

  • A latência que a função a jusante da intercalação adiciona, que é usada para que as finalidades da correção de erros de encaminhamento guardem contra o ruído de impulsos. Para mudar este valor, mude os parâmetros a jusante do Interleaver (organização de dados de forma não-contínua).

  • O tempo que os sinais bondes tomam para viajar para trás através da rede HFC do CMTS ao modem a cabo e então outra vez. O DOCSIS especifica um um-maneira-viagem-tempo máximo entre o CMTS e o modem a cabo de 800 microssegundos. Este valor varia segundo o comprimento físico da planta de cabos. O esquema da modulação downstream e a largura de canal fluxo acima e o esquema de modulação igualmente influenciam este valor.

  • O momento para que o modem a cabo processe uma mensagem recebida do MAPA e possam preparar-se para a transmissão fluxo acima. Este deve ser não mais de 200 microssegundos mais todo o atraso ascendente do Interleaver (organização de dados de forma não-contínua) conforme as diretrizes na especificação de DOCSIS. Na realidade esta vez pode realizar-se como microssegundos altos do AS300 ou como o baixo AS100 os microssegundos segundo fazem, modelo e revisão de firmware do modem a cabo.

Figura 35 – Componentes no tempo do avanço map

/image/gif/paws/69704/upstrm_sch_config_35.gif

O tempo do avanço map pode significativamente afetar a latência das transmissões fluxo acima porque este valor representa o retardo mínimo entre o tempo em que o CMTS sabe que um modem a cabo quer fazer uma transmissão e o tempo em que o modem é permitido fazer essa transmissão. Por este motivo, minimize o momento do avanço map de reduzir a latência ascendente.

Note isso no congestionado rio acima, outros fatores igualmente influenciam a latência ascendente. Por exemplo, atrasos que as causas do algoritmo da requisição de largura de banda do escritório e da nova tentativa, e o enfileiramento de concessões pendentes atrás de uma outras.

Figura 36 mostra o relacionamento entre um MAPA que o CMTS gerencie e os dados correspondentes passam recibo no ascendente.

Figura 36 – Relacionamento entre a geração do MAPA e o recibo de dados ascendentes

/image/gif/paws/69704/upstrm_sch_config_36.gif

Profundidade do Interleaver (organização de dados de forma não-contínua)

O primeiro fator no tempo do avanço map que pode variar é o Interleaver (organização de dados de forma não-contínua) a jusante como usado para a proteção do ruído de impulsos. Esta tabela mostra a latência adicionada às transmissões a jusante para a vários torneira do Interleaver (organização de dados de forma não-contínua) e ajustes do incremento do Interleaver (organização de dados de forma não-contínua):

Nota: Maior o tamanho da torneira, mais poderosa a correção de erros, mas igualmente maior é a latência induzida.

Mim (número de Taps) J (incremento) Latência 64-QAM 256-QAM da latência
8 16 220 segundo do ½ do ¿  ï 150 segundo do ½ do ¿  ïÂ
16 8 480 segundo do ½ do ¿  ï 330 segundo do ½ do ¿  ïÂ
32 4 980 segundo do ½ do ¿  ï 680 segundo do ½ do ¿  ïÂ
64 2 2000 segundos do ½ do ¿  ï 1400 segundo do ½ do ¿  ïÂ
128 1 4000 segundo do ½ do ¿  ï 2800 segundo do ½ do ¿  ïÂ
12 (EuroDOCSIS) 17 (EuroDOCSIS) 430 segundo do ½ do ¿  ï 320 segundo do ½ do ¿  ïÂ

Você pode ajustar os parâmetros do Interleaver (organização de dados de forma não-contínua) com a profundidade de interlace a jusante [8 do cabo | 16 | 32 | 64 | comando configuration da interface de cabo 128]

Nota: O valor para I (número de Taps) é especificado e um valor correspondente fixo para J (incremento) como visto na tabela aplica-se automaticamente. O modo também, porque EuroDOCSIS (anexo A) os parâmetros do Interleaver (organização de dados de forma não-contínua) é fixo em I = 12 e J = 17. O valor padrão para I é 32, que dá um valor padrão para J de 4.

Round Trip Time

O segundo fator que contribui ao avanço map o tempo que pode ser variado é o Round Trip Time bonde entre o CMTS e o Modems a cabo. A distância física entre o CMTS e o Modems a cabo e o retardo de processamento inerente no Modems a cabo influenciam este valor.

A especificação de DOCSIS encarrega-se de que o máximo - o um tempo de propagação permissível da maneira entre o CMTS e o modem a cabo o mais adicional no sistema seja não mais de 800 microssegundos. Isto implica um Round Trip Time, com exclusão do retardo de processamento do modem a cabo, de aproximadamente 1600 microssegundos.

A velocidade da luz em um vácuo é aproximadamente 186,000 milhas por segundo (de 300,000 quilômetros por segundo) e a velocidade de propagação para a fibra é citada tipicamente como 0.67. Consequentemente, o máximo - a uma distância permissível da maneira entre um CMTS e um modem a cabo é aproximadamente:

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

De acordo com a especificação de DOCSIS o retardo de processamento do modem a cabo não deve exceder 200 microssegundos mais nenhum atraso da intercalação de upstream. Contudo, em casos raros, alguns tipos mais velhos do modem a cabo podem tomar enquanto 300 microssegundos para processar uma mensagem do MAPA. Um Modems mais novo dos tipos de cabo com os CPU mais poderosos pode tomar como microssegundos pequenos do AS100 para processar uma mensagem do MAPA.

Supõe que o Modems a cabo é, em média, complacente com a especificação de DOCSIS. Consequentemente, o Round Trip Time máximo deve ser 1600 + 200 = 1800 microssegundos.

A maioria dos sistemas de cabo é muito mais curto de 100 milhas. Consequentemente não é ótimo para que um CMTS suponha sempre que o Round Trip Time bonde entre o CMTS e o modem a cabo o mais adicional é o valor máximo de 1800 microssegundos.

Para uma estimativa bruta para o Round Trip Time bonde previsto o maior, adicionar acima a distância da fibra entre o CMTS e o modem a cabo e multiplique-a em 16 microssegundos por milha (microssegundos 10 pelo quilômetro). Adicionar então acima a distância de todo o co-axial e multiplique esse valor em 12.4 microssegundos por milha (7.6 microssegundos pelo quilômetro). Adicionar então o retardo de processamento de 200 microssegundos.

Por exemplo, um segmento HFC com um total de 20 metros de filamento e de um um a milha de co-axial entre o CMTS e o modem a cabo o mais adicional podia esperar um retardo de round trip bonde de:

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

Esta figura não leva em consideração os atrasos do acréscimo devido às características e às variações do canal de upstream e downstream no tempo de processamento do modem. Consequentemente este valor não é apropriado para usar-se quando você calcula o tempo do avanço map.

Mais modo preciso determinar o Round Trip Time em um sistema é observar o “deslocamento de temporização” para o Modems a cabo como visto na saída do comando show cable modem. Como parte do processo de variação que o Modems a cabo se usa para manter uma comunicação com o CMTS, o CMTS calcula o Round Trip Time para cada modem a cabo. Este Round Trip Time aparece como o “deslocamento de temporização” na saída do comando show cable modem nas unidades de 1/10.24MHz = 97.7 nanossegundos chamados unidades do deslocamento de temporização ou do offset de intervalo. Para converter o deslocamento de temporização para um modem aos microssegundos, multiplique o valor por 25/256, ou divida muito aproximadamente o valor pelo 10.

Está aqui um exemplo em que os deslocamentos de temporização do vário Modems na saída do comando show cable modem são convertidos a um valor do microssegundo:

Nota: O valor do microssegundo aparece nos itálicos.

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

Neste caso, o modem o mais adicional afastado é eletricamente o último modem com um deslocamento de temporização de 6030. Isto iguala a um Round Trip Time de 6030 * 25/256 = 589 microssegundos.

Avanço do mapa de estática

Em um sistema onde você saiba que o comprimento da rede HFC é significativamente menos de 100 milhas, você pode configurar o CMTS para usar um Round Trip Time máximo que é menos do que o padrão 1800 microssegundos em que você calcula o tempo do avanço map.

Para forçar o CMTS para usar um valor feito sob encomenda para o Round Trip Time no cálculo do avanço map, emita o comando cable interface estático do MAX-redondo-viagem-tempo do avanço de mapa de cabo.

A escala para o MAX-redondo-viagem-tempo é 100 a 2000 microssegundos. Se nenhum valor é especificado para o MAX-redondo-viagem-tempo, o padrão de 1800 microssegundos aplica-se.

Nota: Você pode substituir a palavra-chave estática com a palavra-chave dinâmica. Veja a próxima seção.

Certifique-se de que o Round-trip-time especificado é certamente maior do que o grande CMTS ao Round Trip Time do modem a cabo no canal downstream. Se um modem a cabo tem um Round Trip Time maior do que aquele especificado no MAX-redondo-viagem-tempo, o modem pode encontrá-lo difícil ficar em linha. Isto é porque tal modem não tem o tempo suficiente responder a uma mensagem do MAPA e é consequentemente incapaz de comunicar-se com o CMTS.

Se o deslocamento de tempo de um modem a cabo, convertido aos microssegundos, excede o MAX-redondo-viagem-tempo especificado, o modem está identificado por meio da bandeira ruim do deslocamento de temporização. Esta bandeira do offset aparece como um ponto de exclamação (!) ao lado do deslocamento de temporização do modem a cabo na saída do comando show cable modem. Esta situação pode ocorrer se o parâmetro do MAX-redondo-viagem-tempo está ajustado demasiado baixo ou se o modem a cabo sofre de um problema onde seu deslocamento de temporização seja instável e aumenta constantemente ao longo do tempo.

Aqui está um exemplo:

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

Neste exemplo, o comando da estática 500 do avanço de mapa de cabo é especificado. Contudo, um do Modems a cabo conectado à interface de cabo tem um deslocamento de temporização de maior de 500 microssegundos (equivalente a 500 * 256/25 = 5120 unidades do deslocamento de temporização).

Note que o deslocamento de temporização do último modem a cabo está identificado por meio da bandeira ruim do deslocamento de temporização, “!”. Isto é fixado igualmente ao máximo permitido um valor de 5120 unidades mesmo que o deslocamento de temporização verdadeiro possa ser muito mais alto. Este modem a cabo pode ir off line e sofrer do desempenho ruim.

As sobras ruins da bandeira do deslocamento de temporização ajustam-se para o modem a cabo mesmo se o deslocamento de temporização cai abaixo do MAX-redondo-viagem-tempo. A única maneira de cancelar a bandeira é remover temporariamente o modem da lista do modem a cabo da mostra. Para isto, você pode usar o comando delete claro do endereço MAC do modem a cabo. Alternativamente, você pode restaurar a interface de cabo ou a porta upstream.

Para observar a operação do algoritmo do avanço do mapa de estática na pela base ascendente, emita o comando ascendente do rio acima-número do número de interface do cabo do controlador da mostra. Aqui está um exemplo:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

O campo (estático) do avanço map mostra uma estadia do avanço map de 3480 microssegundos. Se você muda as características a jusante do Interleaver (organização de dados de forma não-contínua) ou o parâmetro do MAX-redondo-viagem-tempo, a mudança está refletida no valor do avanço do mapa de estática.

Avanço de MAP dinâmico

O uso do cálculo do avanço do mapa de estática aperfeiçoar tempos do avanço map exige o operador CMTS determinar manualmente o Round Trip Time o maior em um segmento de cabo. Se rio abaixo ou as características do canal upstream mudam, ou se alguma condição de planta muda, o Round Trip Time máximo pode mudar significativamente. Pode ser difícil atualizar continuamente a configuração para acomodar a mudança em condições de sistema.

O algoritmo do Dynamic Map Advance resolve este problema. O algoritmo do Dynamic Map Advance fazem a varredura periodicamente da lista do modem a cabo da mostra para procurar automaticamente pelo modem com o deslocamento de temporização o maior do alcance inicial, e então os usos que avaliam para calcular o tempo do avanço map. Assim, o CMTS usa sempre o mais baixo tempo possível do avanço map.

O deslocamento de temporização do alcance inicial para um modem a cabo é o deslocamento de temporização esse os relatórios do modem no ponto aonde o modem vem em linha. Na maioria dos casos, isto é próximo ao deslocamento de temporização sobre indo como visto na saída do comando show cable modem. Contudo, o Modems de alguns tipos de cabo tem um problema aonde o deslocamento de temporização rasteje para cima ao longo do tempo aos valores muito grandes. Isto pode enviesar o cálculo do tempo do avanço map. Tão somente o deslocamento de temporização do alcance inicial, que é atualizado somente se um modem vem em linha, é usado. Para ver o deslocamento de temporização do alcance inicial e o deslocamento de temporização em curso para um modem a cabo, emita o comando show cable modem verbose. Aqui está um exemplo:

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

Neste exemplo, o deslocamento de tempo em curso (2566) é levemente mais alto do que o deslocamento de temporização do alcance inicial (2560). Estes valores podem diferir levemente. Contudo, se os valores diferem por mais do que algumas cem unidades, pode haver um problema com o controle do deslocamento de temporização do modem a cabo.

Para ativar o cálculo do Dynamic Map Advance, emita o comando cable interface do MAX-redondo-viagem-tempo do fator de segurança do Cable Map-Advance Dynamic.

O parâmetro do fator de segurança varia de 100 a 2000 microssegundos. Este parâmetro é adicionado ao tempo do avanço map para fornecer uma proteção pequena esclarecer todos os atrasos não-antecipados extra na propagação do sinal. O valor padrão é 1000 microssegundos. Contudo, para os sistemas de cabo estáveis que não se submetem a alterações significativas na planta de cabos ou dentro rio acima ou em características do canal downstream, use um valor mais baixo tal como 500 microssegundos.

O parâmetro do MAX-redondo-viagem-tempo varia de 100 a 2000 microssegundos. Este parâmetro é usado como um limite superior para os deslocamentos de tempo do Modems a cabo conectado ao segmento de cabo. O valor padrão é 1800 microssegundos. Se o deslocamento de tempo de um modem a cabo, convertido aos microssegundos, excede o MAX-redondo-viagem-tempo especificado, parece marcado com a bandeira ruim do deslocamento de temporização.

Ajuste o parâmetro do tempo da MAX-redondo-viagem não a um valor padrão quando você sabe que o comprimento do sistema de cabo é significativamente menos de 100 milhas, e se você conhece o que deve ser o offset de período normal máximo para o Modems a cabo conectado ao segmento.

Observe a operação do algoritmo do Dynamic Map Advance na pela base ascendente com o comando ascendente do rio acima-número do número de interface do cabo do controlador da mostra. Aqui está um exemplo:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

O valor de deslocamento de temporização de Tx mostra o deslocamento de temporização o maior para todo o Modems a cabo conectado ao ascendente em unidades do deslocamento de temporização. Use este valor para calcular o tempo do avanço map. O campo (dinâmico) do avanço map mostra o tempo resultante do avanço map. Este valor pode variar se o deslocamento de temporização de Tx muda, se o segurança-valor está alterado, ou se as características a jusante do Interleaver (organização de dados de forma não-contínua) estão mudadas.

O algoritmo do Dynamic Map Advance depende sobre se o Modems a cabo relata seu deslocamento de temporização do alcance inicial ao CMTS corretamente. Infelizmente, algum faz e modela do relatório do Modems a cabo os deslocamentos de temporização do alcance inicial como os valores que são significativamente mais baixos do que o valor verdadeiro. Você pode observar este quando o Modems mostra os deslocamentos de temporização que são próximos a zero ou mesmo a valores negativos.

Mensagens de Erro similares ao %UBR7200-4-BADTXOFFSET: O deslocamento de temporização ruim -2 detectado para o modem a cabo 00ff.0bad.caf3 pode aparecer em tal Modems a cabo. Este Modems dos tipos de cabo não relata seus deslocamentos de temporização em uma maneira do em conformidade com DOCSIS, o algoritmo do Dynamic Map Advance não pode corretamente calcular uma época do avanço map que seja garantida para dar cada tempo do modem a cabo para receber e responder PARA TRAÇAR mensagens.

Se tal Modems a cabo esta presente em um segmento de cabo, desabilite o algoritmo do Dynamic Map Advance e reverta ao algoritmo do avanço do mapa de estática. Refira porque faça algum Modems a cabo indicam um deslocamento de tempo negativo? para obter mais informações.


Informações Relacionadas


Document ID: 69704