Página 4 de 13 PrimeiroPrimeiro 123456789 ... ÚltimoÚltimo
+ Responder ao Tópico

  1. Citação Postado originalmente por ronanrojer Ver Post
    Colega quer saber da real , a única e básica coisa que suas regras fazem é dividir a banda do cliente x6 ou pela quantidade que estipular é apenas isto divisão de banda para que o cliente não estipule o download , não vejo muita diferença no burst que inclusive calcula uma média que por sinal acho mais viável.
    Novamente vou dizer, não compare suas regras com a das grandes operadoras que controlam cada byte que entra e que sai .
    Somente um recado a este rapaz chamado Jailton , se não tem capacidade para um debate técnico não fique dando reputação negativa somente pq discorda do que é postado , não sei como as coias funcionam por aqui , mas já percebi que não gostam de ser contrariados .
    Esta é minha última opinião aqui ..fui
    Primeiramente boa noite e seja bem vindo


    Em seu primeiro comentário no tópico já deu uma bola fora ao afirmar que se utiliza burst
    mas sou da paz,quando for hora ganhara estrelinha aprovando seu comentário ok


    Agora temos saber auditar e saber em que tipo de cenário se enquadra ,e por ventura assim como demostrado em toda explanação pelo andrio fazer as devidas mudanças.

    Já tenho um cenário e que estou estudando para utilização, aonde se tem dois períodos do dia em que aperta a questão da banda(gargalo)e mais banda com as operadoras esta complicado nesse interior de meu Deus, mas a topologia da rede e diferente do apresentado pelo Andrio.

  2. Citação Postado originalmente por 1929 Ver Post
    Não duvido da capacidade do Andrio, o mascaraajp, muitas dicas que ele me passou tenho usado até hoje. Inclusive sobre uma maneira prática de calcular o tempo de renovação do burst.

    Mas neste caso eu fico também sem ver um valor prático para o caso de um cliente que faz um só down. Ele se tiver um plano de 3 mega conforme o exemplo, irá baixar a 512k. Ele não se sentiria frustrado por atingir só 512k? Se eu entendi o que o Andrio deseja é que fique banda liberada para que ele continue a navegar dentro dos 3 mega.

    Mas no caso do burst, se for um só down, ele irá oscilar entre o ponto de corte do burst e o max burst. E o burst será renovado a cada tempo determinado. A sensação para o cliente é muito melhor, penso eu.
    Se ele fizer mais de um down, ele logicamente não irá ter picos de 3 mega para cada down, mas sim para a soma deles. Daí que os picos sempre haverá seja para um ou para 6 down.

    Com o uso do burst não tenho encontrado problemas de leitura nos reloginhos dos medidores. Todos eles fazem a leitura dentro do máximo que o plano permite, ou seja banda contratata+burst.

    Mas afinal, são políticas de gerenciamento e pode ser útil para muitos. Pode não agradar a outros, asim como não me agradou, mas sempre que é uma nova maneira de encarar o gerenciamento do tráfego.
    Se houvesse só uma maneira de configurar o mikrotik por ex. não haveria a necessidade de tantas opções.
    Qualquer hora vou tentar esta forma proposta para fazer uma comparação.
    Carlos,
    O Burst se bem configurado de fato pode oferecer uma velocidade maior para o Cliente de tempos em tempos.
    Ou, podemos configura-lo para somente para oferecer a velocidade inicial e depois reduzir até que se termine o download.
    O ruim do uso do Burst é que mesmo após ter terminado o download, o cliente não tem a banda dele renovada "imediatamente", sendo necessário aguardar um período de tempo.

    Mas o problema maior no Burst é que muita gente o utiliza para economizar banda... como? entregando para o cliente velocidade menores (Max-Limit) podendo atingir velocidades maiores (Burst Limit).
    No final, o cliente acaba sendo enganado.
    (*Sem contar o BUG que o Burst possui quando usado em servidores com muitos clientes)

    Como bem sabemos, com o uso do Burst ,quem somente navega sempre terá a velocidade maior.
    O Burst somente será cortado se o Cliente estiver fazendo um download.
    Logo, se o objetivo é controlar a banda do Cliente somente quando ele faz um download, então o Burst não é a melhor alternativa.
    Nesse caso, na minha opinião devemos utilizar essa regra que postei e adapta-la a gosto (podemos fazer inúmeras configurações).


    Vejamos um outro exemplo de adaptação...
    podemos utilizar Firewall+PCQ "Burst"
    E fazer com que todo trafego que tenha passado de 3mb baixado, entre na regra.
    Ao entrar na regra, O cliente que tinha 1Mega passa a ter 400k com Burst de 1M.

    Mas ai você questiona: há, mas isso o Burst já faz.
    E eu respondo: Sim, o Burst já faz isso, mas a diferença esta no controle do Firewall. Que fará o controle somente após ele ter baixado uma certa quantidade e fará com que o cliente retorne ao 1Mega que ele tinha antes IMEDIATAMENTE após o termino do Download, sem precisar aguardar um período de tempo.
    Sem contar algumas configurações adicionais que podemos fazer, como retirar alguns sites desejado desse controle, entre outras coisas.



  3. Andrio, vamos aprofundar esta questão e fazer um teste comparativo.

    Atualmente deixo o perfil na banda contratada e dou um burst de determinado tempo. Assim o cliente não poderá dizer que não está navegando na velocidade contratada. Uso o burst como um "plus".

    Um dos bugs seria aquele que você citou uma vêz, que ao associar novo usuário do simple queue o burst é renovado para todos, independente do tempo?

  4. Citação Postado originalmente por 1929 Ver Post
    Andrio, vamos aprofundar esta questão e fazer um teste comparativo.

    Atualmente deixo o perfil na banda contratada e dou um burst de determinado tempo. Assim o cliente não poderá dizer que não está navegando na velocidade contratada. Uso o burst como um "plus".

    Um dos bugs seria aquele que você citou uma vêz, que ao associar novo usuário do simple queue o burst é renovado para todos, independente do tempo?
    Na minha opinião, esse Plus é a real forma como deveríamos usar o Burst, pois estaremos sempre entregando o contratado para o cliente.

    Porem, alguns configuram a Velocidade do Cliente com velocidade inferior e um Burst da velocidade contratado.
    E como o Burst não faz distinção entre download ou navegação, a partir do momento que o Burst atingir o Ponto de Corte o cliente ficará por um certo período com velocidade inferior.
    Exemplo:
    Plano configurado com 500k e e Burst de 1M.
    Durante a navegação, o cliente terá 1M.
    A partir do momento que ele fizer um download, ou assistir um vídeo ou mesmo uma atualização (não importa o que seja, desde que seja trafego continuo), esse trafego irá atingir o Ponto de Corte do Burst e a velocidade do cliente será reduzido para 500k.
    Com isso, o cliente terá 500k para dividir entre navegação e download.

    Por outro lado, utilizando essas regras que citei, o Cliente SEMPRE vai poder atingir a velocidade contratada.
    A regra somente irá controlar a velocidade do download (ou qualquer outro com trafego continuo).
    Pois esse controle somente é ativado depois que o cliente tenha baixado 3Mega (ou outra quantidade configurada).

    PS: sim, o bug do Burst na qual me referi é a renovação imediata do Burst para todos sempre que um cliente conecta/desconecta ou alguma regra (Queue) muda de lugar.
    Em bem sabemos que quem tem autenticação centralizada, tem bastante conexão e desconexão.

  5. Como vc faz para que estas regras só contem o que está fora do cache ?
    Vc sabe quantos donwloads são feitos quando o facebook está aberto ? pois cada aplicativo do mesmo é reconhecido separadamente e então a meu entender serão somados vários downloads .
    1 - Basta adicionar uma outra Regra acima dessas marcando o que vem do cache.
    2 - Não faço ideia do tamanho dos aplicativos do Facebook, mas somente irá entrar no controle se ultrapassar 3mb de download.
    Alem do mais, nunca vi um aplicativo depois de aberto consumir muita banda!!!






Visite: BR-Linux ·  VivaOLinux ·  Dicas-L