Página 3 de 3 PrimeiroPrimeiro 123
+ Responder ao Tópico



  1. 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

  2. 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.



  3. 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!

    Clique na imagem para uma versão maior

Nome:	         figure_01.jpg
Visualizações:	65
Tamanho: 	106,6 KB
ID:      	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:
    Clique na imagem para uma versão maior

Nome:	         TILE-Mx100_block.png
Visualizações:	43
Tamanho: 	605,8 KB
ID:      	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:
    Clique na imagem para uma versão maior

Nome:	         diecachesize.jpg
Visualizações:	32
Tamanho: 	52,0 KB
ID:      	63381

    ...pra um padrão onde o cache l2, toda essa parte superiora, ocupava quase uns 30% do núcleo porque era barato:
    Clique na imagem para uma versão maior

Nome:	         02PrescottDie.jpg
Visualizações:	48
Tamanho: 	125,6 KB
ID:      	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:
    Clique na imagem para uma versão maior

Nome:	         corei.jpg
Visualizações:	47
Tamanho: 	156,1 KB
ID:      	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.
    Miniaturas de Anexos Miniaturas de Anexos Clique na imagem para uma versão maior

Nome:	         corei.jpg
Visualizações:	28
Tamanho: 	206,2 KB
ID:      	63383  

  4. 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!

    Clique na imagem para uma versão maior

Nome:	         figure_01.jpg
Visualizações:	65
Tamanho: 	106,6 KB
ID:      	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:
    Clique na imagem para uma versão maior

Nome:	         TILE-Mx100_block.png
Visualizações:	43
Tamanho: 	605,8 KB
ID:      	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:
    Clique na imagem para uma versão maior

Nome:	         diecachesize.jpg
Visualizações:	32
Tamanho: 	52,0 KB
ID:      	63381

    ...pra um padrão onde o cache l2, toda essa parte superiora, ocupava quase uns 30% do núcleo porque era barato:
    Clique na imagem para uma versão maior

Nome:	         02PrescottDie.jpg
Visualizações:	48
Tamanho: 	125,6 KB
ID:      	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:
    Clique na imagem para uma versão maior

Nome:	         corei.jpg
Visualizações:	47
Tamanho: 	156,1 KB
ID:      	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.






Tópicos Similares

  1. Respostas: 0
    Último Post: 11-02-2008, 09:17
  2. Qual a diferença entre os tipos de Queues?
    Por Gosulator no fórum Redes
    Respostas: 2
    Último Post: 07-11-2007, 23:24
  3. Qual a Diferença entre 2,4 e 5,8 ?
    Por tianguapontocom no fórum Redes
    Respostas: 1
    Último Post: 31-03-2006, 09:37
  4. Qual a Diferença entre AP-2000 e AP-2500
    Por fabio-ensite no fórum Redes
    Respostas: 2
    Último Post: 31-03-2005, 22:48
  5. Qual as diferenças entre várias distribuições?
    Por FabioRB no fórum Servidores de Rede
    Respostas: 15
    Último Post: 03-02-2004, 16:18

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L