Kernel Omnislash (Unofficial) - Aprendendo a voar sem segredos!!!

[4d4c47]

o kernel 2.6.36 com o patch ck2 (con koliva), com BFS 357, ficou perfeito, vale a pena testar

[macabu]

Galactus, como vc faz para compilar tão rápido?

É como o HQ disse, Core i7 a 3.6GHz, 4GB de RAM a 1400MHz, Concurrency Level 8 com o kernel do HQ que realmente usa os 100% dos núcleos mais os HTs! Além disso meu Ubuntu é muito mexido! Sabe como é, geralmente tudo que é padrão é lento!  Há sim, ia me esquecendo, a minha nova placa mãe ajuda muito também! Ela não tem mais IDE e nem PS2! Com isso os HDs SATA guanham de 15 a 18% em velocidade!  

Galactus, qual é o comando que vc usa na hora de compilar?

Um amigo meu comprou um notebook da HP com i7 e 6GB de RAM (uma única placa, diga-se de passagem, que deixou todo mundo surpreso)
Eu também comprei um novo, também da HP, mas um Phenon Triple-core, e quero ver se consigo melhorar também um pouco mais o tempo de compilação.

A propósito, como eu verifico a frequência do processador?

PS: não achei esse seu post citado na busca e tive de ir rolando páginas e páginas 

Boa tarde Vampire, o comando é o mesmo do tutorial do HQxriven!

Código: [Selecionar]

#CONCURRENCY_LEVEL=2 make-kpkg --initrd --revision=x86 kernel_image kernel_headers modules_image
A diferença é que eu coloco o número de núcleos que o sistema "vê"! No meu caso são os 4 núcleos físicos mais os 4 virtuais do HT!  Então fica assim:

Código: [Selecionar]

#[b]CONCURRENCY_LEVEL=8[/b] make-kpkg --initrd --revision=x86 kernel_image kernel_headers modules_image
Desligo qualquer outra coisa que possa consumir recurso do sistema, então fica só a compilação do sistema rolando, as vezes deixo o Htop pra ver a todos os núcleos a 100%! 

Quanto ao tempo menor é por causa do Overclock, das memórias ( agora estou com DDR3 2000) e do HD! Tudo ajuda!

 

Desculpa a quotagem gigante, mas eu compilei 2x sem notar isso, sempre compilava usando 2 núcleos físicos, sendo que tenho 4 T-T
Alguém poderia me indicar como atualizar esse BFS, como funciona isso?
[]s

[Hqxriven]

Senhoras e Senhores, esperei mais de uma semana para postar as considerações "totais" sobre o BFS 357!


É sempre bom fazer testes de maior duração em diversos cenários para ter certeza que tudo melhora ou não, não é mesmo?

Continuando então, a primeira vista como havia dito, com a nova compilação com os patchs do Ureheadaread e do BFS 357,  o meu PC havia ficado ainda mais rápido!

O 357 usa ainda mais do cache da memória, então na segunda vez que você chamava alguma aplicação ele se mostrava mais "agressivo" que a versão 318 usada originalmente pelo HQxRiven no Omnislash (se não estou enganado da versão)!  De qualquer maneira, a versão 357 mostrava resultados promissores em relação a versão anterior!  

O consumo de RAM do sistema é maior, o 357 é ainda mais guloso no quesito consumo de memória! No entanto ele usa esse aumento do consumo para deixar a reposta do sistema mais agressiva!

No meu teste de "longo prazo", quando digo isso quero dizer usar o sistema com várias aplicações abertas ao mesmo tempo e deixar o sistema ligado por pelo menos 3 dias direto sem reiniciar ou sair da sessão, o 357 começou a fazer água!

Além do maior consumo de RAM notei uma maior latência ao responder quando chamando as aplicações depois de muito tempo que ela foi fechada!  O que me mostrou que ele não guarda muito tempo no cache aplicações que já foram chamadas faz tempo!

Quando na hora do fervo, com muita coisa agindo ao mesmo tempo no sistema, o consumo de CPU também me pareceu maior e algumas aplicações passaram a fechar do "nada", como o Nautilus e o Rhythmbox. Isso com o sistema ligado por mais de  3 dias! Coisa que não acontecia com o 318!    Contudo, como disse, a resposta do sistema sempre foi mais rápida com o 357! Principalmente se você ficar abrindo e fechando várias aplicações com pouco intervalo de tempo entre o fechar e abrir novamente à aplicação!  Aquele teste básico que faço nos meus vídeos, parecem ainda mais "leves" com o 357, ele responde mais rápido a custa de maior consumo de RAM e CPU!


Outra coisa, com mais de 3 dias do sistema ligado direto, o sistema começa a ficar mais lento! Ele não tem a mesma resposta de quando você acaba de ligar o seu PC!
 
Mas a pá de cal para mim foi no quesito transferência de arquivos!  O 357 sofre do mesmo Bug da versão original do 318 que haviamos identificado, avisei o HQx e ele resolveu o problema da transferência de arquivos!  O que acontecia  com o 318 era o seguinte, se fizer transferência de arquivos para um PenDrive, ele começa rápido e depois praticamente congela a transferência, vai de "soquinho", transfere um pouco e pára, transfere mais um pouco e pára novamente! Enquanto isso o sistema fica uma "derma" só!  Se arrasta!  Com o 357 a coisa é muito pior!  Leva quase meia hora para transferir uma imagem de 4GB para o meu Pen Drive de 8G Kingston Datatraveler! Que é muito rápido, dá mais de 20MB/s de taxa fixa na transferência normal!

Muito pior que isso, agora ele afeta drasticamente a transferência na rede também!  Quem tem visto minha briga para aumentar as taxas de transferência da minha rede gigabit doméstica, lá na sessão de servidores, viu que já consegui 52MB/s fixos com ela!  Com o 357 isso não me pertence mais!  Cai para taxas de rede 10/100!  10MB/s com o famigerado "soquinho"!  Uma bomba para transferência de arquivos!

Foi só fazer uma nova compilação com o 318 modificado pelo HQx que tudo voltou ao normal!

Ainda pretendo testar com o Atom, mas já espero um verdadeiro desastre! Já que o Atom não tem recursos, esse aumento no consumo da RAM e no uso da CPU vão fazer o sistema atingir o seu limite muito mais cedo! O problema é que esses processadores potentes tendem a te enganar logo de início! Parece tudo muito bom, tudo muito bem, mas quando você começar a testar em vários cenários diferentes a coisa muda de figura!  Só velocidade não resolve!

Bom , isso foi com o  meu hardware! Seria bom que outros compiladores contumases postassem suas impressões sobre o 357!

Té+

Percebi a mesma coisa, mas estava esperando o seu post...

Latência baixa atrapalhando a cache e fazendo besteiras no sistema.

No 1.4.4 eu consegui corrigir agora erraram novamente... o 3.57 para server sem alteraçãoes não rola...

Então pra mim é muito relevante se um Kernel consegue ser estável com vários dias ligados!  Se não estou enganado até o HQxRiven faz esse tipo de teste!  

Com ctz... Se ele não tem estabilidade com alguns dias ligado significa para mim que não presta... (resumindo um kernel que não aguenta e uma hora vai dar problema)

Não me lembro se no PC do HQx isso também ocorria.

Ocorria... "soquinhos" de pen drive é chato...

Foi um saco consertar aquilo, passei uma noite e uma madrugada consertando aquilo fazendo a latência e a cache não "brigarem".

Vou ter que tirar um tempo para analisar aonde o BFS foi "com sede ao pote" no 3.57 para alterar e consertar.


@macabu

Alguém poderia me indicar como atualizar esse BFS, como funciona isso?

http://ubuntuforum-br.org/index.php/topic,29799.msg418361.html#msg418361

[Gunss]

engraçado, aqui o novo BFS não alterou o desempenho do PC com muito tempo ligado. Aqui ele ta ligado tem 8 dias e tudo tranquilo.

[macabu]

Eu li e também vi sobre o Ureadahead e baixei.
Quando na hora da compilação eu uso o comando?
Abçs

[Hqxriven]

engraçado, aqui o novo BFS não alterou o desempenho do PC com muito tempo ligado. Aqui ele ta ligado tem 8 dias e tudo tranquilo.

Então deve existir algo aí diferente que faz não aparecer o bug. Pq eu testei em das máquinas e ele apareceu...

Acho que se nós três batermos um papo descobriremos isso.

@Gunss e Galactus vcs estão usando apenas o BFS como patch (estão usando o ck também)?? Estão usando em que kernel?? Quais outros patches vcs estão usando?? (Acho que se formos pelo caminho iremos descobrir o vilão... ou pelo menos melhorar o resultado)

Boa Tarde meus amigos!!

Obrigado

Hqx

[Gunss]

engraçado, aqui o novo BFS não alterou o desempenho do PC com muito tempo ligado. Aqui ele ta ligado tem 8 dias e tudo tranquilo.

Então deve existir algo aí diferente que faz não aparecer o bug. Pq eu testei em das máquinas e ele apareceu...

Acho que se nós três batermos um papo descobriremos isso.

@Gunss e Galactus vcs estão usando apenas o BFS como patch (estão usando o ck também)?? Estão usando em que kernel?? Quais outros patches vcs estão usando?? (Acho que se formos pelo caminho iremos descobrir o vilão... ou pelo menos melhorar o resultado)

Boa Tarde meus amigos!!

Obrigado

Hqx

bem. o kernel é o 2.6.34. Estou usando o omnislash original + o bfs 0.357. Não estou usando o patch do CK, somente o BFS.

Vamos bater um papo. Agora uma coisa sobre o BFS 0.357. Não é preciso ficar com o PC ligado por muito tempo para ver ele se atrapalhar com essa pressa toda. Basta abri vários programas ao mesmo tempo. Se for esse tipo de usuário que fica com mais de 10 abas abertas com vídeo tocando, tocando música, abrindo programas aleatoriamente, você vai sentir um soquinho. Como eu mantenho no máximo 7 abas abertas (o máximo que cabe sem diminuir o tamanho delas), mantenho o music player e só, não vejo muita necessidade de fazer downgrade. Uso o DeVeDe quase que diariamente, deixo convertendo para DVD enquanto estou na faculdade e quando volto uso o PC normalmente sem nenhum lag. Isso fiz por 8 dias seguidos.

Repito, se for que nem o galactus que fica com muuitos programas abertos, ai realmente é melhor ficar no BFS que vem de "fabrica" com o omnislash.

Agora isso não quer dizer que o sistema não funcione sobre carga alta. Considero o DeVeDe um programa que puxa bastante do sistema, e mesmo com ele rodando o sistema fica bem tranquilo. Rodei aqui o programa Grid (estilo o Folding @ Home) ele usa 100% do processador o TEMPO INTEIRO, porém com uma prioridade lááá em baixo, 19 para ser preciso. Com ele rodando também não percebi maiores problemas.

Agora vou ficar mais atento, estava muito ocupado com a faculdade e nem parava pra ver como o sistema estava. Vou ficar puxando o danado agora. Tentar abrir vários programas e ver como ele se comporta.

[dtomadon]

Compilei o kernel 2.6.34 aqui com os patchs Omnislash, BFS 357 e ureheadaread em uma instalação minima do Ubuntu, funcionou 100%!!  
A únicas mudanças que fiz foi deixar o Timer Frequency em 1000Mhz e o processador em athlon(Não sei se foi uma boa escolha rs).

Configurações da carroça:
athlon XP 2000+  
512mb de ram  
40gb de HD  

obs.: Antes de reiniciar o PC eu reinstalei o ureadahead!

O consumo de ram ficou na base do 60~70mb!

Ahh, também usei o apt-build pra reinstalar/instalar tudo!

Forte abraço a todos!

Alyscom, me tira uma dúvida voce disse que antes de reiniciar o pc vc instalou o ureadahead, somente compilando o patch junto com o kernel ele já não é instalado, pergunto porque recompilei o kernel omnislash e esse patch , mas tive impressão que o boot ficou mais lento que o padrão do kubuntu 10.10, por favor me tira essa dúvida!! Valeu e até mais.!

Só mais uma coisa que lembrei , na compilação anterior que fiz inclusive a que nosso amigo Hqx, colocou no projeto usei como processador o core2duo e nessa passei para P4, inclusive já vi vários amigos do fórum recomendarem a compilação em P4, parece que não ficou legal dessa forma!

[Andreson Goveia]

Alyscom, me tira uma dúvida voce disse que antes de reiniciar o pc vc instalou o ureadahead, somente compilando o patch junto com o kernel ele já não é instalado, pergunto porque recompilei o kernel omnislash e esse patch , mas tive impressão que o boot ficou mais lento que o padrão do kubuntu 10.10, por favor me tira essa dúvida!! Valeu e até mais.!

Não sou o Alyscom, mas acho que posso responder, hehe
Não ele não vem com o patch, o patch é para poder usa-lo.
Creio que ele reinstalou o ureheadaread do próprio ubuntu.

[dtomadon]

Andreson, valeu pela informação já tá instalado mas não notei grande diferença no boot, vou fazer mais algumas compilações fiderentes e depois posto o resultado!

[galactus]

engraçado, aqui o novo BFS não alterou o desempenho do PC com muito tempo ligado. Aqui ele ta ligado tem 8 dias e tudo tranquilo.

Então deve existir algo aí diferente que faz não aparecer o bug. Pq eu testei em das máquinas e ele apareceu...

Acho que se nós três batermos um papo descobriremos isso.

@Gunss e Galactus vcs estão usando apenas o BFS como patch (estão usando o ck também)?? Estão usando em que kernel?? Quais outros patches vcs estão usando?? (Acho que se formos pelo caminho iremos descobrir o vilão... ou pelo menos melhorar o resultado)

Boa Tarde meus amigos!!

Obrigado

Hqx

Vamos por partes então!


Estou usando o kernel  2.6.34 puro! Pego o seu último Patch do Omnislash da versão 1.4.4 e coloco dentro dele o Patch do Ureheadahead do Fórum do Gentoo!  Aplico esse patch modificado no 2.6.34 puro e depois disso é que faço as aplicações dos patchs que transformam o BFS 318 modificado por você no BFS 357 sem modificações! Não uso o patch do CK, só o BFS 357 sem modificações!

Talvez eu sinta tanta diferença com o 357 por causa das configurações agressivas das minhas compilações! 1000MHz, Low Latency, Perfomance!
Não sinto nenhum Lag no uso do sistema com o 357, o "soquinho" é só na transferência de arquivos! Seja com Pen-Drive ou pela rede!  O que eu noto é que o sistema vai ficando mais lento com muito tempo ligado! Depois dos três dias é bastante perceptível!   

Em outra máquina, a do meu amigo com Core2 Quad e com Chipset da Nvidia, o 357 também mostrou a lentidão na transferência de arquivos! No caso dele ele só consegue fazer uma transferência no sistema e mais nada! Fica tudo muito lento!  Ele suga todas as forças do sistema para a transferência de arquivos!

Outra coisa que pode estar gerando muita diferença é o Journal! Talvez eu seja o único a estar usando o Journal externo com 1GB em outro HD aqui! Pra gente ter certeza dos resultados acho que deveria deixar tudo igual!  Vocês usam o Journal padrão ou o aumentado dentro do mesmo HD?

Agora fico no aguardo HQ, vamos partir de onde para tentar solucionar isso aí?

[vampire_thunder]

Aqui eu tenho compilado apenas o Kernel do Ubuntu. Ele já vem com o ureadaread, mas eu não percebi que o boot está rápido. Ao contrário, às vezes demora muito pra ligar.
Aonde especificamente eu tenho de habilitar esse patch? E além do pacote ureadaread, existe algum outro que eu tenho que instalar, ou alguma config que eu tenha que fazer?

[dtomadon]

Aqui eu tenho compilado apenas o Kernel do Ubuntu. Ele já vem com o ureadaread, mas eu não percebi que o boot está rápido. Ao contrário, às vezes demora muito pra ligar.
Aonde especificamente eu tenho de habilitar esse patch? E além do pacote ureadaread, existe algum outro que eu tenho que instalar, ou alguma config que eu tenha que fazer?

Eu compilei ele junto com o patch do Hxqriven no omnislash , mas percebi que o boot tá demorando mais que o kernel generic do 10.10 , acredito que tenha que recompilar o kernel para introduzi-lo, se estiver errado me corrijam, abraços!

[Niller]

Beleza galera!
Sem querer atrvessar mas atravessando, tem alguem usando o 10.10 com omnislash ou terei que ficar preso no 10.04?
Será que dá para usar o kernel .34 + omni 1.4.4 com ganho de performance no meerkat? Gostaria de alguma sugestão se possível.
Abraçõs.

[macabu]

Niller, eu estava com o 10.10 com o omnislash compilado em casa bjs
agradeça ao Hqxriven \O/