Queues dinamicos do HotSpot

[godoy]

Ola amigos do under, estou com um problema que a muito tempo estou pesquisando mais ainda não encontrei solução.


O caso é o seguinte:


Possuo um concentrador HotSpot onde através de Radius faço a autenticação dos meus clientes e é criado os Queues dinamicamente.
Todos os meus clientes possuem Burst configurado com o dobro da velocidade durante 20 segundos, e antes que haja indagações, todos os calculos do Burts foram feitos, refeitos, testados, retestados, o problema não é relacionado ao burst e sim o que se reporta abaixo.


O que ocorre, é que após de esgotarmos inumeros teste descobrimos a seguinte situação:


os clientes estão consumindo banda normalmente, tudo no seu devido lugar (quem tem direito a burst utiliza e quem já passou a media de corte volta para o Max Limit), tudo perfeito até um próximo cliente se logar e gerar um novo queues dinâmico que por sua vez entra no inicio da fila de queues (por padrão do mikrotik) reorganizando todos os demais uma posição para baixo e quando isso acontece o burst reabre para todos os meus clientes (sejam dinamicos ou estaticos), independente se ja cortou o burst, ou se estava no inicio, como se mikrotik resetase todas os registro dos queues já existente.


Fiz o teste de inserir um queues estático, mas o problema não ocorre, pois ele é inserido no final da lista de queues, assim não reorganizando a lista que queues.


Resumo: Através de todos os testes feitos, acredito que o problema esteja no fato de reorganizar a tabela de queues. A grande jogada é saber como posso fazer os novos queues dinâmicos ao invés de serem criados no inicio da lista de queues (que consequentemente a reorganiza), serem criados ao final da lista (como os estáticos).


Alguém tem alguma idéia de como fazer isso (acredito que no nosso mundo nada é impossivel), até e-mail enviamos para o suporte da mikrotik, mas eles fizeram pouco caso, disseram que não era possivel, gostaria até de se encontrar a solução enviar um e-mail mostrando o contrário.


Abraços.


Rodrigo Godoy

[AndrioPJ]

um simples disable e enable ja reorganiza a tabela.

apenas uma correção:
os clientes estão consumindo banda normalmente, tudo no seu devido lugar, quem tem direito a burst utiliza e quem já passou a media de corte volta para o Max Limit, apos um certo periodo o Burst é renovado e o cliente volta a ter direito a Burst (igual montanha russa)
''''''''''''''Burst''''''''''''''............Max Limit............''''''''''''''Burst''''''''''''''............Max Limit............

[1929]

Eu entendo exatamente como o Andrio, o burst se renova a cada ciclo de tempo.

Mesmo que não entre nenhuma conexão nova para reorganizar a lista do queues, o burst é renovado.
Pelo menos é isso que eu observo.
E não seria prático o burst não ser renovado. Senão, o que é para agilizar a navegação só ocorreria uma vêz e se por uma hora não conectasse ninguém novo, o benefício do burst não estaria presente.

Todos os tutoriais que apresentam o recurso do burst não são claros quanto ao tempo do burst.
Quando voce coloca lá 60 segundos, não quer dizer que vai durar 60 segundos. Este tempo serve para calcular o ponto de corte do burst e o tempo de renovação.
O Andrio andou algum tempo atrás postando umas contas mais práticas para calcular o ponto de corte e o tempo de renovação.
Coloca aí de novo Andrio. Por este método de cálculo você poderá ter uma renovação do burst a ciclos bem longos, bastando aumentar o tempo. Mas com certeza ele irá ser renovado independentemente de entrar nova conexão ou não. Tudo regulado pelo 'burst time'. Esta expressão não me parece definir corretamente o que acontece, deveria ser 'burst renew'.
Talvêz seja aí a confusão.
Me perdoe caso eu não tenha entendido o que acontece no seu servidor.

[godoy]

Ola amigos, obrigado pelas respostas. Mas como eu postei anteriormente, o problema não esta no burst.


Meu problema não é o burst dos cliente renovar após um ciclo de tempo, isso já previmos, calculamos, recalculamos, fizemos diversos laboratórios para teste e tudo mais o que podem imaginar.


Meu problema é que quando um cliente loga pelo HotSpot gera um novo queues dinâmico no inicio da tabela de queues, e exatamente neste momento o burst é renovado para todos os meus clientes sem exeção, meu servidor é um concentrador e chega a 700 clientes simultâneos, imagine o burst reabrindo para todos os 700 clientes junto (por esse motivo não acredito em um problema de configuração do burst e nem em coincidencias).


Também tenho ciencia dos campos de configuração do burst, meus clientes possuem 20 segundos de burst (não disse que o "burst time" tem o valor de 20). observem o diagrama abaixo, acho que posso explicar melhor







Observem que cada cliente possuem uma situação diferente um do outro e que no momento X todos reabrem os 20 segundos burst.


Amigos, estou muito agradecido da colaboração de vocês e espero ter explicado melhor meu caso.


Obrigado

[1929]

E o que acontece com o processamento neste momento? Vai para as alturas?
Ficam usuários travados até abrir espaço para eles?

É isso que está prejudicando?
Eu não tenho tantos usuários e talvêz por isso não tenha detectado o fato. No visual observando os usuários ativos não deu para perceber se acontece o mesmo aqui, ou se isso estaria prejudicando.
Mas vou tentar observar melhor.

[AndrioPJ]

hum, agora entendi aonde voce queria chegar
realizei um teste aqui, configurei para min: 1M max limit, 3M burst Limit.
32s de burst e 96s sem burst, totalizando 128s no burst time.

realmente, sempre que a tabela é renovada, o burst tbm é renovado.
independente se um cliente esta entrando, saindo, se foi ativado ou desativado uma queue.
agora, se isso é bug, eu acho que nao.
mas que pode ser um problema, isso pode.

segue um print do meu teste...
deixei um tempo com burst, um tempo sem burst
quando reiniciou novamente, deixei ter o burst e quando era para ser limitado novamente, eu ativei e desativei uma OUTRA regra no queue, fazendo com que a tabela renovasse... e com isso meu burst foi renovado:

Ola amigos, obrigado pelas respostas. Mas como eu postei anteriormente, o problema não esta no burst.


Meu problema não é o burst dos cliente renovar após um ciclo de tempo, isso já previmos, calculamos, recalculamos, fizemos diversos laboratórios para teste e tudo mais o que podem imaginar.


Meu problema é que quando um cliente loga pelo HotSpot gera um novo queues dinâmico no inicio da tabela de queues, e exatamente neste momento o burst é renovado para todos os meus clientes sem exeção, meu servidor é um concentrador e chega a 700 clientes simultâneos, imagine o burst reabrindo para todos os 700 clientes junto (por esse motivo não acredito em um problema de configuração do burst e nem em coincidencias).


Também tenho ciencia dos campos de configuração do burst, meus clientes possuem 20 segundos de burst (não disse que o "burst time" tem o valor de 20). observem o diagrama abaixo, acho que posso explicar melhor







Observem que cada cliente possuem uma situação diferente um do outro e que no momento X todos reabrem os 20 segundos burst.


Amigos, estou muito agradecido da colaboração de vocês e espero ter explicado melhor meu caso.


Obrigado

[godoy]

E o que acontece com o processamento neste momento? Vai para as alturas?
Ficam usuários travados até abrir espaço para eles?

É isso que está prejudicando?
Eu não tenho tantos usuários e talvêz por isso não tenha detectado o fato. No visual observando os usuários ativos não deu para perceber se acontece o mesmo aqui, ou se isso estaria prejudicando.
Mas vou tentar observar melhor.

O Processamento da um pico mais alto, mas bem rapido, não chega a estourar 100% de CPU. Os usuários não travam aguardando espaço.


O meu problema é que como tenho muitos clientes logando constantemente, o que faz com que ao invés do burst ter seu andamento normal (renovando após um ciclo de tempo), ele fica praticamente renovando o tempo todo, pois praticamente todo minuto tem um cliente novo que loga, fazendo assim que meus clientes utilizem o burst muito mais tempo do que deveriam.


Acredito que você tenha entendido agora.


Obrigado


Rodrigo Godoy

[godoy]

hum, agora entendi aonde voce queria chegar
realizei um teste aqui, configurei para min: 1M max limit, 3M burst Limit.
32s de burst e 96s sem burst, totalizando 128s no burst time.

realmente, sempre que a tabela é renovada, o burst tbm é renovado.
independente se um cliente esta entrando, saindo, se foi ativado ou desativado uma queue.
agora, se isso é bug, eu acho que nao.
mas que pode ser um problema, isso pode.

segue um print do meu teste...
deixei um tempo com burst, um tempo sem burst
quando reiniciou novamente, deixei ter o burst e quando era para ser limitado novamente, eu ativei e desativei uma OUTRA regra no queue, fazendo com que a tabela renovasse... e com isso meu burst foi renovado:

Sem duvida agora vocês entenderam.


E isso de certa forma é um grande problema, pois o burst que eu uso é o dobro da banda do cliente, ou seja, se o burst reanovar constantemente para 700 clientes, tenho consumo dobrado de link.


Vocês acreditam que há algum tipo de configuração avançada de HotSpot ou de queues que pode ser feita para resolver esse problema?


Qual versão do MK você utilizou para o teste?


Obrigado


Rodrigo Godoy

[AndrioPJ]

acredito nao ser problema do Hotspot, mas sim do queue
pois mesmo que voce tenha queue fixo, se desativar, ativar ou criar uma nova regra... a tabela é renovada.
independente de qual sistema de autenticacao voce usa

fiz teste na v5.5 mk

Sem duvida agora vocês entenderam.


E isso de certa forma é um grande problema, pois o burst que eu uso é o dobro da banda do cliente, ou seja, se o burst reanovar constantemente para 700 clientes, tenho consumo dobrado de link.


Vocês acreditam que há algum tipo de configuração avançada de HotSpot ou de queues que pode ser feita para resolver esse problema?


Qual versão do MK você utilizou para o teste?


Obrigado


Rodrigo Godoy

[RockBells]

Também já havia percebido esse "bug" no MK. Até nos MK que não uso Hotspot, quando vc mexe em qualquer queue, ele renova a tabela de todas as demais, fazendo com que os burst tbm sejam renovados. Esse é um dos motivos pela qual eu uso Hotspot descentralizado em cada torre, pois se usasse um único concentrador, meu link iria saturar, pois como nosso amigo citou acima, é cliente logando e deslogando de minuto a minuto.

[superxandaoce]

Nao entendi como vc faz, aqui tenho minhas RB em bridge e meu hotspot fica num computador com o mikrotik, vc faz como ai ?
Usa algum sistema como o mk-auth ? ou o myauth ? para fazer autenticacao radius ?

Também já havia percebido esse "bug" no MK. Até nos MK que não uso Hotspot, quando vc mexe em qualquer queue, ele renova a tabela de todas as demais, fazendo com que os burst tbm sejam renovados. Esse é um dos motivos pela qual eu uso Hotspot descentralizado em cada torre, pois se usasse um único concentrador, meu link iria saturar, pois como nosso amigo citou acima, é cliente logando e deslogando de minuto a minuto.

[RockBells]

Não verdade eu não resolvi o problema, mas o amenizei. Como tenho hotspots em todas as torres, de forma descentralizada, cada torre tem suas próprias queues (dinâmicas ou não). Isso significa que quando o joão conectar, ele não vai renovar a tabela das queues de todos os clientes do provedor, forçando meu link, mas somente daquela torre (hotspot) em questão.

[fsoaress76]

Ola amigos, obrigado pelas respostas. Mas como eu postei anteriormente, o problema não esta no burst.


Meu problema não é o burst dos cliente renovar após um ciclo de tempo, isso já previmos, calculamos, recalculamos, fizemos diversos laboratórios para teste e tudo mais o que podem imaginar.


Meu problema é que quando um cliente loga pelo HotSpot gera um novo queues dinâmico no inicio da tabela de queues, e exatamente neste momento o burst é renovado para todos os meus clientes sem exeção, meu servidor é um concentrador e chega a 700 clientes simultâneos, imagine o burst reabrindo para todos os 700 clientes junto (por esse motivo não acredito em um problema de configuração do burst e nem em coincidencias).


Também tenho ciencia dos campos de configuração do burst, meus clientes possuem 20 segundos de burst (não disse que o "burst time" tem o valor de 20). observem o diagrama abaixo, acho que posso explicar melhor







Observem que cada cliente possuem uma situação diferente um do outro e que no momento X todos reabrem os 20 segundos burst.


Amigos, estou muito agradecido da colaboração de vocês e espero ter explicado melhor meu caso.


Obrigado

Aqui nosso servidor acontece a mesma coisa... pico do processador sobe de 59% para 70%.

A foto1 mostra e queues zerado e foto2 mostra o queues funcionado.

[RockBells]

Eu acho que é uma falha no RouterOS isso ae, pois não tem nexo ele interferir nas demais queues. Experimentem só desabilitar e habilitar uma simple queue, ele irá zerar toda a tabela e dar burst pra todos ao mesmo tempo. O que estabiliza os links, é justamente o fato de nem todo mundo usar 100% de sua banda ao mesmo tempo, agora o MK está justamente fazendo o contrário disso...

Alguém que contribua com o desenvolvimento e melhoramento da MK, poderia tentar entrar em contato informando isso.

[godoy]

Olá amigos.

Sem duvida nenhuma é uma visivel falha do RouterOS que no meu ponto de vista deveria ser corrigido, pois gera (dependendo do caso) um sério transtorno. No meu caso, nós não adotamos a politica de descentralização do HotSpot, até hoje, achamos que será mais trabalhoso administrar tantas RBs, pois possuimos muitos POPs.

Será que algum moderador especialista em Mikrotik poderia interferir junto o desenvolvimento?

Se alguém mais tiver algum ponto de vista ou uma possível solução para o nosso problema, compartilhem conosco para podermos crescer juntos.

Rodrigo Godoy

[1929]

Godoy, aqui no Under, o Sergio tem fortes ligações com o desenvolvimento do mikrotik.
Creio que se voces contatarem ele, conseguirão alguma coisa.

Eu não estou encontrando este problema. Tentei monitorar para ver se acontecia mas não encontrei.

[godoy]

Godoy, aqui no Under, o Sergio tem fortes ligações com o desenvolvimento do mikrotik.
Creio que se voces contatarem ele, conseguirão alguma coisa.

Eu não estou encontrando este problema. Tentei monitorar para ver se acontecia mas não encontrei.

Certo amigo ... você tem algum contato do Sergio para me passar para que eu posso estar conversando com ele?

Grato

Rodrigo Godoy

[AndrioPJ]

Eu acho que é uma falha no RouterOS isso ae, pois não tem nexo ele interferir nas demais queues. Experimentem só desabilitar e habilitar uma simple queue, ele irá zerar toda a tabela e dar burst pra todos ao mesmo tempo. O que estabiliza os links, é justamente o fato de nem todo mundo usar 100% de sua banda ao mesmo tempo, agora o MK está justamente fazendo o contrário disso...

Alguém que contribua com o desenvolvimento e melhoramento da MK, poderia tentar entrar em contato informando isso.

Eu acho que nao é falha nao, é limitacao de tecnologia.
uma regra de controle de banda é bem parecido a uma regra de firewall...
qualquer mudanca, temos que reiniciar a tabela de regras, o que faz com que o burst reinici tbm.

Godoy, aqui no Under, o Sergio tem fortes ligações com o desenvolvimento do mikrotik.
Creio que se voces contatarem ele, conseguirão alguma coisa.

Eu não estou encontrando este problema. Tentei monitorar para ver se acontecia mas não encontrei.

experimente criar um plano com um tempo grande, algo como burst time de 5 min... onde serao 1 min com burst e 4 min sem burst.
quando houve a limitacao, que a velocidade for reduzida, aguarde mais 5s e desative e ative uma regra no queue, sua tabela ira zerar e voltar, e com o ele o burst tbm volta

[1929]

Certo amigo ... você tem algum contato do Sergio para me passar para que eu posso estar conversando com ele?

Grato

Rodrigo Godoy

É só procurar por Sérgio na pesquisa do forum. E daí manda uma mensagem particular para ele.

[int21]

negão, se pode tentar pelo login do usuario, forçar um script que posicione ele no final da lista

um exemplo seria:

/queue simple move [find name="xxxx"] 9999
um forte abraço.