kernel Linux otimizado - Compilação e teste
Obtenção, configuração, compilação e instalação de um novo kernel Linux otimizado na distribuição Debian Wheezy, com posterior teste de desempenho comparativo entre kernel com e sem alterações. Inclusive, com overclock simples.
[ Hits: 45.851 ]
Por: Buckminster em 02/09/2013
Testando
Foram efetuados testes sem as alterações e com as alterações no kernel, ou seja, entrando no boot do Kernel alterado e do Kernel sem alterações.
Utilizamos o Phoronix Test Suite e rodamos o teste Complex e a suíte de testes Kernel. O teste Complex leva de 30 a 45 minutos, dependendo da máquina, e a suíte Kernel, leva de 3 a 4 horas.
Foi utilizado também o Hardinfo, que faz parte dos pacotes do Debian.
O Phoronix Test Suite é uma plataforma de benchmarking abrangente disponível, que fornece uma estrutura extensível para novos testes serem facilmente adicionados. O software é projetado para, efetivamente, realizar referências qualitativas e quantitativas de uma forma limpa, reprodutível e fácil de usar.
Foi originalmente desenvolvido para testes em GNU/Linux, mas desde então, foram adicionados para OpenSolaris, Mac OS X, Microsoft Windows e sistemas operacionais BSD.
O Phoronix Test Suite é baseado em extensos testes e ferramentas internas desenvolvidas pela Phoronix.com desde 2004, juntamente com o apoio dos principais fabricantes de Hardware e Software. O Phoronix é Open Source e licenciado sob a GNU GPLv3 e fornece 150 tipos de testes diferentes.
A grande vantagem do Phoronix, é que é necessário instalar somente o programa, todo o resto, inclusive jogos utilizados nos testes (OpenArena, por exemplo), ele instala e desinstala sozinho. Poderia dizer que o tempo decorrido para os testes é demorado, porém, tendo em vista a facilidade e a praticidade de sua utilização, faz do Phoronix um dos melhores programas do gênero.
Foram realizados testes em três máquinas, mas postaremos somente os resultados do servidor com Core 2 Quad a título de ilustração, pois os resultados de todos os testes, foram semelhantes entre si nos kernels com e sem otimização.
Resolvemos também, na última resfolega, dar um overclockzinho sem muitas pretensões no Core 2 Quad, overclock este, feito através da placa-mãe Asus P5Q:
O FSB (Front Side Bus - Barramento Frontal), é o produto da multiplicação da frequência de clock (ciclos por segundo), da largura da via de dados e da quantidade de transferências de dados realizadas por ciclo do clock.
Após verificarmos que não houve travamentos e que a máquina continuava funcionando normalmente, efetuamos o teste com este overclock simples.
Seguem as imagens com os resultados dos testes, sendo que os testes podem ser visualizados na íntegra nos links do site da Phoronix, disponíveis no final do artigo.
Figura 6 - Teste Complex sem "otimização"
Figura 7 - Teste Complex com "otimização"
Figura 8 - Teste Complex com overclock
Podemos observar que os testes com as alterações de "otimização" nos arquivos do kernel antes da compilação, geraram uma diferença não muito significativa no desempenho em relação ao kernel sem as alterações.
O placar final neste teste foi de 3 (Kernel 'Sem') a 2 (Kernel 'Com'), ou seja, o kernel sem otimização demonstrou melhor desempenho, porém as diferenças são ínfimas e não muito significativas resultando no que chamamos de empate técnico.
O teste com overclock foi realizado no kernel sem as alterações e podemos constatar que houve uma diferença significativa, onde conclui-se o esperado: para otimizar o processador, deve-se alterar as configurações do processador através da placa-mãe, isso é óbvio.
Apesar de que não somos partidários de overclock, fizemos este somente para o fim destes testes, o qual foi desfeito depois.
Postmark (Carimbo): é um teste de NetApps projetado para simular testes em pequenos arquivos semelhantes aos das tarefas enfrentadas por servidores web e e-mail. Este teste realiza 25 mil operações, com 500 arquivos simultaneamente, com os tamanhos dos arquivos variando entre 5 e 512 kilobytes.
RAMspeed: este benchmark testa o desempenho de memória RAM do sistema com cálculos com números inteiros e com números com ponto flutuante.
C-Ray: este é um teste raytracer simples, projetado para testar o desempenho de ponto flutuante da CPU. Este teste é multi-threaded (16 threads por núcleo) e atira oito raios por pixel para anti-aliasing e gera uma imagem de 1600 x 1200. Basicamente é um teste de renderização e CPU.
Apache Benchmark: testa o desempenho do sistema de um modo geral e da CPU, com a utilização do Apache.
Utilizamos o Phoronix Test Suite e rodamos o teste Complex e a suíte de testes Kernel. O teste Complex leva de 30 a 45 minutos, dependendo da máquina, e a suíte Kernel, leva de 3 a 4 horas.
Foi utilizado também o Hardinfo, que faz parte dos pacotes do Debian.
O Phoronix Test Suite é uma plataforma de benchmarking abrangente disponível, que fornece uma estrutura extensível para novos testes serem facilmente adicionados. O software é projetado para, efetivamente, realizar referências qualitativas e quantitativas de uma forma limpa, reprodutível e fácil de usar.
Foi originalmente desenvolvido para testes em GNU/Linux, mas desde então, foram adicionados para OpenSolaris, Mac OS X, Microsoft Windows e sistemas operacionais BSD.
O Phoronix Test Suite é baseado em extensos testes e ferramentas internas desenvolvidas pela Phoronix.com desde 2004, juntamente com o apoio dos principais fabricantes de Hardware e Software. O Phoronix é Open Source e licenciado sob a GNU GPLv3 e fornece 150 tipos de testes diferentes.
A grande vantagem do Phoronix, é que é necessário instalar somente o programa, todo o resto, inclusive jogos utilizados nos testes (OpenArena, por exemplo), ele instala e desinstala sozinho. Poderia dizer que o tempo decorrido para os testes é demorado, porém, tendo em vista a facilidade e a praticidade de sua utilização, faz do Phoronix um dos melhores programas do gênero.
Foram realizados testes em três máquinas, mas postaremos somente os resultados do servidor com Core 2 Quad a título de ilustração, pois os resultados de todos os testes, foram semelhantes entre si nos kernels com e sem otimização.
Resolvemos também, na última resfolega, dar um overclockzinho sem muitas pretensões no Core 2 Quad, overclock este, feito através da placa-mãe Asus P5Q:
- FSB Frequency de 333 MHz, foi colocada em 400 MHz;
- FSB Strap to North Bridge de 333 MHz, foi para 400 MHz.
O FSB (Front Side Bus - Barramento Frontal), é o produto da multiplicação da frequência de clock (ciclos por segundo), da largura da via de dados e da quantidade de transferências de dados realizadas por ciclo do clock.
Após verificarmos que não houve travamentos e que a máquina continuava funcionando normalmente, efetuamos o teste com este overclock simples.
Seguem as imagens com os resultados dos testes, sendo que os testes podem ser visualizados na íntegra nos links do site da Phoronix, disponíveis no final do artigo.
Figura 6 - Teste Complex sem "otimização"
Figura 7 - Teste Complex com "otimização"
Figura 8 - Teste Complex com overclock
- PostMark → quanto maior, melhor.
- RAM integer → quanto maior, melhor.
- RAM Floating Point → quanto maior, melhor.
- C-Ray → quanto menor, melhor.
- Apache → quanto maior, melhor.
Podemos observar que os testes com as alterações de "otimização" nos arquivos do kernel antes da compilação, geraram uma diferença não muito significativa no desempenho em relação ao kernel sem as alterações.
O placar final neste teste foi de 3 (Kernel 'Sem') a 2 (Kernel 'Com'), ou seja, o kernel sem otimização demonstrou melhor desempenho, porém as diferenças são ínfimas e não muito significativas resultando no que chamamos de empate técnico.
O teste com overclock foi realizado no kernel sem as alterações e podemos constatar que houve uma diferença significativa, onde conclui-se o esperado: para otimizar o processador, deve-se alterar as configurações do processador através da placa-mãe, isso é óbvio.
Apesar de que não somos partidários de overclock, fizemos este somente para o fim destes testes, o qual foi desfeito depois.
Postmark (Carimbo): é um teste de NetApps projetado para simular testes em pequenos arquivos semelhantes aos das tarefas enfrentadas por servidores web e e-mail. Este teste realiza 25 mil operações, com 500 arquivos simultaneamente, com os tamanhos dos arquivos variando entre 5 e 512 kilobytes.
RAMspeed: este benchmark testa o desempenho de memória RAM do sistema com cálculos com números inteiros e com números com ponto flutuante.
C-Ray: este é um teste raytracer simples, projetado para testar o desempenho de ponto flutuante da CPU. Este teste é multi-threaded (16 threads por núcleo) e atira oito raios por pixel para anti-aliasing e gera uma imagem de 1600 x 1200. Basicamente é um teste de renderização e CPU.
Apache Benchmark: testa o desempenho do sistema de um modo geral e da CPU, com a utilização do Apache.
Páginas do artigo
1. Introdução2. Configurando e otimizando
3. Compilando e otimizando
4. Testando
5. Suíte de testes Kernel
6. Hardinfo
7. Conclusões
Outros artigos deste autor
ClamAV, o kit de ferramentas antivírus
Compilação e instalação do Vim e habilitando a copiar e colar com o mouse
Squid - Entendendo um pouco as configurações
Leitura recomendada
Sistema de arquivos EXT4 no OpenSuSE 11.1
Slackware 13 - Compilando o kernel 2.6.32rc6
Recompilando o kernel na distribuição Debian
Mascarando conexões PPTP de clientes
Instalando e configurando os módulos do kernel 2.6 no Slackware
Comentários
[1] Comentário enviado por nicolo em 02/09/2013 - 09:28h
Fiquei com uma dúvida. Em termos de hardware sempre li que os tempos de espera deveriam ser os menores possíveis indo de 4 ms (250 hertz) para 1 ms (1000 hertz) se o hardware suportasse. Para multimedia sempre li que 1000 hertz seria mellhor.
É isso mesmo?
Não sei nada de servidor, uma vez que não sou profissional de informática, apenas gosto de multimedia por diletantismo.
O artigo é interessante pela lucidez. O software não faz milagre no hardware. Pelo menos para os usuários domésticos os resultados não compensam a ginástica, exceto para quem está a procura de emoções fortes.
Vai para os favoritos.
Fiquei com uma dúvida. Em termos de hardware sempre li que os tempos de espera deveriam ser os menores possíveis indo de 4 ms (250 hertz) para 1 ms (1000 hertz) se o hardware suportasse. Para multimedia sempre li que 1000 hertz seria mellhor.
É isso mesmo?
Não sei nada de servidor, uma vez que não sou profissional de informática, apenas gosto de multimedia por diletantismo.
O artigo é interessante pela lucidez. O software não faz milagre no hardware. Pelo menos para os usuários domésticos os resultados não compensam a ginástica, exceto para quem está a procura de emoções fortes.
Vai para os favoritos.
[2] Comentário enviado por gpxlnx em 02/09/2013 - 09:57h
Meus sinceros parabéns pelo ótimo artigo. Sem palavras, uma verdadeira aula de otimização, teste e compilação de kernel.
Só uma duvida, tais procedimentos podem ser aplicados a compilações de kernel 64 bits?
Obg e parabéns.
Meus sinceros parabéns pelo ótimo artigo. Sem palavras, uma verdadeira aula de otimização, teste e compilação de kernel.
Só uma duvida, tais procedimentos podem ser aplicados a compilações de kernel 64 bits?
Obg e parabéns.
[3] Comentário enviado por Buckminster em 02/09/2013 - 10:33h
[1] Comentário enviado por nicolo em 02/09/2013 - 09:28h:
Fiquei com uma dúvida. Em termos de hardware sempre li que os tempos de espera deveriam ser os menores possíveis indo de 4 ms (250 hertz) para 1 ms (1000 hertz) se o hardware suportasse. Para multimedia sempre li que 1000 hertz seria mellhor.
É isso mesmo?
Não sei nada de servidor, uma vez que não sou profissional de informática, apenas gosto de multimedia por diletantismo.
O artigo é interessante pela lucidez. O software não faz milagre no hardware. Pelo menos para os usuários domésticos os resultados não compensam a ginástica, exceto para quem está a procura de emoções fortes.
Vai para os favoritos.
Obrigado.
A frequência de interrupção do temporizador é um parâmetro importante do real-time (tempo real de resposta) e de aplicações multimídia rodando em Linux. A frequência de interrupção do timer impacta diretamente na capacidade de tempo real para processar eventos em altas frequências. A "alta frequência" neste contexto, significa valores maiores do que 100 Hz (10 ms). 100 Hz é também considerada uma frequência alta para esse tipo de processamento.
250 Hz (4 ms) e 1000 HZ (1 ms).
Em 1000 Hz o sistema é mais ágil, mas passa muito tempo 'esperando' pelos eventos (para que ele possa responder a eles rapidamente), porém, o seu rendimento é menor em hardwares que não são muito bons.
O Kernel Linux vem com 250 Hz por padrão porque é um valor médio que se adapta à maioria das aplicações e dos hardwares.
Mas cada caso é um caso. Se você tem uma boa placa de vídeo, um sistema e um hardware voltados quase que exclusivamente para aplicações multimídia pode colocar em 1000 Hz sem problemas.
Eu sempre sugiro 100 Hz para servidores tendo em vista a estabilidade do sistema. E 100 Hz melhora o tempo de resposta das requisições no sentido de que um servidor não precisa ficar 'esperando' pelos eventos e pelas interrupções, ou seja, assim como vão chegando os pedidos ele vai respondendo, ao passo que em 1000 Hz a resposta em si é 10 vezes mais rápida, mas ficará mais tempo 'esperando' pelo hardware.
Resumindo, cada caso é um caso, não adianta colocar 2000 Hz (como já vi colocarem) sendo que o sistema e o hardware não acompanham e ficam travando.
E nessa 'jogada' aí temos que levar em conta também o processador, pois o Timer Frequency do kernel age em conjunto com o processador, tanto assim que está justamente nos parâmetros de tipos e recursos do processador.
Em questão de configuração do kernel, é importantíssimo ter em mente que é um conjunto (set) de coisas. Nada pode ser levado em conta isoladamente.
[1] Comentário enviado por nicolo em 02/09/2013 - 09:28h:
Fiquei com uma dúvida. Em termos de hardware sempre li que os tempos de espera deveriam ser os menores possíveis indo de 4 ms (250 hertz) para 1 ms (1000 hertz) se o hardware suportasse. Para multimedia sempre li que 1000 hertz seria mellhor.
É isso mesmo?
Não sei nada de servidor, uma vez que não sou profissional de informática, apenas gosto de multimedia por diletantismo.
O artigo é interessante pela lucidez. O software não faz milagre no hardware. Pelo menos para os usuários domésticos os resultados não compensam a ginástica, exceto para quem está a procura de emoções fortes.
Vai para os favoritos.
Obrigado.
A frequência de interrupção do temporizador é um parâmetro importante do real-time (tempo real de resposta) e de aplicações multimídia rodando em Linux. A frequência de interrupção do timer impacta diretamente na capacidade de tempo real para processar eventos em altas frequências. A "alta frequência" neste contexto, significa valores maiores do que 100 Hz (10 ms). 100 Hz é também considerada uma frequência alta para esse tipo de processamento.
250 Hz (4 ms) e 1000 HZ (1 ms).
Em 1000 Hz o sistema é mais ágil, mas passa muito tempo 'esperando' pelos eventos (para que ele possa responder a eles rapidamente), porém, o seu rendimento é menor em hardwares que não são muito bons.
O Kernel Linux vem com 250 Hz por padrão porque é um valor médio que se adapta à maioria das aplicações e dos hardwares.
Mas cada caso é um caso. Se você tem uma boa placa de vídeo, um sistema e um hardware voltados quase que exclusivamente para aplicações multimídia pode colocar em 1000 Hz sem problemas.
Eu sempre sugiro 100 Hz para servidores tendo em vista a estabilidade do sistema. E 100 Hz melhora o tempo de resposta das requisições no sentido de que um servidor não precisa ficar 'esperando' pelos eventos e pelas interrupções, ou seja, assim como vão chegando os pedidos ele vai respondendo, ao passo que em 1000 Hz a resposta em si é 10 vezes mais rápida, mas ficará mais tempo 'esperando' pelo hardware.
Resumindo, cada caso é um caso, não adianta colocar 2000 Hz (como já vi colocarem) sendo que o sistema e o hardware não acompanham e ficam travando.
E nessa 'jogada' aí temos que levar em conta também o processador, pois o Timer Frequency do kernel age em conjunto com o processador, tanto assim que está justamente nos parâmetros de tipos e recursos do processador.
Em questão de configuração do kernel, é importantíssimo ter em mente que é um conjunto (set) de coisas. Nada pode ser levado em conta isoladamente.
[4] Comentário enviado por Buckminster em 02/09/2013 - 10:40h
[2] Comentário enviado por gpxlnx em 02/09/2013 - 09:57h:
Meus sinceros parabéns pelo ótimo artigo. Sem palavras, uma verdadeira aula de otimização, teste e compilação de kernel.
Só uma duvida, tais procedimentos podem ser aplicados a compilações de kernel 64 bits?
Obg e parabéns.
Obrigado.
Todas as compilações do artigo foram em 64 bits.
Nestas configurações não importa se é 32 ou 64 bits. O Kernel Linux no início do menuconfig traz a opção de marcar se você quer 64 bits, se não quiser é só desmarcar a opção que ele compilará em 32 bits.
[2] Comentário enviado por gpxlnx em 02/09/2013 - 09:57h:
Meus sinceros parabéns pelo ótimo artigo. Sem palavras, uma verdadeira aula de otimização, teste e compilação de kernel.
Só uma duvida, tais procedimentos podem ser aplicados a compilações de kernel 64 bits?
Obg e parabéns.
Obrigado.
Todas as compilações do artigo foram em 64 bits.
Nestas configurações não importa se é 32 ou 64 bits. O Kernel Linux no início do menuconfig traz a opção de marcar se você quer 64 bits, se não quiser é só desmarcar a opção que ele compilará em 32 bits.
[5] Comentário enviado por lcavalheiro em 02/09/2013 - 11:05h
Rapaz, que artigo porreta de bom! Agora não tem mais desculpa, você descomplicou o lance de compilar um kernel, e agor até minha avó de 90 anos conseguiria compilar um.
PS.: quando eu vi o avatar pensei logo, "ressuscitaram o Irado?"
Rapaz, que artigo porreta de bom! Agora não tem mais desculpa, você descomplicou o lance de compilar um kernel, e agor até minha avó de 90 anos conseguiria compilar um.
PS.: quando eu vi o avatar pensei logo, "ressuscitaram o Irado?"
[6] Comentário enviado por Buckminster em 02/09/2013 - 11:12h
[5] Comentário enviado por lcavalheiro em 02/09/2013 - 11:05h:
Rapaz, que artigo porreta de bom! Agora não tem mais desculpa, você descomplicou o lance de compilar um kernel, e agor até minha avó de 90 anos conseguiria compilar um.
PS.: quando eu vi o avatar pensei logo, "ressuscitaram o Irado?"
Obrigado meu caro.
É verdade, bem lembrado, o Irado usava essa imagem também.
[5] Comentário enviado por lcavalheiro em 02/09/2013 - 11:05h:
Rapaz, que artigo porreta de bom! Agora não tem mais desculpa, você descomplicou o lance de compilar um kernel, e agor até minha avó de 90 anos conseguiria compilar um.
PS.: quando eu vi o avatar pensei logo, "ressuscitaram o Irado?"
Obrigado meu caro.
É verdade, bem lembrado, o Irado usava essa imagem também.
[7] Comentário enviado por removido em 02/09/2013 - 11:47h
Nada como a imparcialidade para lidar com assuntos como esse.
Nem todo mundo usa meta distribuição, e como usuário final, não vejo a necessidade de compilar kernel para ganhos infímos.
Já compilei kernels algumas vezes no Slack e não ficou diferente da costumeira velocidade/desempenho característicos do preguiçoso.
Mas que compilar vale a experiência, isso vale!
Primoroso. Essencial.
Um dos melhores artigos sobre o assunto que já li.
Nada como a imparcialidade para lidar com assuntos como esse.
Nem todo mundo usa meta distribuição, e como usuário final, não vejo a necessidade de compilar kernel para ganhos infímos.
Já compilei kernels algumas vezes no Slack e não ficou diferente da costumeira velocidade/desempenho característicos do preguiçoso.
Mas que compilar vale a experiência, isso vale!
Primoroso. Essencial.
Um dos melhores artigos sobre o assunto que já li.
[8] Comentário enviado por Buckminster em 02/09/2013 - 12:03h
[7] Comentário enviado por izaias em 02/09/2013 - 11:47h:
Nada como a imparcialidade para lidar com assuntos como esse.
Nem todo mundo usa meta distribuição, e como usuário final, não vejo a necessidade de compilar kernel para ganhos infímos.
Já compilei kernels algumas vezes no Slack e não ficou diferente da costumeira velocidade/desempenho característicos do preguiçoso.
Mas que compilar vale a experiência, isso vale!
Primoroso. Essencial.
Um dos melhores artigos sobre o assunto que já li.
Muito obrigado, Izaias.
[7] Comentário enviado por izaias em 02/09/2013 - 11:47h:
Nada como a imparcialidade para lidar com assuntos como esse.
Nem todo mundo usa meta distribuição, e como usuário final, não vejo a necessidade de compilar kernel para ganhos infímos.
Já compilei kernels algumas vezes no Slack e não ficou diferente da costumeira velocidade/desempenho característicos do preguiçoso.
Mas que compilar vale a experiência, isso vale!
Primoroso. Essencial.
Um dos melhores artigos sobre o assunto que já li.
Muito obrigado, Izaias.
[9] Comentário enviado por madrugada em 02/09/2013 - 18:53h
Um ótimo artigo, meus parabéns!
Caso queira adicionar, a flag "-pipe" não otimiza os binários kernel/módulos, e sim o tempo de construção dos mesmos. Ele indica pra fazer mais uso da ram durante a compilação, e assim reduz o I/O no disco.
Um ótimo artigo, meus parabéns!
Caso queira adicionar, a flag "-pipe" não otimiza os binários kernel/módulos, e sim o tempo de construção dos mesmos. Ele indica pra fazer mais uso da ram durante a compilação, e assim reduz o I/O no disco.
[10] Comentário enviado por albfneto em 02/09/2013 - 19:29h
Mais um Artigo Excelente. Demonstra Conhecimento. Favoritado. 10! Parabéns!
Aparentemente, me parece semelhante.
eu concluiria que overclocar a CPU é melhor do que recompilar o kernel.
eu ia tentar kernel de baixa latência no sabayon e estou mudando de idéia.
Mais um Artigo Excelente. Demonstra Conhecimento. Favoritado. 10! Parabéns!
Aparentemente, me parece semelhante.
eu concluiria que overclocar a CPU é melhor do que recompilar o kernel.
eu ia tentar kernel de baixa latência no sabayon e estou mudando de idéia.
[11] Comentário enviado por Buckminster em 03/09/2013 - 07:30h
[9] Comentário enviado por madrugada em 02/09/2013 - 18:53h:
Um ótimo artigo, meus parabéns!
Caso queira adicionar, a flag "-pipe" não otimiza os binários kernel/módulos, e sim o tempo de construção dos mesmos. Ele indica pra fazer mais uso da ram durante a compilação, e assim reduz o I/O no disco.
Obrigado.
Sim, a flag "-pipe" agiliza o tempo de construção dos binários e diminui um pouco o tempo de compilação.
[9] Comentário enviado por madrugada em 02/09/2013 - 18:53h:
Um ótimo artigo, meus parabéns!
Caso queira adicionar, a flag "-pipe" não otimiza os binários kernel/módulos, e sim o tempo de construção dos mesmos. Ele indica pra fazer mais uso da ram durante a compilação, e assim reduz o I/O no disco.
Obrigado.
Sim, a flag "-pipe" agiliza o tempo de construção dos binários e diminui um pouco o tempo de compilação.
[12] Comentário enviado por Buckminster em 03/09/2013 - 07:35h
[10] Comentário enviado por albfneto em 02/09/2013 - 19:29h:
Mais um Artigo Excelente. Demonstra Conhecimento. Favoritado. 10! Parabéns!
Aparentemente, me parece semelhante.
eu concluiria que overclocar a CPU é melhor do que recompilar o kernel.
eu ia tentar kernel de baixa latência no sabayon e estou mudando de idéia.
Obrigado meu caro Alberto.
O Timer Frequency é relativo, depende muito do hardware em questão. O kernel Linux você pode configurar ele especificamente para o hardware da sua máquina.
O problema é mexer em todo aquele "monte" de parâmetros e configurações e saber o que cada um faz. Uma vida não bastaria para o cara aprender tudo.
Mas veja o comentário 3 ai em cima sobre o Timer Frequency.
[10] Comentário enviado por albfneto em 02/09/2013 - 19:29h:
Mais um Artigo Excelente. Demonstra Conhecimento. Favoritado. 10! Parabéns!
Aparentemente, me parece semelhante.
eu concluiria que overclocar a CPU é melhor do que recompilar o kernel.
eu ia tentar kernel de baixa latência no sabayon e estou mudando de idéia.
Obrigado meu caro Alberto.
O Timer Frequency é relativo, depende muito do hardware em questão. O kernel Linux você pode configurar ele especificamente para o hardware da sua máquina.
O problema é mexer em todo aquele "monte" de parâmetros e configurações e saber o que cada um faz. Uma vida não bastaria para o cara aprender tudo.
Mas veja o comentário 3 ai em cima sobre o Timer Frequency.
[13] Comentário enviado por galactus em 03/09/2013 - 08:47h
Olá. Parabéns pelo artigo e obrigado pelo link do meu artigo: Compilando o Kernel otimizado para o seu processador no Ubuntu!
Contudo, discordo da sua conclusão. Testes sintéticos não são tudo. Já li comentários dos desenvolvedores do ext4 e do XFS no próprio phoronix alertando sobre isso. Você ainda pode fazer maiores alterações, incluindo patchs para melhorar o desempenho do sistema, como alterar escalonadores do disco ou do processador e por aí vai. O fato da sua compilação não ter dado diferença pra você, não quer dizer que não melhore para outros.
Façam uma compilação voltada para desktop, use 1000MHz, preempt, lowlatency, coloque os patchs BFS + BFQ e verão que a diferença de desempenho para um kernel padrão é evidente. Se assim não o fosse, porque teríamos as ferramentas para compilação? E o trabalho que os caras tem de desenvolver novos patchs para melhorar o desempenho? Tente fazer um monte de coisas com um kernel padrão como nesses vídeos:
http://www.youtube.com/watch?v=PSMwkPC_dHc
http://www.youtube.com/watch?v=AowpcItBS_U
Depois tentem o mesmo com um kernel "preparado" para sua máquina! Fiz questão de colocar exemplos de hardware bem distintos para notarem que o ganho é exponencial ao seu hardware. Mas que dá diferença, dá!
Olá. Parabéns pelo artigo e obrigado pelo link do meu artigo: Compilando o Kernel otimizado para o seu processador no Ubuntu!
Contudo, discordo da sua conclusão. Testes sintéticos não são tudo. Já li comentários dos desenvolvedores do ext4 e do XFS no próprio phoronix alertando sobre isso. Você ainda pode fazer maiores alterações, incluindo patchs para melhorar o desempenho do sistema, como alterar escalonadores do disco ou do processador e por aí vai. O fato da sua compilação não ter dado diferença pra você, não quer dizer que não melhore para outros.
Façam uma compilação voltada para desktop, use 1000MHz, preempt, lowlatency, coloque os patchs BFS + BFQ e verão que a diferença de desempenho para um kernel padrão é evidente. Se assim não o fosse, porque teríamos as ferramentas para compilação? E o trabalho que os caras tem de desenvolver novos patchs para melhorar o desempenho? Tente fazer um monte de coisas com um kernel padrão como nesses vídeos:
http://www.youtube.com/watch?v=PSMwkPC_dHc
http://www.youtube.com/watch?v=AowpcItBS_U
Depois tentem o mesmo com um kernel "preparado" para sua máquina! Fiz questão de colocar exemplos de hardware bem distintos para notarem que o ganho é exponencial ao seu hardware. Mas que dá diferença, dá!
[14] Comentário enviado por Buckminster em 03/09/2013 - 09:14h
Galactus:
Obrigado e concordo.
Mas a diferença é notada com Kernels preparados especificamente para determinados hardwares, não com somente essas alterações feitas no artigo.
E você mesmo fala: "um kernel "preparado" para sua máquina!", ou seja, ratifica o que eu digo, alterações genéricas não surtem efeito no desempenho.
Os patchs são para corrigir e melhorar determinadas deficiências no código e mesmo assim são para determinada versão do Kernel, ou seja, cada versão basicamente tem um patch específico, o que nos leva de novo à conclusão de que alterações genéricas não surtem muito efeito.
Um patch utilizado numa versão errada irá prejudicar o Kernel em vez de melhorar.
E nas conclusões está bem claro que os testes feitos no artigo estão longe de serem conclusivos e que talvez em determinado processador, as alterações sugeridas no artigo tenham um efeito um pouco maior.
Veja a descrição do primeiro vídeo:
"Esta máquina usava um kernel experimental compilado para ela com um sistema de arquivos próprio para essa máquina e o Ubuntu 10.04 também foi modificado. Deu um certo trabalho, mas ficou ótima de usar como pode ver no vídeo. Infelizmente o kernel Ominslash não é mais desenvolvido e o suporte ao Ubuntu 10.04 está acabando. Mas você pode ter algo bem próximo, com um kernel "tunado" e algumas das minhas dicas no tópico: Acelerando o seu sistema Linux sem compilações em computadores e Notebooks."
O sistema foi modificado e teve um sistema de arquivos próprio, não foi uma simples alteração de arquivos Makefiles.
Aqui o segundo vídeo:
"Linux Mint 11 64 bits modificado para baixa Latência do sistema!
Meu PC de casa: Core i7 2600k 4.4GHz + 4GB de RAM + ATI HD4850 + Sistema de arquivos ext4 modificado para baixa latência + Gnome 2.32 + Openbox!"
Um core i7 com uma boa placa de vídeo e, de novo, um sistema de arquivos modificado.
E quanto a essas questões:
"Se assim não o fosse, porque teríamos as ferramentas para compilação? E o trabalho que os caras tem de desenvolver novos patchs para melhorar o desempenho?"
respondo com outra questão:
então porque os caras tem o trabalho de desenvolver programas de benchmark?
TODAS as "otimizações" via software que produzem um bom resultado sempre são feitas com um objetivo especifico e isso requer trabalho e estudo.
Porém, tais alterações, mesmo específicas, jamais irão fazer o hardware trabalhar acima da sua capacidade.
Galactus:
Obrigado e concordo.
Mas a diferença é notada com Kernels preparados especificamente para determinados hardwares, não com somente essas alterações feitas no artigo.
E você mesmo fala: "um kernel "preparado" para sua máquina!", ou seja, ratifica o que eu digo, alterações genéricas não surtem efeito no desempenho.
Os patchs são para corrigir e melhorar determinadas deficiências no código e mesmo assim são para determinada versão do Kernel, ou seja, cada versão basicamente tem um patch específico, o que nos leva de novo à conclusão de que alterações genéricas não surtem muito efeito.
Um patch utilizado numa versão errada irá prejudicar o Kernel em vez de melhorar.
E nas conclusões está bem claro que os testes feitos no artigo estão longe de serem conclusivos e que talvez em determinado processador, as alterações sugeridas no artigo tenham um efeito um pouco maior.
Veja a descrição do primeiro vídeo:
"Esta máquina usava um kernel experimental compilado para ela com um sistema de arquivos próprio para essa máquina e o Ubuntu 10.04 também foi modificado. Deu um certo trabalho, mas ficou ótima de usar como pode ver no vídeo. Infelizmente o kernel Ominslash não é mais desenvolvido e o suporte ao Ubuntu 10.04 está acabando. Mas você pode ter algo bem próximo, com um kernel "tunado" e algumas das minhas dicas no tópico: Acelerando o seu sistema Linux sem compilações em computadores e Notebooks."
O sistema foi modificado e teve um sistema de arquivos próprio, não foi uma simples alteração de arquivos Makefiles.
Aqui o segundo vídeo:
"Linux Mint 11 64 bits modificado para baixa Latência do sistema!
Meu PC de casa: Core i7 2600k 4.4GHz + 4GB de RAM + ATI HD4850 + Sistema de arquivos ext4 modificado para baixa latência + Gnome 2.32 + Openbox!"
Um core i7 com uma boa placa de vídeo e, de novo, um sistema de arquivos modificado.
E quanto a essas questões:
"Se assim não o fosse, porque teríamos as ferramentas para compilação? E o trabalho que os caras tem de desenvolver novos patchs para melhorar o desempenho?"
respondo com outra questão:
então porque os caras tem o trabalho de desenvolver programas de benchmark?
TODAS as "otimizações" via software que produzem um bom resultado sempre são feitas com um objetivo especifico e isso requer trabalho e estudo.
Porém, tais alterações, mesmo específicas, jamais irão fazer o hardware trabalhar acima da sua capacidade.
[15] Comentário enviado por galactus em 03/09/2013 - 09:28h
Veja, você falou de alterações "genéricas", mas colocou no artigo uma alteração específica para o seu processador! Depois "Todavia, continuamos, até prova em contrário, com a opinião de que alterações via software para otimizar fisicamente computadores são ilusórias, e não compensam todo o trabalho. Tais alterações podem dar um pequeno ganho em determinado desempenho, porém, no cômputo geral comprovamos que não faz diferença nenhuma."
É estranho, mas você já viu os programas da ASUS para overclock do hardware via software? HÃ? É, software alterando hardware! E a BIOS da placa mãe é software ou hardware? Então o meu Processador projetado para 4GHz, não poderia ser aumentado via software para 4.7GHz!
É claro que compilar kernel não vai te trazer ganhos tão grandes quanto um overclock, mas você usou um software para alterar o seu hardware. Para fazer como numa oficina mecânica, o cara teria que alterar componentes eletrônicos da placa mãe para fazer o sistema render ainda mais. E os caras fazem isso em overclocks pra lá dos 6GHz!
Então dizer que alterações de software trazem ganhos ilusórios não é bem assim!
Veja, você falou de alterações "genéricas", mas colocou no artigo uma alteração específica para o seu processador! Depois "Todavia, continuamos, até prova em contrário, com a opinião de que alterações via software para otimizar fisicamente computadores são ilusórias, e não compensam todo o trabalho. Tais alterações podem dar um pequeno ganho em determinado desempenho, porém, no cômputo geral comprovamos que não faz diferença nenhuma."
É estranho, mas você já viu os programas da ASUS para overclock do hardware via software? HÃ? É, software alterando hardware! E a BIOS da placa mãe é software ou hardware? Então o meu Processador projetado para 4GHz, não poderia ser aumentado via software para 4.7GHz!
É claro que compilar kernel não vai te trazer ganhos tão grandes quanto um overclock, mas você usou um software para alterar o seu hardware. Para fazer como numa oficina mecânica, o cara teria que alterar componentes eletrônicos da placa mãe para fazer o sistema render ainda mais. E os caras fazem isso em overclocks pra lá dos 6GHz!
Então dizer que alterações de software trazem ganhos ilusórios não é bem assim!
[16] Comentário enviado por Buckminster em 03/09/2013 - 09:49h
Galactus:
Bom, pelo visto isso vai longe porque vamos ter que entrar nas definições de Linguagens de Programação de Alto e de Baixo nível.
Mas enfim.
Os progamas da Asus para overclock, assim como todos os programas para overclock na verdade não produzem overclock.
Somente fazem o processador trabalhar na sua capacidade máxima e, novamente, são alterações específicas.
Vamos ter que entrar também na forma como são produzidos os processadores e colocados à venda.
O artigo limita-se somente às alterações feitas no artigo.
No artigo também está bem explícito: "se você alterar um software e este demonstrar melhor desempenho, era porque o código anterior estava aquém da sua capacidade, então, você otimizou apenas o software e não o hardware.
Não podemos esquecer que um computador é feito, basicamente, de software e hardware, bem como o ser humano é feito, basicamente, de corpo e mente."
E no artigo está: "Otimizações via software, de um modo geral, não alteram significativamente o desempenho do hardware."
DE UM MODO GERAL, DE UM MODO GERAL, DE UM MODO GERAL, de um modo geral quer dizer "de um modo geral" e não de um modo específico.
Talvez eu tenha me expresado mal na frase, mas não pensei que teria que explicar o sentido das palavras.
Estamos com um problema aqui de conceitação básica em infomática, mas no fundo estamos falando a mesma coisa.
Galactus:
Bom, pelo visto isso vai longe porque vamos ter que entrar nas definições de Linguagens de Programação de Alto e de Baixo nível.
Mas enfim.
Os progamas da Asus para overclock, assim como todos os programas para overclock na verdade não produzem overclock.
Somente fazem o processador trabalhar na sua capacidade máxima e, novamente, são alterações específicas.
Vamos ter que entrar também na forma como são produzidos os processadores e colocados à venda.
O artigo limita-se somente às alterações feitas no artigo.
No artigo também está bem explícito: "se você alterar um software e este demonstrar melhor desempenho, era porque o código anterior estava aquém da sua capacidade, então, você otimizou apenas o software e não o hardware.
Não podemos esquecer que um computador é feito, basicamente, de software e hardware, bem como o ser humano é feito, basicamente, de corpo e mente."
E no artigo está: "Otimizações via software, de um modo geral, não alteram significativamente o desempenho do hardware."
DE UM MODO GERAL, DE UM MODO GERAL, DE UM MODO GERAL, de um modo geral quer dizer "de um modo geral" e não de um modo específico.
Talvez eu tenha me expresado mal na frase, mas não pensei que teria que explicar o sentido das palavras.
Estamos com um problema aqui de conceitação básica em infomática, mas no fundo estamos falando a mesma coisa.
[17] Comentário enviado por galactus em 03/09/2013 - 10:29h
João:
Bom, pelo visto isso iria longe! Porque já vi que não vamos a lugar nenhum, a pesar de você dizer que estamos falando da mesma coisa.
Antes que isso se transforme num curso de engenharia, antes de nos atermos ainda mais a termos vernaculares, com ou sem o "DE UM MODO GERAL" indicando coisas específicas, eu só posso dar graças que o software e o hardware podem ser livres! E assim sendo livre, podemos tirar nossas conclusões de acordo com o seu uso específico ou "DE UM MODO GERAL"!
Sendo assim eu vou continuar minhas compilações e overclockando meus processadores, mesmo sendo essas compilações, segundo suas conclusões, terem ganhos ilusórios e o meu hardware não poder render mais do que o fabricante assim o determinou!
Até mais e desculpe pela perda do seu tempo!
João:
Bom, pelo visto isso iria longe! Porque já vi que não vamos a lugar nenhum, a pesar de você dizer que estamos falando da mesma coisa.
Antes que isso se transforme num curso de engenharia, antes de nos atermos ainda mais a termos vernaculares, com ou sem o "DE UM MODO GERAL" indicando coisas específicas, eu só posso dar graças que o software e o hardware podem ser livres! E assim sendo livre, podemos tirar nossas conclusões de acordo com o seu uso específico ou "DE UM MODO GERAL"!
Sendo assim eu vou continuar minhas compilações e overclockando meus processadores, mesmo sendo essas compilações, segundo suas conclusões, terem ganhos ilusórios e o meu hardware não poder render mais do que o fabricante assim o determinou!
Até mais e desculpe pela perda do seu tempo!
[18] Comentário enviado por removido em 03/09/2013 - 12:07h
Cavalheiros,
Lógica não precisa de argumentos.
Discutam saudavelmente.
E quando terei uma oportunidade como essa pra tirar uma dúvida? É raro encontrar gente garabaritada reunida.
- Poderiam me responder se overlock diminui a vida do processador?
Já li sobre isso, mas vi divergências quanto às explicações dadas.
Cavalheiros,
Lógica não precisa de argumentos.
Discutam saudavelmente.
E quando terei uma oportunidade como essa pra tirar uma dúvida? É raro encontrar gente garabaritada reunida.
- Poderiam me responder se overlock diminui a vida do processador?
Já li sobre isso, mas vi divergências quanto às explicações dadas.
[19] Comentário enviado por galactus em 03/09/2013 - 12:36h
Olá izaias. Veja que a discussão foi saudável, em nenhum momento um dos dois se agrediu ou proferiu palavras de baixo calão! :)
Só cheguei a conclusão lógica que nada que eu diga, ou que ele diga vai nos fazer mudar de idéia!
Quanto a sua pergunta da vida útil do processador, depende!
Se o seu overclock for feito com componentes que não foram feitos para isso, com certeza a vida útil do seu processador vai diminuir.
Eu tenho um Core i7 com "falso" overclock, segundo o João, de 4.7GHz com um Cooler da Cooler Master, ele é enorme e mantém o meu i7 mesmo com os 4.7 GHZ com menos de 50 graus. Tenho uma placa mãe preparada e desenhada para overclock, com seus reguladores de tensão super dimensionados e as trilhas de cobre reforçadas para isso. Assim eu o tenho a quase 2 anos praticamente ligado 24 por 7 e nenhum pau até agora. Agora, já tive Pentium D em overclcok com placa genérica da Gigabyte que derreteu as trilhas do chipset! kkkkkkkkkkkkk
Então tem que ter hardware que preste para dar condições que não vão forçar ele até queimar. Já perdi duas placas de vídeo com Over, elas não resistem muito a over, mas o processador estando bem resfriado e com boa energia é difícil morrer.
Olá izaias. Veja que a discussão foi saudável, em nenhum momento um dos dois se agrediu ou proferiu palavras de baixo calão! :)
Só cheguei a conclusão lógica que nada que eu diga, ou que ele diga vai nos fazer mudar de idéia!
Quanto a sua pergunta da vida útil do processador, depende!
Se o seu overclock for feito com componentes que não foram feitos para isso, com certeza a vida útil do seu processador vai diminuir.
Eu tenho um Core i7 com "falso" overclock, segundo o João, de 4.7GHz com um Cooler da Cooler Master, ele é enorme e mantém o meu i7 mesmo com os 4.7 GHZ com menos de 50 graus. Tenho uma placa mãe preparada e desenhada para overclock, com seus reguladores de tensão super dimensionados e as trilhas de cobre reforçadas para isso. Assim eu o tenho a quase 2 anos praticamente ligado 24 por 7 e nenhum pau até agora. Agora, já tive Pentium D em overclcok com placa genérica da Gigabyte que derreteu as trilhas do chipset! kkkkkkkkkkkkk
Então tem que ter hardware que preste para dar condições que não vão forçar ele até queimar. Já perdi duas placas de vídeo com Over, elas não resistem muito a over, mas o processador estando bem resfriado e com boa energia é difícil morrer.
[20] Comentário enviado por removido em 03/09/2013 - 12:56h
" Só cheguei a conclusão lógica que nada que eu diga, ou que ele diga vai nos fazer mudar de idéia!"
Mas isso é completamente ilógico. rs
Com relação a manter a conversa saudável, é só por previdência.
-----------------------
Entendi, Marcelo.
Não é o overlock em si que pode diminuir a vida do processador, e sim se ele tem as condições favoráveis para ser overlockado.
É todo o conjunto do hardware que deve fornecer condições para um overlock duradouro e eficiente.
Acho que entendi.
Não tenho interesse direto, é pura curiosidade.
Obrigado!
" Só cheguei a conclusão lógica que nada que eu diga, ou que ele diga vai nos fazer mudar de idéia!"
Mas isso é completamente ilógico. rs
Com relação a manter a conversa saudável, é só por previdência.
-----------------------
Entendi, Marcelo.
Não é o overlock em si que pode diminuir a vida do processador, e sim se ele tem as condições favoráveis para ser overlockado.
É todo o conjunto do hardware que deve fornecer condições para um overlock duradouro e eficiente.
Acho que entendi.
Não tenho interesse direto, é pura curiosidade.
Obrigado!
[21] Comentário enviado por Buckminster em 03/09/2013 - 13:09h
Pensar que clock e desempenho são a mesma coisa é o erro mais comum acerca de processadores.
É coisa de principiante.
E overclock diminui sim a vida do processador, em certos casos diminui pela metade. Porém, um processador é feito para durar, em média, 15 anos. A metade disso dá 7,5 anos. Atualmente é difícil alguém ficar esse tempo todo sem trocar de computador.
O problema é que nesse meio tempo o processador em overclock força outras partes da placa mãe.
Quando um processador é fabricado ele não sai com a frequência de clock exata, ou seja, é fabricado por lotes, ou como preferirem, por "wafers", as famosas bolachas de silício. A Intel, por exemplo, utiliza 'wafers' com 30 cm de diâmetro mais ou menos.
Os próprios fabricantes não sabem a frequência certa de cada processador, o que sabem é somente uma determinada faixa de frequência e a partir dessa faixa são colocados a venda por lotes e denominações.
Nenhum fabricante de processador pode dizer: agora vamos fabricar um processador de 3.0 GHz. Isso é impossível.
Depois de fabricado, é que são medidas as frequências aproximadas de cada lote.
Antes de fabricar, os fabricantes somente podem definir uma certa faixa de frequência, devido ao processo de fabricação.
Assim, um processador de 3.0 GHz, por exemplo, pode trabalhar em 4.0 GHZ, ou até mais. Mas não porque foi dado um 'overclock' nele e sim porque essa é a capacidade real.
E todo dispositivo trabalhando no limite de sua capacidade total, logicamente, diminui a sua vida útil.
E não podemos esquecer que um processador tem dois tipos de 'clocks', o interno e o externo.
Os chamados 'overclocks' em processadores nada mais são do que colocar o processador trabalhando na sua capacidade máxima.
O termo inglês 'overclock' significa 'sobre o clock', além do clock', mais do que o clock', o que por definição é impossível. Overclock nada mais é do que um termo comercial utilizado para definir uma coisa que os filhinhos de papai e bundões gostam de fazer com seus processadores e placas-mãe e placas de vídeo e memórias, etc...
Tanto a Intel quanto a AMD desaconselham o chamado 'overclock'.
E, sinceramente, não sei como argumentar com um cara que diz que derreteu as trilhas do chipset e ainda quer defender os chamados overclocks.
E ainda fala: "Se o seu overclock for feito com componentes que não foram feitos para isso, com certeza a vida útil do seu processador vai diminuir."
Uma afirmação dessas não tem sentido. 'Overclock' por definição é colocar os componentes trabalhando no máximo de sua capacidade.
Componente nenhum é fabricado para 'overclock', senão já sairia de fábrica assim.
Tanto faz se um processador for feito de ouro ou de latão. Hipoteticamente, o de ouro irá durar mais, o de latão menos. Mas se os dois trabalharem em overclock, os dois irão durar menos, cada um dentro de sua capacidade.
A susbstância com que os componentes são fabricados não interessa nada em caso de um dispositivo trabalhar sempre na sua capacidade máxima.
Em relação a ele mesmo, a sua vida útil irá diminuir devido ao desgaste mais acentuado.
E eu não estou dizendo que você, Galactus, deve parar com seus overclocks, continue com eles, os fabricantes agradecem.
Mas não leve a nossa conversa tão a sério.
Estamos aqui para aprender e nada melhor do que aprender podendo dar umas risadas tambem.
Pensar que clock e desempenho são a mesma coisa é o erro mais comum acerca de processadores.
É coisa de principiante.
E overclock diminui sim a vida do processador, em certos casos diminui pela metade. Porém, um processador é feito para durar, em média, 15 anos. A metade disso dá 7,5 anos. Atualmente é difícil alguém ficar esse tempo todo sem trocar de computador.
O problema é que nesse meio tempo o processador em overclock força outras partes da placa mãe.
Quando um processador é fabricado ele não sai com a frequência de clock exata, ou seja, é fabricado por lotes, ou como preferirem, por "wafers", as famosas bolachas de silício. A Intel, por exemplo, utiliza 'wafers' com 30 cm de diâmetro mais ou menos.
Os próprios fabricantes não sabem a frequência certa de cada processador, o que sabem é somente uma determinada faixa de frequência e a partir dessa faixa são colocados a venda por lotes e denominações.
Nenhum fabricante de processador pode dizer: agora vamos fabricar um processador de 3.0 GHz. Isso é impossível.
Depois de fabricado, é que são medidas as frequências aproximadas de cada lote.
Antes de fabricar, os fabricantes somente podem definir uma certa faixa de frequência, devido ao processo de fabricação.
Assim, um processador de 3.0 GHz, por exemplo, pode trabalhar em 4.0 GHZ, ou até mais. Mas não porque foi dado um 'overclock' nele e sim porque essa é a capacidade real.
E todo dispositivo trabalhando no limite de sua capacidade total, logicamente, diminui a sua vida útil.
E não podemos esquecer que um processador tem dois tipos de 'clocks', o interno e o externo.
Os chamados 'overclocks' em processadores nada mais são do que colocar o processador trabalhando na sua capacidade máxima.
O termo inglês 'overclock' significa 'sobre o clock', além do clock', mais do que o clock', o que por definição é impossível. Overclock nada mais é do que um termo comercial utilizado para definir uma coisa que os filhinhos de papai e bundões gostam de fazer com seus processadores e placas-mãe e placas de vídeo e memórias, etc...
Tanto a Intel quanto a AMD desaconselham o chamado 'overclock'.
E, sinceramente, não sei como argumentar com um cara que diz que derreteu as trilhas do chipset e ainda quer defender os chamados overclocks.
E ainda fala: "Se o seu overclock for feito com componentes que não foram feitos para isso, com certeza a vida útil do seu processador vai diminuir."
Uma afirmação dessas não tem sentido. 'Overclock' por definição é colocar os componentes trabalhando no máximo de sua capacidade.
Componente nenhum é fabricado para 'overclock', senão já sairia de fábrica assim.
Tanto faz se um processador for feito de ouro ou de latão. Hipoteticamente, o de ouro irá durar mais, o de latão menos. Mas se os dois trabalharem em overclock, os dois irão durar menos, cada um dentro de sua capacidade.
A susbstância com que os componentes são fabricados não interessa nada em caso de um dispositivo trabalhar sempre na sua capacidade máxima.
Em relação a ele mesmo, a sua vida útil irá diminuir devido ao desgaste mais acentuado.
E eu não estou dizendo que você, Galactus, deve parar com seus overclocks, continue com eles, os fabricantes agradecem.
Mas não leve a nossa conversa tão a sério.
Estamos aqui para aprender e nada melhor do que aprender podendo dar umas risadas tambem.
[22] Comentário enviado por galactus em 03/09/2013 - 15:41h
João, você escreve bonito cara! Parabéns. Tô aprendendo muito com você.
Quanto a você gastar seu argumento com um cara que derretou a sua placa mãe. Fica tranquilo cara. A placa era só minha e só ela foi pro pau! Tenho certeza que não te feriu. Desculpe qualquer ofensa por isso.
Eu defender overclock? Onde eu disse isso? Só porque eu faço?
Cara, como eu disse antes, dou graças que o mundo é livre, se eu quiser marretar o meu i7 e comprar outro, a Intel agradece, não é mesmo?
Fui!
João, você escreve bonito cara! Parabéns. Tô aprendendo muito com você.
Quanto a você gastar seu argumento com um cara que derretou a sua placa mãe. Fica tranquilo cara. A placa era só minha e só ela foi pro pau! Tenho certeza que não te feriu. Desculpe qualquer ofensa por isso.
Eu defender overclock? Onde eu disse isso? Só porque eu faço?
Cara, como eu disse antes, dou graças que o mundo é livre, se eu quiser marretar o meu i7 e comprar outro, a Intel agradece, não é mesmo?
Fui!
[23] Comentário enviado por Buckminster em 03/09/2013 - 15:57h
[22] Comentário enviado por galactus em 03/09/2013 - 15:41h:
João, você escreve bonito cara! Parabéns. Tô aprendendo muito com você.
Quanto a você gastar seu argumento com um cara que derretou a sua placa mãe. Fica tranquilo cara. A placa era só minha e só ela foi pro pau! Tenho certeza que não te feriu. Desculpe qualquer ofensa por isso.
Eu defender overclock? Onde eu disse isso? Só porque eu faço?
Cara, como eu disse antes, dou graças que o mundo é livre, se eu quiser marretar o meu i7 e comprar outro, a Intel agradece, não é mesmo?
Fui!
Não marreta não, dá para eu.
E eu também aprendi com o teu tutorial "Compilando o Kernel otimizado para o seu processador no Ubuntu".
Tem informações interessantes.
[22] Comentário enviado por galactus em 03/09/2013 - 15:41h:
João, você escreve bonito cara! Parabéns. Tô aprendendo muito com você.
Quanto a você gastar seu argumento com um cara que derretou a sua placa mãe. Fica tranquilo cara. A placa era só minha e só ela foi pro pau! Tenho certeza que não te feriu. Desculpe qualquer ofensa por isso.
Eu defender overclock? Onde eu disse isso? Só porque eu faço?
Cara, como eu disse antes, dou graças que o mundo é livre, se eu quiser marretar o meu i7 e comprar outro, a Intel agradece, não é mesmo?
Fui!
Não marreta não, dá para eu.
E eu também aprendi com o teu tutorial "Compilando o Kernel otimizado para o seu processador no Ubuntu".
Tem informações interessantes.
[24] Comentário enviado por adryanohexa em 03/09/2013 - 22:09h
eu to aprendendo muito com esse site viva o linux
eu to aprendendo muito com esse site viva o linux
[25] Comentário enviado por removido em 04/09/2013 - 11:19h
Já vi alguns vídeos no Youtube e Olhar Digital sobre overlock em máquinas de gamers.
O processador era refrigerado a água! E esse tipo de arrefecimento está custando menos hoje. Antes era impossível para classes J,K,Z, como eu. rs
Já vi alguns vídeos no Youtube e Olhar Digital sobre overlock em máquinas de gamers.
O processador era refrigerado a água! E esse tipo de arrefecimento está custando menos hoje. Antes era impossível para classes J,K,Z, como eu. rs
[26] Comentário enviado por hellnux em 04/09/2013 - 14:28h
Belo artigo e obrigado por compartilhar. De certa forma foi até boa essa "discussão", além de aprender mais, serve como termômetro de como a comunidade vem amadurecendo, pois se fosse antigamente, certeza que seria mais feio.
@izaias
Eu mesmo era doido em um watercooler, quase comprei um Antec 620 esses dias por ~R$170.
No início eu tinha computadores da AMD, no clock normal já esquentava que era uma beleza, mas quando mudei para intel nunca mais tive problemas. Os cooler normais seguram bem um processador sem overclock, ainda mais se tiver um gabinete com boa ventilação.
Belo artigo e obrigado por compartilhar. De certa forma foi até boa essa "discussão", além de aprender mais, serve como termômetro de como a comunidade vem amadurecendo, pois se fosse antigamente, certeza que seria mais feio.
@izaias
Eu mesmo era doido em um watercooler, quase comprei um Antec 620 esses dias por ~R$170.
No início eu tinha computadores da AMD, no clock normal já esquentava que era uma beleza, mas quando mudei para intel nunca mais tive problemas. Os cooler normais seguram bem um processador sem overclock, ainda mais se tiver um gabinete com boa ventilação.
[27] Comentário enviado por removido em 04/09/2013 - 15:58h
Há uns 5 anos atrás comprei um PC com gabinete no tipo mini-torre, bonito e cheio de charme!
Burrice!!! Como vai caber uma fonte de maior potência, uma placa de vídeo dedicada?
Agora não, tô com um gabinete aqui que dá até pra morar nele!
Bem ventilado. Permite fazer qualquer upgrade, colocar coolers extras e placas parrudas.
Só estou esperando vencer a garantia pra colocar (não vou romper o lacre do fabricante) minha Corsair e NVidia.
Aí sim. Meu Sper Tux vai voar! rsrsrs
Há uns 5 anos atrás comprei um PC com gabinete no tipo mini-torre, bonito e cheio de charme!
Burrice!!! Como vai caber uma fonte de maior potência, uma placa de vídeo dedicada?
Agora não, tô com um gabinete aqui que dá até pra morar nele!
Bem ventilado. Permite fazer qualquer upgrade, colocar coolers extras e placas parrudas.
Só estou esperando vencer a garantia pra colocar (não vou romper o lacre do fabricante) minha Corsair e NVidia.
Aí sim. Meu Sper Tux vai voar! rsrsrs
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
[30] Comentário enviado por asdf2 em 05/09/2013 - 00:27h
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h:
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
@Buckminster, faz um teste nesse script de compilação do kernel 3.4.60 com a cflag -Ofast, e ve se faz diferença da compilação padrão (sem cflag)
http://sourceforge.net/projects/scriptkernel/files/scriptkernel-3.4.60_AMD_ATHLON64.sh/download
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h:
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
@Buckminster, faz um teste nesse script de compilação do kernel 3.4.60 com a cflag -Ofast, e ve se faz diferença da compilação padrão (sem cflag)
http://sourceforge.net/projects/scriptkernel/files/scriptkernel-3.4.60_AMD_ATHLON64.sh/download
[31] Comentário enviado por Buckminster em 05/09/2013 - 08:19h
[30] Comentário enviado por asdf2 em 05/09/2013 - 00:27h:
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h:
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
@Buckminster, faz um teste nesse script de compilação do kernel 3.4.60 com a cflag -Ofast, e ve se faz diferença da compilação padrão (sem cflag)
http://sourceforge.net/projects/scriptkernel/files/scriptkernel-3.4.60_AMD_ATHLON64.sh/download
"ESPECIFICO para processadores AMD = K8, K10, K10.5" <<< isso está no início do script...
E é para Kernel 3.4.
e de novo voltamos à UM MODO GERAL e um modo específico.
Você leu o artigo e os comentários?
Faça você o teste, se eu fizer e falar que não deu diferença nenhuma você não vai acreditar em mim.
E você leu o script?
Você viu o que o script faz?
[30] Comentário enviado por asdf2 em 05/09/2013 - 00:27h:
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h:
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
@Buckminster, faz um teste nesse script de compilação do kernel 3.4.60 com a cflag -Ofast, e ve se faz diferença da compilação padrão (sem cflag)
http://sourceforge.net/projects/scriptkernel/files/scriptkernel-3.4.60_AMD_ATHLON64.sh/download
"ESPECIFICO para processadores AMD = K8, K10, K10.5" <<< isso está no início do script...
E é para Kernel 3.4.
e de novo voltamos à UM MODO GERAL e um modo específico.
Você leu o artigo e os comentários?
Faça você o teste, se eu fizer e falar que não deu diferença nenhuma você não vai acreditar em mim.
E você leu o script?
Você viu o que o script faz?
[32] Comentário enviado por asdf2 em 05/09/2013 - 12:15h
[31] Comentário enviado por Buckminster em 05/09/2013 - 08:19h:
[30] Comentário enviado por asdf2 em 05/09/2013 - 00:27h:
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h:
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
@Buckminster, faz um teste nesse script de compilação do kernel 3.4.60 com a cflag -Ofast, e ve se faz diferença da compilação padrão (sem cflag)
http://sourceforge.net/projects/scriptkernel/files/scriptkernel-3.4.60_AMD_ATHLON64.sh/download
"ESPECIFICO para processadores AMD = K8, K10, K10.5" <<< isso está no início do script...
E é para Kernel 3.4.
e de novo voltamos à UM MODO GERAL e um modo específico.
Você leu o artigo e os comentários?
Faça você o teste, se eu fizer e falar que não deu diferença nenhuma você não vai acreditar em mim.
E você leu o script?
Você viu o que o script faz?
Li sim, não é especifico para amd não, na hora que aparece o menuconfig, basta escolher sua arquitetura exata
[31] Comentário enviado por Buckminster em 05/09/2013 - 08:19h:
[30] Comentário enviado por asdf2 em 05/09/2013 - 00:27h:
[29] Comentário enviado por Buckminster em 04/09/2013 - 23:22h:
[28] Comentário enviado por asdf2 em 04/09/2013 - 22:50h:
Acompanhei o artigo do kernel omnslash por muito tempo, e refazia todos os testes escrito la com ou sem paths ou só com cflags, te GARANTO, o galactus está completamente correto em suas afirmações, pode confiar
Tu dando palpite por aqui de novo... mas que satisfação!!!
@Buckminster, faz um teste nesse script de compilação do kernel 3.4.60 com a cflag -Ofast, e ve se faz diferença da compilação padrão (sem cflag)
http://sourceforge.net/projects/scriptkernel/files/scriptkernel-3.4.60_AMD_ATHLON64.sh/download
"ESPECIFICO para processadores AMD = K8, K10, K10.5" <<< isso está no início do script...
E é para Kernel 3.4.
e de novo voltamos à UM MODO GERAL e um modo específico.
Você leu o artigo e os comentários?
Faça você o teste, se eu fizer e falar que não deu diferença nenhuma você não vai acreditar em mim.
E você leu o script?
Você viu o que o script faz?
Li sim, não é especifico para amd não, na hora que aparece o menuconfig, basta escolher sua arquitetura exata
[33] Comentário enviado por Buckminster em 05/09/2013 - 14:36h
É verdade, você tem razão, não é específico para AMD.
Mas é para Kernel 3.4.
E para eu fazer um teste teria que instalar esse kernel e aplicar o script e ando sem tempo agora.
É verdade, você tem razão, não é específico para AMD.
Mas é para Kernel 3.4.
E para eu fazer um teste teria que instalar esse kernel e aplicar o script e ando sem tempo agora.
[34] Comentário enviado por meinhardt_jgbr em 08/09/2013 - 14:55h
Excelente o artigo!! Parabéns!!
Muito didático e de grande valor para desmistificar a dificuldade em fazer uma re-compilação de kernel.
Usuário Linux tipico, mesmo sabendo de varias fontes que as alterações do desempenho serão negligenciáveis, no minimo por curiosidade vai tentar algum dia.
Além de satisfazer a curiosidade, a satisfação depois de concluído o trabalho não tem preço, principalmente para aqueles que já foram "futricadores" em outros S.O.s e não conseguiam chegar tão longe.
Sem duvida vale um 10!!
Excelente o artigo!! Parabéns!!
Muito didático e de grande valor para desmistificar a dificuldade em fazer uma re-compilação de kernel.
Usuário Linux tipico, mesmo sabendo de varias fontes que as alterações do desempenho serão negligenciáveis, no minimo por curiosidade vai tentar algum dia.
Além de satisfazer a curiosidade, a satisfação depois de concluído o trabalho não tem preço, principalmente para aqueles que já foram "futricadores" em outros S.O.s e não conseguiam chegar tão longe.
Sem duvida vale um 10!!
[35] Comentário enviado por Buckminster em 09/09/2013 - 11:16h
[34] Comentário enviado por meinhardt_jgbr em 08/09/2013 - 14:55h:
Excelente o artigo!! Parabéns!!
Muito didático e de grande valor para desmistificar a dificuldade em fazer uma re-compilação de kernel.
Usuário Linux tipico, mesmo sabendo de varias fontes que as alterações do desempenho serão negligenciáveis, no minimo por curiosidade vai tentar algum dia.
Além de satisfazer a curiosidade, a satisfação depois de concluído o trabalho não tem preço, principalmente para aqueles que já foram "futricadores" em outros S.O.s e não conseguiam chegar tão longe.
Sem duvida vale um 10!!
Muito obrigado pelo comentário.
[34] Comentário enviado por meinhardt_jgbr em 08/09/2013 - 14:55h:
Excelente o artigo!! Parabéns!!
Muito didático e de grande valor para desmistificar a dificuldade em fazer uma re-compilação de kernel.
Usuário Linux tipico, mesmo sabendo de varias fontes que as alterações do desempenho serão negligenciáveis, no minimo por curiosidade vai tentar algum dia.
Além de satisfazer a curiosidade, a satisfação depois de concluído o trabalho não tem preço, principalmente para aqueles que já foram "futricadores" em outros S.O.s e não conseguiam chegar tão longe.
Sem duvida vale um 10!!
Muito obrigado pelo comentário.
[36] Comentário enviado por rudregues em 06/01/2014 - 18:00h
Gostei da parte dos benchmarks, usou a phoronix-test-suite e hardinfo inclusive. Tem gente que acha que compilar ao invés de usar binário vai trazer diferenças perceptíveis, quando na maioria dos casos não traz. O que faz diferença é configurar corretamente o sistema e ir tunando com patches etc.
Comentários também interessantes, mas sobre o termo overclocking, acredito que signifique apenas "trabalhando acima do clock padrão". Compro um pc que tem um clock default, se eu aumentar eu overclockeei, apenas isto. Não está indo "além da frequência suportada", mas sim, "além da frequência padrão".
No mais, parabéns pelo artigo, com certeza demorou bastante pra escrever (dedicação!)
Gostei da parte dos benchmarks, usou a phoronix-test-suite e hardinfo inclusive. Tem gente que acha que compilar ao invés de usar binário vai trazer diferenças perceptíveis, quando na maioria dos casos não traz. O que faz diferença é configurar corretamente o sistema e ir tunando com patches etc.
Comentários também interessantes, mas sobre o termo overclocking, acredito que signifique apenas "trabalhando acima do clock padrão". Compro um pc que tem um clock default, se eu aumentar eu overclockeei, apenas isto. Não está indo "além da frequência suportada", mas sim, "além da frequência padrão".
No mais, parabéns pelo artigo, com certeza demorou bastante pra escrever (dedicação!)
[37] Comentário enviado por Buckminster em 06/01/2014 - 20:49h
[36] Comentário enviado por rudregues em 06/01/2014 - 18:00h:
Gostei da parte dos benchmarks, usou a phoronix-test-suite e hardinfo inclusive. Tem gente que acha que compilar ao invés de usar binário vai trazer diferenças perceptíveis, quando na maioria dos casos não traz. O que faz diferença é configurar corretamente o sistema e ir tunando com patches etc.
Comentários também interessantes, mas sobre o termo overclocking, acredito que signifique apenas "trabalhando acima do clock padrão". Compro um pc que tem um clock default, se eu aumentar eu overclockeei, apenas isto. Não está indo "além da frequência suportada", mas sim, "além da frequência padrão".
No mais, parabéns pelo artigo, com certeza demorou bastante pra escrever (dedicação!)
Obrigado.
Sim, você está com a razão. Coloquei mal no artigo de acordo com as expressões correntes. Ir além da frequência suportada é impossível, pois isso implicaria, por analogia, dizer que um fusquinha 69 vai correr a 300 Km/h.
O certo é "além da frequência padrão".
[36] Comentário enviado por rudregues em 06/01/2014 - 18:00h:
Gostei da parte dos benchmarks, usou a phoronix-test-suite e hardinfo inclusive. Tem gente que acha que compilar ao invés de usar binário vai trazer diferenças perceptíveis, quando na maioria dos casos não traz. O que faz diferença é configurar corretamente o sistema e ir tunando com patches etc.
Comentários também interessantes, mas sobre o termo overclocking, acredito que signifique apenas "trabalhando acima do clock padrão". Compro um pc que tem um clock default, se eu aumentar eu overclockeei, apenas isto. Não está indo "além da frequência suportada", mas sim, "além da frequência padrão".
No mais, parabéns pelo artigo, com certeza demorou bastante pra escrever (dedicação!)
Obrigado.
Sim, você está com a razão. Coloquei mal no artigo de acordo com as expressões correntes. Ir além da frequência suportada é impossível, pois isso implicaria, por analogia, dizer que um fusquinha 69 vai correr a 300 Km/h.
O certo é "além da frequência padrão".
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Enviar mensagem ao usuário trabalhando com as opções do php.ini
Meu Fork do Plugin de Integração do CVS para o KDevelop
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Compartilhamento de Rede com samba em modo Público/Anônimo de forma simples, rápido e fácil
Cups: Mapear/listar todas as impressoras de outro Servidor CUPS de forma rápida e fácil
Criando uma VPC na AWS via CLI
Tópicos
xubuntu sem sons de eventos (3)
Erro ao iniciar serviço samba4 como novo dc em um ambiente com ad (9)
Dificuldade para renderizar vídeo no kdenlive (5)
Top 10 do mês
-
Xerxes
1° lugar - 67.021 pts -
Fábio Berbert de Paula
2° lugar - 49.667 pts -
Renato Michnik de Carvalho
3° lugar - 27.289 pts -
Buckminster
4° lugar - 17.767 pts -
Mauricio Ferrari
5° lugar - 15.105 pts -
Alberto Federman Neto.
6° lugar - 14.037 pts -
Diego Mendes Rodrigues
7° lugar - 13.788 pts -
Daniel Lara Souza
8° lugar - 13.604 pts -
edps
9° lugar - 11.532 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 11.046 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
