Mas ainda ninguem comentou quantos % de garantia de banda q cada um está oferecendo.
Caso não queira q ninguem veja, me mande por mensagem privada q as minhas são bloqueadas.
Isso varia muito por região.
Na minha região por exemplo tem os q não desligam o pc pra nada, em horario comercial fico com certa de 35% dos clientes conectados, no horario de almoço q é quando alguns chegam do colegio passa dos 50% conectados e no horario das 20:00 às 22:00 muitas das vezes passa dos 60% dos clientes conectados.
Vc tá tendo é sorte mesmo, olha q tenho um bom servidor, o cache full q hoje varia entre 10% a 15% da navegação, ou dependendo do mês passa dos 20% da navegação.
Aqui só vendo 128K e 256K e tenho um link de 2mb full corporativo e outro 2mb 50% diamante.
Constatemente tenho clientes navegando a 2.8mb, 3.4mb e algumas vezes 5.8mb. Mas o meu recorde foi um q é ligado direto na RB q distribui local. A qual a mesma recebe sinal outra RB q uso só para fazer Ponto a Ponto do Escritorio para a torre, para jogar sinal para outra cidade e para ligar via cabo na Rb de distribuição local.
O cliente chegou a navegar a 24mb (do cache).
Última edição por NetoGO23; 31-03-2009 às 18:08.
Seguinte "Fiote"
passa a analizar os gráficos de seu link no mikrotik.
por instindo vc saberá a hora certa.
não se esqueça de observar o uso de seus links nos chamados "horários de pico"
no meu caso entre as 18:00 e 23:00 da noite...
mais o que define mesmo é o gráfico de seus links....
Aquele Abraço....
Entedi tudo direitinho, porém, tem um fator intrigante que vai me tirar o sono...
oras.... tem que ter uma explicação vc com seu link de 3MB e ter tanta banda sendo utilizada.
Pergunto:
Quantos clientes estão conectados?
quais são os acessos?
Quais são as velocidades fornecidas?
se estão usando o ARES emule, Rapidshare... (cada caso tem um tratamento especifico)
Vale lembrar tbm que tem "aqueles" usuários que ficam o dia todo com o Rapidshare aberto baixando filmes seriados, etc (filme maniacos). destruidores de link.
E informe por favor.
Talvez vc consegue contornar este pico de link não e não perdendo a performance de seus usuários.
que é o meu caso, dá uma olhada nos print aki.
adicione meu msn.
pra gente poder conversar direito.
Abraço...
Ola amigo!
gostei dessa dica. como vc pode me dizer como se faz esta configuração. colocar na segunda aba do Queues do Mikrotik... como vc fala acima.
eu uso hotspót com mac+login+senha. webproxy de 33giga fico 15 dias sem limpar e sem rebootar.
meu mk é 2.9.27. da pra vc passar como se configurar isso. garantia de banda naQueues do Mikrotik. fico agradecido.
1929,
você põe CIR de quanto?
Essa regra que postei é apropriada para quem usa DHCP, IP fixo e PPPoE (amarrando usuário + MAC + IP).
No hotspot muda por causa do perfil criado. Nesse caso crie o perfil e a garantia de banda desse perfil que dará aos clientes. Geralmente banda larga a garantia é entre 10 e 30%, independentemente do tamanho da operadora/provedor.
Marcelo,
Eu ainda não assimilei bem o conceito da prioridade e Cir, apesar de saber para que servem.
Gostaria de saber como eles agem.
Para um plano de 256k dei um cir de 64k.
Mas o resultado será o mesmo, né?
Dando um CIR de 64 e prioridade 8, vai impedir que poucos usuários absorvam toda a banda disponível?
E fiz o cálculo de lotação de link, 1024/64= 16. Significa isso que um link de 1mega vai suportar 16 online, se todos estiverem fazendo downloads?
Pois a idéia do CIR é dar a garantia mínima.
É isso?
Eu uso HotsPot e faço assim:
100k/190k 128k/256k 90k/150k 120/120
100k/110k 100k/150k 90k/100k 120/120
Na verdade paguei pra configurar pra mim e foi assim q deixaram.
Neto,
o único problema nessas suas configurações é que a garantia de banda que você está fornecendo aos clientes é muito alta: mais de 50% na primeira linha e quase 100% na segunda linha. Vai estourar o seu link assim. Garanta entre 10% e 30%. De preferência 20%. Entretanto, se poucos estiverem navegando vão conseguir 100% (ou perto disso). Caso muitos estejam conectados ao mesmo tempo navegarão com velocidades reduzidas, mas navegarão. E à medida que a banda for ficando livre outra vez as velocidades dos conectados irão aumentando.
Eu não entendo bem mas o que vc está falando acho q é os 120/120 q está no final
100k(UP)/190k(DOW depois dos 120 segundos) 128k(UP)/256k(DOW antes dos 120 segundos) 90k/150k(isso aqui q não sei o q é) 120/120(contagem de tempo para baixar a velocidade pra 100k UP e 190k Dow)
Eu não li direito o seu perfil e confundi.
Voce tem o tempo, o que não tem é a prioridade e o CIR>
Mas basicamente é assim:
1º bloco -> é a taxa de upload e de download . No seu caso 100k/190k
2º bloco -> é o burst ou rajada. NO seu caso 128k/256k
3º bloco -> é o burst threshold ou o ponto de inflexão onde termina o burst. No seu caso 90k/150k
4º bloco -> é o tempo usado para o algorrítmo. No seu caso 120/120
Ainda tem outras opções;
5º bloco -> é a prioridade. No meu caso deixei em 8
6º bloco -> é o CIR ou garantia de banda. No meu caso deixei em 64k/64k
Mas uma coisa que eu não entendia é quanto ao tempo. Eu pensava que o burst durava todo o tempo determinado no perfil, mas relendo o manual do mk vi que não. Este tempo é usado para calcular o busrt.
por ex:
Maximo limit=256k
burst time= 8segundos
Burst threshold=192k
Burst limit=512k
Daí voce vai montar o perfil assim.
128k/256k 256k/512k 64k/192k 8/8
E pode acrescentar no final 8 para prioridade e 64k/64k para a garantia de banda. Sendo que esta garantia só existirá na prática se você não estiver com o link sobrecarregado.
Considerando só o download, mas o cálculo é o mesmo para o upload.
Você irá dar um burst limit de 512 (segundo bloco). Vai ser calculada a taxa média de consumo da banda durante o tempo determinado, no exemplo 8 segundos.
- no 1º segundo a taxa média é 512/8= 64k
- no 2º segundo a taxa media será 512+512=1024/8= 128k
- no 3º segundo a taxa média será 512+512+512=1536/8=192k
Quando atingir os 192K ele vai cortar o burst e trazer o limite para o que está estabelecido no 1º bloco ou seja 256k. Assim, o burst não vai durar todos os 8 segundos, mas sim o tempo que levar para chegar na média estabelecida no burst threshold, até o máximo de 8 segundos.
É por isso que o Marcelo disse, que estes valores não devem ser mais que 20 a 30%.
Vamos ao teu caso agora:
100k/190k 128k/256k 90k/150k 120/120
1º segundo -> 256/120=2,13k
2º segundo : 256+256=512/120=4,26k
3º segundo : 256+256+256=768/120=6,4k
4º segundo : 256*4=1024/120=8,53k
5º segundo ; 256*5= 1280/120=10,66k
6º segundo : 256*61536/120= 12,8
e por aí vai repetindo os cálculos até atingir o valor do burst threshold que é 150k
Qual é o problema de ter um tempo tão alto assim, como 120 segundos? é que o cliente vai ocupar a banda durante este tempo numa velocidade maior do que o contratado, no seu exemplo 190k
O burst, a meu ver só é vantajoso para abrir páginas mais rápido, pois são pequenas e logo desocupam a banda. Por isso o nome burst ou rajada.
Mas se o cliente for fazer download, este tempo de 120segundos pode ser muito para ele congestionar a banda.
E seria interessante tu colocar lá também a prioridade e o CIR.
É isso que eu entendi deste uso. Os mais conhecedores podem confirmar se está certo o meu raciocínio ou não.
Agora entendi!
Mas teria como vc me passar as regras exatamente do jeito q tenho q colocar em cada perfil?
É pq não entendo praticamente nada de mk e fico com medo de dar algum problema.
Outra coisa, onde posso arrumar um manual no modo "Avançado" de mk pq tenho q fazer um ponto a ponto e pensei q erá só copiar as regras dos outros 2 q já estão pronto mas não deu certo.
Obrigado.
Amigo aconselho você estudar a fundo neste caso o HTB (nada de HTB-Tools), ele dará a você uma boa noção das classes hierarquias que ja vem por padrão no mk (no caso a classe pai eth0), e as classes que você irá desenvolver para seu controle em particular. Procure por imagens sobre o esquema do HTB no Google. Juntando as imagens e explicações, verá que também existem diversos algoritmos de descartes de pacotes red,sfq,pfifo,pfifo-fast, etc. Logo poderá ver qual se encaixa melhor para sua aplicação.
http://linux-ip.net/traffic-control/htb-class.png
https://www.mideiros.net/doc/system/...htb-borrow.png
http://www.opalsoft.net/qos/ds-lb-284.gif
As principais explicacoes sobre burst, CIR, priority, etc os amigos já deram para você.
Analisando esses conceitos verá que o mk é uma "mãe" em controle de banda. E terá conhecimento suficiente para saber a diferença de se colocar uma regra na Queue Tree ou na Simple Queue.
Já no ptp você poderá fazer colocando um mk em bridge(apenas 1 cliente) ou ap-bridge(varios clientes)(default forward=no default autentication=no), colocar o mac do outro mk na access list. No outro mk você deixa mode=station ou station-wds, verifica se os dois estão na mesma band, ai é só dar um scan e conectar.
No caso do wds basta adicionar uma bridge e setar ela na interface ap-bridge, wds dynamic. Do outro lado a mesma coisa, cria-se uma nova bridge, coloca-se ela na interface station-wds(guia wds, também wds-mode dynamic) e conectar.
Aqui utilizo assim sem problemas.
Espero ter ajudado.
Abs!
Última edição por darklinux3; 01-05-2009 às 14:36.
Este é um perfil clássico para um plano de 128k de upload e 256k de download
128k/256k 256k/512k 64k/192k 8/8
Partindo dele, depois que você entender o conceito usado no algorrítmo voce vai criando outros perfis que melhor se adaptem a sua necessidade.
No WIKI do Under tem alguns tutoriais, e tem alguns tópicos também que ajudam.
Agora uma coisa que me chamou a atenção foi o comentário do Darklinux3.
Quando se cria estes perfis no hotspot ele automaticamente escreve no Queues. No queues type do meu mk, tem lá todos estes algorritmos red,sfq,fifo,pfifo. Na verdade eu não sei o que eles fazem, o fifo e pfifo eu posso imaginar por analogia destes termos num controle de estoque comercial por exemplo.
Como eu também sou crú no mk, muita coisa fiz porque alguém me deu uma receita de bolo. E na ansia de fazer este trem andar, não me detive na época em saber o porquê das coisas.
Mas a medida que a poeira começa a baixar vou ter que ler nos links que voce postou para entender melhor.
Já que surgiu a duvida, pra ficar mais facil vou expor um pedacinho do meu trabalho de conclusao de curso, onde explica como funcionam as coisas no linux :
De acordo com (Hubert, 2003), todo o controle de trafego de rede nos sistemas Unix, é realizado quando regras de enfileiramento (qdisc) juntamente com filtros (classificadores) são atribuidas ao buffer de liberação de dados das interfaces de rede.
As regras de enfileiramento por sua vez possibilitam o controle do tráfego através do atraso ou descarte dos pacotes de rede, consequentemente obrigando as interfaces reenviarem a informação, atrasando a taxa de transferência.
Existem dois tipos de regras de enfileiramento:
- ClassFull – Utiliza diversas classes, utiliza varios tratamento, para o trafego de rede. As regras de enfileiramento do tipo ClassFull são : CBQ, HTB, PRIO.
- ClassLess – Não utiliza classe. Torna-se viável quando necessita-se ter o mesmo tratamento para todo o tráfego. Dispensa-se a necessidade do uso de classes para esta finalidade. As regras de enfileiramento ClassLess, normalmente não são utilizadas como regra principal da interface de rede, mas estão internas as classes de uma regra de enfileiramento ClassFull. As regras do tipo ClassLess são : PFIFO, PFIFO Fast, SFQ, TBF, RED, GRED, DSMARK.
PFIFO (Packet First-In First-Out) – É a regra de enfileiramento mais simples pois segue o conceito de “filas”, o primeiro pacote que entra é o primeiro que sái.
PFIFO Fast (Packet First-In First-Out Fast) – É similar a regra de enfileiramento PFIFO, esta regra utiliza prioridade de acordo com o campo TOS dos pacotes de rede. Esta classe é atribuida por padrão durante o boot para todas as interfaces de um sistema unix.
Token Bucket Filter (TBF)– É uma regra que permite somente a passagem de pacotes que chegam até uma determinada taxa de tranferencia, não excedendo qualquer taxa de transferencia administrativa setada, mas pode permitir que curtas rajadas excedam o limite. Devido a isso TBF é muito preciso e trabalha amigavelmente na rede.
A implementação do TBF consiste em um buffer (bucket), o qual está sempre sendo preenchido por pequenos pedaços virtuais de informação chamado tokens. Cada token que chega recolhe um pacote de dados de uma fila de dados e é repassado a rede, em seguida é deletado do bucket. O mais importante atributo do bucket é o seu tamanho, que é a quantidade de tokens que ele pode armzenar.
Stochastic Fairness Queueing (SFQ) – Esta regra foi projetada para garantir que cada fluxo de pacotes tenha um acesso "justo" aos recursos da rede, evitando que um fluxo "mal-comportado" consuma mais do que a sua quota de largura de banda.
Os pacotes são classificados através de endereço de origem, porta de origem, e endereço de destino e colocados cada um em uma fila (FIFO) dedicada a esse fluxo. Esta classificação associa um codigo hash a cada enderecamento que chega, e a cada fila, fazendo com que cada tráfego seja direcionado para uma unica fila. Caso o número de tráfegos seja maior do que o número de filas, o codigo hash será repetido, fazendo com que cada fila controle um ou mais tráfegos. As filas são servidas uma por vez, por um algoritmo round-robin. É um metodo menos rigoroso do que outros, porém exige menos cálculos (Brown, 2006).
Random Early Detection (RED) – Devido aos principais problemas do FIFO DropTail, como o fenomeno do full-queues e lock-off (starvation).
Projetado com o objetivo de fornecer o mais rapidamente possível uma resposta a fluxos que implementem controle de congestionamento (tais como o TCP) antes que a fila encha, indicando assim que o congestionamento da rede é eminente, em vez de esperar que este se torne excessivo.
O descarte de pacotes é também distribuído de forma mais equilibrada entre todos os fluxos.
Este efeito é obtido controlando o tamanho médio da fila de espera no roteador, este é comparado a dois limiares (threshold), um mínimo e um máximo.
Quando o tamanho médio da fila é inferior ao limiar mínimo, nenhum pacote é descartado. Já se este tamanho for superior ao limiar máximo, todos os pacotes que chegam sofrem descarte baseado na probabilidade máxima indicada.
Pacotes com tamanho entre o limiar mínimo e máximo, são descartados relativamente a uma probabilidade menor que a indicada, baseada em uma função que considera o tamanho médio da fila.
Essas sao as principais da qdiscs Class less, no mikrotik é utilizado o sistema de qdiscs Class Full (HTB), que possibilita o uso de todas as qdiscs class less no seu interior, em um esquema hierarquico.
É isso aí, espero ter ajudado.
Abs!
Última edição por darklinux3; 02-05-2009 às 03:06.