Qual a diferença entre as CCR e as CRS?
Essa CRS faz a mesma função das routerboards comuns tipo a RB 450g?
Versão Imprimível
Qual a diferença entre as CCR e as CRS?
Essa CRS faz a mesma função das routerboards comuns tipo a RB 450g?
CCR é uma serie um pouco mais parruda de roteadores Mikrotik. CRS sao switches layer 3 da mikrotik, com excessao das 260, todo os restante da serie CRS tem funcoes de roteador "tipo" 450g
Vale lembrar que a serie CCR tem muito mais processamento do que uma CRS, mas tudo vai do seu uso.
A sua dúvida se esclarece com a seguinte resposta.
Os dois tem os mesmo potenciais de processamento referente aos processos que eles terão.
CCR é um router.
CRS é um switch.
Vou dar um exemplo comparado a carros.
A CCR tem motor 3.0 turbo, 210 cilindros. Porém pesa 3 mil quilos. Carrega 7 pessoas, e trata individualmente cada vontade deles.
A CRS tem motor 2.0 tem 180 cilindros pesa 800 kilos. Carrega também 7 pessoas. Trata a vontade de todos aos mesmo tempo.
Qual anda mais? Quem tem mais potência ou quem é mais leve?
Como você quer tratar os passageiros? Individualmente ou pode ser um grupo de uma vez.
Vai depender da função que você irá utilizar para justificar o investimento.
Espero ter entendido.
A CCR é a série de altíssimo desempenho da MK. Usam processadores que possuem de 9 até 72 núcleos (e cada núcleo sozinho é mais poderoso do que qualquer CRS).
CCR é equipamento para BORDA ou CORE da rede. A CRS é um switch que usa o routerOS (possui muitas portas e usa routerOS). E como todo routerOS o que manda nas funções é o nível da licença. Se vai precisar de um switch e você gosta de MK vá de CRS. Agora se precisa autenticar clientes, regras de firewall, controle de banda aí você precisa de uma routerboard tradicional.
Uma CRS possui o "mesmo" (do mesmo porte) processador que uma RB750R2.
CCR a lenda que ter X processadores, maior mentira, são vários processadores sim, mas somente um que trabalha de fato.
Poderia postar qual milagre você fez a sua CCR rodar com esse tanto de núcleos? Tenho 10 na rede e todos ela só funciona com 1.
Lorota essa aí de x núcleos. De nada adianta ter um bilhao de nucleos se ela só funciona 1.
Enviado via GT-I9515L usando UnderLinux App
Acredito que o BUG dela é com relação somente ao cálculo de rotas dinâmicas.... No resto ela vai bem.
Enviado de meu Lenovo A7010a48 usando Tapatalk
Sério isso? Nunca utilizei uma CCR, então me fala o que diabos os outros nucelos fazem enquanto somente 1 trabalha? São de enfeites? Se eles não tem "utilidade" o porque de fazer uma com vários nucleos, já que eles não tem uso?Citação:
Postado originalmente por rimaraujo
Apenas uma dúvida que fiquei, na verdade fiquei sem entender o porque, o "certo" não seria "todos" funcionarem? Ou eles só são utilizados de acordo com a demanda de processamento que a rede precisa? To sem entender rsrsrs
Só funciona 1.
Pelo menos aqui na minha rede. Onde utilizo Ospf BGP. Nunca deu mais de 60%.
Tráfegos próximos a 5 giga e nunca utilizou mais de um.
Hum, certo!
Da uma olhada nessa imagem:
Anexo 63377
Que foi postado por um amigo aqui do Under, neste post: https://under-linux.org/showthread.php?t=166705
Olhando a imagem "todos" os nucelos estão trabalhando mesmo que pouco, porém a um que está nos 100%.
Onde no post o amigo fala que roda um BGP com mais de 1 milhão de rotas, com tráfego no pico dos 500Mbps; bem abaixo do seu tráfego então, não será problema de algumas versões? Ou realmente é algo geral?
Posso até está errado, mais o "interesse" em ter uma ccr, não seria justamente pelos seus processadores"nucleos" se só funciona 1, o que ainda justifica a compra dela?
Voltem um pouco no tempo e lembrem se quando apareceram os primeiros Processadores x86 domésticos com múltiplos núcleos. Existiam algumas aplicações que ocupavam 100% de um único núcleo e os demais ficaram livres. Sabem por que? O motivo é simples, aquele software em específico não foi desenhado para mult thread.
Eu não tenho uma lista mas no caso do routeros e o seu atual kernel Linux, quando o assunto é subir um full routing, toda essa rotina fica restrita a um único núcleo.
Agora firewall, queuing, tráfego Ethernet... Tudo é distribuído entre os demais núcleos, simples assim. Imaginem uma batata quente de tamanho variável, múltiplas requisições sendo distribuídas entre todos os processadores, quando chega um full routing.... Queimou! Coitado daquele núcleo em particular. A 1100ahx2 possuí uma performance por núcleo maior e por isso é melhor neste caso em específico.
Enviado via GT-I9300I usando UnderLinux App
Tenho ctz que a mikrotik está trabalhando arduamente na resolução dessa situação.
O problema disso é somente o software deles. Algo me diz que a versão 7 já deve estar por vim e irá corrigir isso.
Não tem cabimento você investir 25.000,00 numa 1072 (ou qualquer ccr que seja) e ela funcionar somente um núcleo.
Os equipamentos da mikrotik tem a proposta de oferecer qualidade e acessibilidade, graças a eles podemos ter roteadores de alto desempenho que "mortais" podem comprar. :)
No caso das CCR, não tem NADA a ver com os múltiplos cores como em x86 típico, não tem nem como o processamento ficar só em 1 core porque os dados passam por VÁRIOS.
Isso é só o modo como o gráfico exibe o uso, o endereçador de entrada geralmente conta como core1, se é por ele que você entra o pacote e recebe a resposta, então é ele quem processou isso (Pro SOFTWARE, pro software! Software é um bicho cego e burro, não pensa, só segue ordens! Não tem como fazer o software descobrir qual core processou algo, o pouco que dá pra arrancar do endereçador de entrada é quais núcleos estão demorando mais nas respostas. Núcleo demorando significa núcleo sendo usado, mas o core1 sendo a entrada é o que mais vai demorar sempre, logo, pro software ele será o mais lento e portanto o mais usado).
Só achei imagem da série antiga dos Tile, mas o esquema é o mesmo nos mais novos, o primeiro core NEM CONSEGUE acessar a memória ou qualquer outra coisa sem "gastar" os outros cores!
Anexo 63379
(Notar que contam como cores as unidades de processamento que aparecem "dentro" da ram ou ethernet, mas não estão foras do núcleo, é que são unidades específicas pra isso, é como se fosse um nó que só trafega da malha principal pra ram, enquanto os nós da malha principal trafegam conteúdo de diferentes trajetos)
Um approach BEM diferente é dos chipsets com ARM, estilo da RB3011. Naquele tipo de chipset, aí sim cada nucleo é separado e isolado um do outro, processa seu quinhão independente do outro núcleo:
Anexo 63380
Mas ainda assim, o núcleo do lado do gerenciador de tráfego será sempre o mais usado, e isso não é um problema. Como ele tem micrometros de distância a menos que os outros núcleos, ele será terá resposta em menos tempo então o gerenciador de tráfego vai passar mais coisa pra ele, e só hora que o tempo de resposta dele for inferior aos outros (Ou seja, só hora que ele estiver lerdo) é que os outros cores serão escolhidos.
"É uma questão de geografia", quem está mais perto responde mais rápido, a luz é rápida mas o gerenciador é mais rápido ainda, um núcleo mais longe demorará mais pra receber o pedido e mais pra resposta voltar por simples questão de distância.
Alias... essa questão do cache L2 neles é curiosa. Pra fabricar um wafer com os processadores você põe em maquinas que fazem a deposição ou corrosão das trilhas de maneira microscópica, um wafer com 150 processador passa por 500 etapas dessa (Deposita material pra trilha, usa laser pra cortar excedente, deposita material isolador, vai construindo em camadas igual impressora 3D, só que com materiais diferentes, hora vai silício, germánio, paládio, cobre, ouro, cerâmica isoladora, nanotubos de carbono pra isolar, etc), digamos um Celeron slot 1 de 1999 tinha seu cache de 256kb porque era caro fazer maior. Mas... lá por 2004 a robotização era tal que pra fazer o núcleo de processamento mesmo, com suas 400 etapas, poderia ser reduzido pra 380 etapas e reduzir custo se o nucleo fosse simplificado, isso mata desempenho. Mas... aí entrou a estratégia de aproveitar que o cache é um monte de espaço repetitivo, e poucas etapas constroem ele, e ao invés de 128 ou 256kb de cache, o cache dos processadores baratos passou a ser enorme, compensava umas definiências do resto do núcleo.
Se saiu de um padrão com cache pequeno, porque ficava no meio do nucleo ocupando espaço:
Anexo 63381
...pra um padrão onde o cache l2, toda essa parte superiora, ocupava quase uns 30% do núcleo porque era barato:
Anexo 63382
Só que aí a "geografia" começou a pesa. Pro dado passar do cache num extremo, até o outro extremo do núcleo, demorava demais, por isso um Celeron mesmo com excelentes 2M de cache L2 era uma porcaria.
Hoje isso morreu, cada núcleo tem seu L2 pequeno do lado, compartilham um L3 porque este pode ser mais lento, separaram melhor os blocos, o que pode ficar distante está distante, enfim, hoje se pesa muito essa questão das distância internas, e olha que estamos falando de núcleos de 3x5mm como isso:
Anexo 63384
Alguns xeon também tem esse problema, porque são velhos mesmo, tá cheio de server por aí usando processadores de 2005 (Idade dos core2duo), a Intel muda a plataforma a cada ANO porque muda a organização interna dos núcleos, em 10 anos isso mudou MUITO.
Enfim, são mundos muito diferentes, os cores de x86 e seu espaço e poder perdidos com proteções contra o usuário, os ARM bem divididos mas ainda pouco evoluídos, os Tile com sua malha entrelaçada de cores que dificulta a medição de uso dos cores mas que gasta pouca eletricidade, os PowerPC com seu barramento central com um monte de coisas ligado nele, onde aí sim se mede perfeitamente os usos exatos dos múltiplos núcleos (Se tiver), pois tem um módulo de coerência pesando as requisições por núcleo pra não deixar um em 100% e o outro em 1%.
Enfim, em x86 e PowerPC a medição de uso de cada core é confiável, mas em Tile e ARM pelo diagrama dos cores não tem como, e nem faz mal se um core tem mesmo mais tráfego, é natural pela questão de distância, o core mais próximo sempre responderá mais rápido mesmo.
(Mips dualcore não sei, tem o ZBBus interligando tudo igual o barramento central de PowerPC (Que eu acho a plataforma perfeita), mas não sei como é a prática, Mips tem mais foco em consumo baixo por custo ainda mais baixo, tem a praxe de colocar co-processador num lado e controlador de consumo no outro, pra produto mobile isso talvez ajude, mas pra produto pra ficar parado em mesa não ajuda nada derrubar o consumo de 4W pra 3,6W, tá certo que muda o calor interno, mas isso se resolve colocando um dissipador em cima e talvez um fan em rotação baixa, Mips pra mim peca numas bobeiras. Você encontra os mesmos chipsets em vários produtos MK, UBNT, e roteadores de mesa porque não tem tanto lançamento de core coerente com o que um roteador pede, tem muito foco gasto em espaço ou consumo que um roteador não precisa)
Ah, e nenhum processador tem um sistema decente de balanceamento de carga nos cores por um motivo simples: O tempo gasto pra processar qual core está desocupado é o tempo de um core ocupado processar a bagaça.
É mais rápido criar fila, e o core livre responder um "Pode mandar". O único problema disso é que um core micrometros mais próximo vai chegar com a resposta mais rapidamente, logo, esse core vai ser mais usado. Só que ser ele chegar perto de 100%, ele fica lento e aí sim o tempo de resposta dos outros cores será menor!
Mas veja isso, o core1 é tão poderoso que mesmo com 70% de uso ele responde rápido o suficiente pros 20 micrometros de distãncia até o próximo core (E a velocidade da luz são 300 mil km por segundo, um micrometro é 1 centésimo de milimetro, que é um milésimo de metro, que é 1 milésimo de km) serem mais lerdo que ele.
Ou seja, o tempo do core em 50% processar e responder algo é menor que o tempo que leva pro core mais distante e em 1% de uso responder algo.
O core1 não tem sentimentos, ele não se cansa por ficar em 100%, ele não tem férias remuneradas 30 dias no ano onde vai pra praia descansar, ele pode muito bem ficar a 100% o dia todo e não sofrer com isso.
Se há problema de desempenho, a culpa não é do core1 aparecer como 100%, provavelmente o gargalo é barramento de entrada ou coisa assim, ou então é o poder geral de processamento do chipset. Lembrem que um Core i3 dualcore custa R$ 500, mas um chipset Tile de 64 nucleos custa R$ 250, não importa o clock ou número de cores, um chipset barato terá diversos gargalos internos, olhar só clock e número de cores é basicamente ser trouxa de comprar um Celeron 3,6GHz e colocar 16GB de Ram DDR3-1066 achando que terá desempenho melhor que um i7 3,1GHz com 12GB de Ram DDR3-1600.
No caso das CCR, não tem NADA a ver com os múltiplos cores como em x86 típico, não tem nem como o processamento ficar só em 1 core porque os dados passam por VÁRIOS.
Isso é só o modo como o gráfico exibe o uso, o endereçador de entrada geralmente conta como core1, se é por ele que você entra o pacote e recebe a resposta, então é ele quem processou isso (Pro SOFTWARE, pro software! Software é um bicho cego e burro, não pensa, só segue ordens! Não tem como fazer o software descobrir qual core processou algo, o pouco que dá pra arrancar do endereçador de entrada é quais núcleos estão demorando mais nas respostas. Núcleo demorando significa núcleo sendo usado, mas o core1 sendo a entrada é o que mais vai demorar sempre, logo, pro software ele será o mais lento e portanto o mais usado).
Só achei imagem da série antiga dos Tile, mas o esquema é o mesmo nos mais novos, o primeiro core NEM CONSEGUE acessar a memória ou qualquer outra coisa sem "gastar" os outros cores!
Anexo 63379
(Notar que contam como cores as unidades de processamento que aparecem "dentro" da ram ou ethernet, mas não estão foras do núcleo, é que são unidades específicas pra isso, é como se fosse um nó que só trafega da malha principal pra ram, enquanto os nós da malha principal trafegam conteúdo de diferentes trajetos)
Um approach BEM diferente é dos chipsets com ARM, estilo da RB3011. Naquele tipo de chipset, aí sim cada nucleo é separado e isolado um do outro, processa seu quinhão independente do outro núcleo:
Anexo 63380
Mas ainda assim, o núcleo do lado do gerenciador de tráfego será sempre o mais usado, e isso não é um problema. Como ele tem micrometros de distância a menos que os outros núcleos, ele será terá resposta em menos tempo então o gerenciador de tráfego vai passar mais coisa pra ele, e só hora que o tempo de resposta dele for inferior aos outros (Ou seja, só hora que ele estiver lerdo) é que os outros cores serão escolhidos.
"É uma questão de geografia", quem está mais perto responde mais rápido, a luz é rápida mas o gerenciador é mais rápido ainda, um núcleo mais longe demorará mais pra receber o pedido e mais pra resposta voltar por simples questão de distância.
Alias... essa questão do cache L2 neles é curiosa. Pra fabricar um wafer com os processadores você põe em maquinas que fazem a deposição ou corrosão das trilhas de maneira microscópica, um wafer com 150 processador passa por 500 etapas dessa (Deposita material pra trilha, usa laser pra cortar excedente, deposita material isolador, vai construindo em camadas igual impressora 3D, só que com materiais diferentes, hora vai silício, germánio, paládio, cobre, ouro, cerâmica isoladora, nanotubos de carbono pra isolar, etc), digamos um Celeron slot 1 de 1999 tinha seu cache de 256kb porque era caro fazer maior. Mas... lá por 2004 a robotização era tal que pra fazer o núcleo de processamento mesmo, com suas 400 etapas, poderia ser reduzido pra 380 etapas e reduzir custo se o nucleo fosse simplificado, isso mata desempenho. Mas... aí entrou a estratégia de aproveitar que o cache é um monte de espaço repetitivo, e poucas etapas constroem ele, e ao invés de 128 ou 256kb de cache, o cache dos processadores baratos passou a ser enorme, compensava umas definiências do resto do núcleo.
Se saiu de um padrão com cache pequeno, porque ficava no meio do nucleo ocupando espaço:
Anexo 63381
...pra um padrão onde o cache l2, toda essa parte superiora, ocupava quase uns 30% do núcleo porque era barato:
Anexo 63382
Só que aí a "geografia" começou a pesa. Pro dado passar do cache num extremo, até o outro extremo do núcleo, demorava demais, por isso um Celeron mesmo com excelentes 2M de cache L2 era uma porcaria.
Hoje isso morreu, cada núcleo tem seu L2 pequeno do lado, compartilham um L3 porque este pode ser mais lento, separaram melhor os blocos, o que pode ficar distante está distante, enfim, hoje se pesa muito essa questão das distância internas, e olha que estamos falando de núcleos de 3x5mm como isso:
Anexo 63384
Alguns xeon também tem esse problema, porque são velhos mesmo, tá cheio de server por aí usando processadores de 2005 (Idade dos core2duo), a Intel muda a plataforma a cada ANO porque muda a organização interna dos núcleos, em 10 anos isso mudou MUITO.
Enfim, são mundos muito diferentes, os cores de x86 e seu espaço e poder perdidos com proteções contra o usuário, os ARM bem divididos mas ainda pouco evoluídos, os Tile com sua malha entrelaçada de cores que dificulta a medição de uso dos cores mas que gasta pouca eletricidade, os PowerPC com seu barramento central com um monte de coisas ligado nele, onde aí sim se mede perfeitamente os usos exatos dos múltiplos núcleos (Se tiver), pois tem um módulo de coerência pesando as requisições por núcleo pra não deixar um em 100% e o outro em 1%.
Enfim, em x86 e PowerPC a medição de uso de cada core é confiável, mas em Tile e ARM pelo diagrama dos cores não tem como, e nem faz mal se um core tem mesmo mais tráfego, é natural pela questão de distância, o core mais próximo sempre responderá mais rápido mesmo.
(Mips dualcore não sei, tem o ZBBus interligando tudo igual o barramento central de PowerPC (Que eu acho a plataforma perfeita), mas não sei como é a prática, Mips tem mais foco em consumo baixo por custo ainda mais baixo, tem a praxe de colocar co-processador num lado e controlador de consumo no outro, pra produto mobile isso talvez ajude, mas pra produto pra ficar parado em mesa não ajuda nada derrubar o consumo de 4W pra 3,6W, tá certo que muda o calor interno, mas isso se resolve colocando um dissipador em cima e talvez um fan em rotação baixa, Mips pra mim peca numas bobeiras. Você encontra os mesmos chipsets em vários produtos MK, UBNT, e roteadores de mesa porque não tem tanto lançamento de core coerente com o que um roteador pede, tem muito foco gasto em espaço ou consumo que um roteador não precisa)
Ah, e nenhum processador tem um sistema decente de balanceamento de carga nos cores por um motivo simples: O tempo gasto pra processar qual core está desocupado é o tempo de um core ocupado processar a bagaça.
É mais rápido criar fila, e o core livre responder um "Pode mandar". O único problema disso é que um core micrometros mais próximo vai chegar com a resposta mais rapidamente, logo, esse core vai ser mais usado. Só que ser ele chegar perto de 100%, ele fica lento e aí sim o tempo de resposta dos outros cores será menor!
Mas veja isso, o core1 é tão poderoso que mesmo com 70% de uso ele responde rápido o suficiente pros 20 micrometros de distãncia até o próximo core (E a velocidade da luz são 300 mil km por segundo, um micrometro é 1 centésimo de milimetro, que é um milésimo de metro, que é 1 milésimo de km) serem mais lerdo que ele.
Ou seja, o tempo do core em 50% processar e responder algo é menor que o tempo que leva pro core mais distante e em 1% de uso responder algo.
O core1 não tem sentimentos, ele não se cansa por ficar em 100%, ele não tem férias remuneradas 30 dias no ano onde vai pra praia descansar, ele pode muito bem ficar a 100% o dia todo e não sofrer com isso.
Se há problema de desempenho, a culpa não é do core1 aparecer como 100%, provavelmente o gargalo é barramento de entrada ou coisa assim, ou então é o poder geral de processamento do chipset. Lembrem que um Core i3 dualcore custa R$ 500, mas um chipset Tile de 64 nucleos custa R$ 250, não importa o clock ou número de cores, um chipset barato terá diversos gargalos internos, olhar só clock e número de cores é basicamente ser trouxa de comprar um Celeron 3,6GHz e colocar 16GB de Ram DDR3-1066 achando que terá desempenho melhor que um i7 3,1GHz com 12GB de Ram DDR3-1600.