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.

Buckminster

Por Buckminster em 02/09/2013

Hits: 49.132 Categoria: Linux Subcategoria: Kernel

Parte 7: Conclusões

A primeira conclusão a que se chega, é que aquelas "otimizações" do kernel não fazem muita diferença no desempenho. Talvez o lado psicológico tenda a dizer o contrário e o "olhômetro", diga que a inicialização ficou mais rápida, as janelas abrem mais rápidas, etc.

Os testes feitos neste artigo podem ser repetidos em casa, por quem tiver interesse.

Otimizações via software, de um modo geral, não alteram significativamente o desempenho do hardware. Talvez, o que confunda os usuários, é o fato de raciocinar que se um vírus pode travar a máquina e um ataque DoS pode derrubar um servidor, e um vírus, grosso modo, é um software e um ataque DoS é feito por um software também, a conclusão aparentemente lógica seria raciocinar que o contrário também é válido, ou seja, um software pode acelerar a máquina.

Porém, este raciocínio é ilusório. Analogamente, seria como você colocar combustível de avião num fusca e querer que ele corra a 300 quilômetros por hora. É fisicamente impossível. O motor dele não é feito para correr tanto. Porém, se você colocar gasolina adulterada, ou suja, no mesmo fusca (ou até em uma Ferrari), ele irá "travar".

Ainda que alguém argumente que as mudanças no kernel não aceleram a máquina, mas somente extraem todo o potencial do processador, argumentamos de volta dizendo que, se os processadores comerciais fossem de total arquitetura RISC, aí concordaríamos, mas não é o caso. Os processadores comerciais vêm com suas instruções prontas e fechadas, ou seja, você não pode programar diretamente no processador.

Alterando o kernel com melhorias, você estará somente "otimizando" o próprio kernel, nada mais. Alguém pode alegar que otimizando o kernel estará melhorando o desempenho geral de todo o computador. Contudo, não podemos esquecer que o kernel é feito para suportar as mais variadas arquiteturas de hardware e alterando uma parte do código sem ter conhecimento, pode estar causando detrimento em outra parte.

Também foram feitos testes no kernel nativo do Debian Wheezy (3.2.0-4-amd64) sem alterações e apresentaram resultados semelhantes em desempenho.

Os testes realizados nas três máquinas apresentaram resultados semelhantes, uma hora tendendo para o Kernel 'Sem', outra hora para o Kernel 'Com', porém, sempre com diferenças não muito significativas entre eles. É claro que estes testes, apesar de feitos com seriedade, estão longe de serem conclusivos. Talvez em determinado processador, as alterações sugeridas neste artigo tenham um efeito um pouco maior.

Os programas de testes utilizados no artigo foram escolhidos tendo em vista serem confiáveis e plenamente satisfatórios ao que se propõem. A escolha do teste Complex foi uma escolha lógica, uma vez que são realizados vários teste abrangentes. A escolha do teste Kernel no Phoronix, também foi uma escolha lógica.

Para fins de aprendizado, é válido ter esse trabalho todo de alterar 15 arquivos Makefile do kernel. Para quem estuda as linguagens de programação C e Shell Script, entre outras, mexer nos arquivos do kernel é um prato cheio.

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.

Para melhor esclarecimento, 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.

Links para otimizações e Linus x Lennart:

Links para testes Phoronix:

Páginas do artigo

   1. Introdução
   2. Configurando e otimizando
   3. Compilando e otimizando
   4. Testando
   5. Suíte de testes Kernel
   6. Hardinfo
   7. Conclusões

Outros artigos deste autor

Instalação Completa e Configuração Básica do Void Linux

IPv6, DNSv6 e DHCPv6

Configuração do sistema, DHCP, compartilhamento e DNS no Debian Squeeze

Manual traduzido do Squid - Parte 3

Instalar e Configurar a santíssima trindade (PAP) no Void Linux

Leitura recomendada

Gerência e criação de módulos do kernel

Instalando kernel otimizado do Ubuntu no Asus eeepc

Instalando o kernel 2.6.13 pré-compilado no Slackware 10.2

Como compilar o kernel Linux 2.6.31.1

Kernel atualizado no Debian - Parte II

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.

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

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

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

#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?"

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

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

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

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

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

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

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

#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á!

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

#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!

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

#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!

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

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

#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!

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

#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!

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

#24 Comentário enviado por adryanohexa em 03/09/2013 - 22:09h

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

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

#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

#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

#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!!!

#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

#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?

#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

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

#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!!

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

#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!)

#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".

Parte 7: Conclusões

Páginas do artigo

Outros artigos deste autor

Leitura recomendada

Comentários

Contribuir com comentário