kernel Linux otimizado - Compilação e teste

Buckminster

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.741 ]

Por: Buckminster em 02/09/2013

4 0

Denuncie Favoritos Indicar Impressora

Configurando e otimizando

# make menuconfig # Entra nas configurações do kernel

Para entrar nas opções, dê Enter e para alterar de "M" para "*", e vice-versa, é só pressionar a barra de espaços.

Para sair de uma opção, dê Esc duas vezes seguidas.

Vá em: Processor type and features → Processor Family (Generic-x86-64)

...e marque (barra de espaços) a opção que corresponde ao processador da sua máquina. No meu caso, mesmo sendo um processador Intel Pentium Dual E2140, marquei Core 2/newer Xeon, por ele ter dois núcleos (Cores).

Mais abaixo, vá em: "Preemption Model (Voluntary Kernel Preemption (Desktop))" e se for Desktop, deixe marcada a opção Desktop. Se for servidor, marque "No Forced Preemption (Server)".

No Dual-Core ficou "Desktop", e no Core 2 Quad, ficou "Server".

Mais abaixo, vá em "Timer frequency". Se a sua instalação for do tipo servidor, marque a opção "100 HZ" (isso melhorará o tempo de resposta do servidor para as requisições). Para Desktop, deixe "250 HZ".

No Dual-Core ficou "250 HZ", no Core 2 Quad, ficou "100 HZ".

Retorne ao menu principal: Esc + Esc

Caso seja um servidor, é aconselhável marcar as opções abaixo. Caso seja Desktop, você pode pular para "File Systems".

Vá em: Networking support → Networking options → Network packet filtering framework (netfilter) → IP: Netfilter Configuration

Verifique se "IPv4 connection tracking support (required for NAT)" está marcada.

Mais abaixo, marque a opção: "IPv4 NAT (NEW)". E as seguintes opções abaixo aparecerão já marcadas:

MASQUERADE target support
NETMAP target support
REDIRECT target support

Tecle: Esc + Esc

Vá em IPv6: "Netfilter Configuration" e marque:

IPv6 NAT
MASQUERADE
NPT

Tecle: Esc + Esc

Volte ao menu principal: Esc + Esc, Esc + Esc e Esc + Esc

Vá em "File Systems", marque os sistemas de arquivos utilizados com "*". No meu caso, ext4 (todas as partições) para o Desktop e ext4 (/boot) com btrfs (demais partições) para o servidor.

* Dica: para ext4, marque a primeira opção (The Extended 4 (ext4) filesystem) com "*", e deixe somente as duas seguintes marcadas. Ficarão 3 opções marcadas.

Para btrfs, ficarão três opções também:

Btrfs filesystem support;
Btrfs POSIX Access Control Lists e
Btrfs will run sanity tests upon loading.

Mais abaixo, vá em: "Network File Systems"

E se for servidor, coloque um "*" na opção "NFS server support".

Volte: Esc + Esc

Logo abaixo, vá em "Native language support" e marque com "*", as opções:

Codepage 860 (Portuguese)
  ASCII (United...)
  NLS 8859-1 (Latin 1, ...)
  NLS UTF-8

Retorne ao menu principal dando EXIT. Após o último EXIT, aparecerá a janela "Do you wish...", deixe como: "Yes" e dê Enter.

Execute:

# ls -a

E veja se o arquivo ".config" foi gravado. Se não, repita a operação.

Agora, vamos alterar os arquivos necessários para otimizar a compilação de acordo com o processador da máquina:

# cc -march=native -E -v - &1 | grep cc1

Veja a figura 1, com a saída desse comando.

Vamos alterar os arquivos (segue uma lista completa dos arquivos com as linhas a serem alteradas). É necessário alterar somente 5 arquivos (os 5 primeiros abaixo), porém, se você é paranoico e obcecado, altere os outros 10 também:

* Importante: em todos os arquivos, altere as opções "march" para "-march=native", as opções "mcpu" para "-mcpu=native" e as opções "mtune" para "mtune=nome_do_processador". Nesta última opção, "mtune", coloque o que aparecer na saída do comando cc -march=native -E -v - &1 | grep cc1. No caso do Core 2 Quad e do Dual-Core, ficou "-mtune=core2". No caso dos Pentium 4, ficou "-mtune=nocona".

Se a versão do GCC for 4.5.1, inclusive, para baixo, deixe "-mtune=generic". Como anteriormente instalamos e atualizamos a versão do GCC (o GCC, o G++ e o MAKE, entre outros, estão no pacotão "build-essential"), não precisa se preocupar muito com isso. A não ser que seu sistema e seu hardware sejam bem antigos.

Lista de arquivos:

/usr/src/Linux-3.10.7/Makefile - linha 244;
/usr/src/Linux-3.10.7/arch/x86/boot/compressed/Makefile - linha 12;
/usr/src/Linux-3.10.7/arch/x86/boot/Makefile - linha 59;
/usr/src/Linux-3.10.7/arch/x86/Makefile - linhas 64, 65, 68, 69, 70 e 71;
/usr/src/Linux-3.10.7/arch/x86/Makefile_32.cpu - linhas 5, 13 à 22, 25 à 36, 39, 42, 43, 46 e 69.

Neste último arquivo acima, atenção especial na linha 46 "cflags-$(CONFIG_X86_GENERIC += $(call tune,generic,$(call tune,i686))", que deverá ficar assim:

cflags-$(CONFIG_X86_GENERIC += $(call tune,core2,$(call tune,core2))

Este arquivo de número 5, é o que supostamente otimizará a compilação para o processador da máquina.

A partir daqui, continue se quiser extrair mais, mas preste atenção para alterar os arquivos da forma certa.

O único arquivo que dará mensagem em caso de erro, é o "/usr/src/Linux-3.10.7/Makefile", então, faça com calma, cuidado e divirta-se.

/usr/src/Linux-3.10.7/arch/alpha/Makefile - linhas 18 à 24 e 29;
/usr/src/Linux-3.10.7/arch/arm/Makefile - linhas 62, 63, 67, 69 à 72 e 75 à 92;
/usr/src/Linux-3.10.7/arch/avr32/Makefile - linha 19;
/usr/src/Linux-3.10.7/arch/frv/Makefile - linhas 58, 59, 62, 63, 65 e 66;
/usr/src/Linux-3.10.7/arch/m68k/Makefile - linhas 44 à 59;
/usr/src/Linux-3.10.7/arch/mips/Makefile - linha 125 à 159;
/usr/src/Linux-3.10.7/arch/parisc/Makefile - linhas 69 à 73;
/usr/src/Linux-3.10.7/arch/powerpc/Makefile - linhas 91 à 96, 98 e 132;
/usr/src/Linux-3.10.7/arch/s390/Makefile - linhas 38 à 44;
/usr/src/Linux-3.10.7/arch/sparc/Makefile - linhas 27, 40, 43 e 44.

Alterando

Estando dentro de "/usr/src/Linux-3.10.7", vamos alterar:

# vim Makefile # Usei o Vim, use o teu editor de texto preferido

Seguem imagens com antes e depois da alteração.

Não vou colocar imagens de todos os arquivos, mas somente alguns para ilustração e entendimento, pois uma imagem vale mais do que mil palavras.

Figura 2 - /usr/src/Linux-3.10.7/Makefile antes

Figura 3 - /usr/src/Linux-3.10.7/Makefile depois

Figura 4 - /usr/src/Linux-3.10.7/arch/x86/Makefile_32.cpu antes

Figura 5 - /usr/src/Linux-3.10.7/arch/x86/Makefile_32.cpu depois

Terminadas as alterações nos arquivos "Makefile", vamos exportar algumas variáveis que parecem interessantes. Antes de executar os três comandos abaixo, leia o que significa cada opção, porém, a exportação dessas variáveis é opcional e não fará muita diferença.

# export CONCURRENCY_LEVEL=2 # Aqui usei o valor 2, pois é o número de cores (núcleos) do processador. No caso do Core 2 Quad, usei o valor 4; veja o número de núcleos com o comando cat /proc/cpuinfo | less

# export CFLAGS="-march=native -O2 -pipe"
# export CXXFLAGS="$CFLAGS"

A partir de agora, se você fechar o terminal, ao abri-lo de novo, deverá executar os três comandos acima novamente, pois as alterações serão perdidas.

Explicando:

CONCURRENCY_LEVEL :: setar esta variável com o número de núcleos de sua CPU, ele usará todos eles ao compilar o kernel.
CFLAGS :: são flags de compilação, principalmente para a otimização dos binários. As versões mais recentes do GCC, podem detectar automaticamente esses recursos, porém, definindo-os como "native" será adequado na maioria dos casos. A opção "-march" permite que o GCC compile o código tirando proveito de qualquer característica de sua CPU. As opções "-02" e "-pipe", são outras flags de otimização. Há mais flags, mas estas são as "genéricas" utilizadas, que oferecem uma suposta quantidade de benefícios.
CXXFLAGS :: são opções extras para o GCC, normalmente você pode configurá-las para CFLAGS.

Página anterior Próxima página

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

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

Instalação do Comodo Antivirus para Linux (CAVL) resolvendo o problema de dependências

Manual traduzido do Squid

Atualizar o macOS no Mac - Opencore Legacy Patcher

Instalação do PAP (PostgreSL, Apache2 e PHP7) no Debian Jessie

Leitura recomendada

Como instalar/atualizar seu kernel

Compilando o KERNEL sem medo do "kernel panic"

Experimento com Linux: Misturando Sabayon com Gentoo

Compilar e habilitar os módulos ip_table e iptable_nat no kernel 2.6.26 no Debian Linux

Compilando ou atualizando um kernel Linux

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.

1 0

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

1 0

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

0 0

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

0 0

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

1 0

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

0 0

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

1 0

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

0 0

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

1 0

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

1 0

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

0 0

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

0 0

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

1 0

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

0 0

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

1 0

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

0 0

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

1 0

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

0 0

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

1 0

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

0 0

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

0 0

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

1 0

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

0 0

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

eu to aprendendo muito com esse site viva o linux

0 0

[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

0 0

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

0 0

[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

0 0

[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

0 0

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

0 0

[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

1 0

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

0 0

[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

1 0

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

0 0

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

1 0

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

0 0

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

0 0

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

0 0