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

[galactus]

Deixa ver se eu entendi bem, se eu marcar P4 terei então melhor desempenho?

Obs: estou em 64bits e com GCC 4.4

Ah, e parabéns ae Hqx uma vez mais e a toda comunidade também.

[]z

É isso mesmo, se marcar P4 o desempenho é maior! O que estamos tentando descobrir é o motivo exato disso!

[brottor]

Deixa ver se eu entendi bem, se eu marcar P4 terei então melhor desempenho?

Obs: estou em 64bits e com GCC 4.4

Ah, e parabéns ae Hqx uma vez mais e a toda comunidade também.

[]z

É isso mesmo, se marcar P4 o desempenho é maior! O que estamos tentando descobrir é o motivo exato disso!

P4 para sistemas 64bits e Pentium II  para sistemas 32 segundo o HQx.

[vampire_thunder]

Compilei o Kernel do Ubuntu Natty no Lucid, mas não consegui de jeito nenhum instalar o driver da placa ATI.

Vocês sabem se a dica do GCC também funciona no Lucid?

Existe um módulo que se monta em /sys/kernel/debug chamado vgashwitcheroo que só funciona no Maverick. Compilei o kernel com ele habilitado mas mesmo assim no Lucid não monta. Preciso dele para fazer a saída HDMI funcionar, mas não tenho ideia de como fazer isso, e não queria migrar para o Maverick.

olha, o GCC 4.5 só vem no 10.10

Sobre esse módulo vgashwitcheroo, vi que ele é para trocar de VGA durante o uso do sistema correto?
se for vê se isso ajuda
http://linux-hybrid-graphics.blogspot.com/2010/02/howto-install-vgaswitcheroo-for-linux.html

http://asusm51ta-with-linux.blogspot.com/
https://launchpad.net/~hybrid-graphics-linux

Obrigado, mas nenhum deles funcionou. O vgaswitcheroo não monta de jeito nenhum no Lucid. No Maverick eu não preciso fazer nada para ele funcionar. Engraçado que eu instalei no Maverick o mesmo pacote que compilei no Lucid e lá funciona. Portanto, deve ser outra coisa.

Quase consegui atualizar o GCC no Lucid. Consegui compilar as dependências, mas na hora do "dpkg-buildpackage -rfakeroot -uc -b", deu erro na aplicação dos patches:

Código Selecionar Expandir

Applying patch gcc-default-format-security.diff
patching file src/gcc/c-common.c
Hunk #1 succeeded at 245 (offset -55 lines).
patching file src/gcc/c.opt
Hunk #1 succeeded at 240 (offset 4 lines).
patching file src/gcc/doc/invoke.texi
Hunk #1 FAILED at 2864.
Hunk #2 FAILED at 2917.
2 out of 2 hunks FAILED -- rejects in file src/gcc/doc/invoke.texi
Patch gcc-default-format-security.diff does not apply (enforce with -f)
make: ** [stamps/02-patch-stamp] Erro 1
dpkg-buildpackage: erro: debian/rules build gave error exit status 2


[Gunss]

@vampire_thunder realmente o meio mais fácil seria atualizar para o 10.10 então. Mas se alguém aqui que vai conseguir é você, só lembrar do LZMA.

e eu não consigo descobrir qual a opção que ativo para a webcam funcionar. No omnislash 1.4.4 funciona, porém no 2.6.36 nem em sonho. Não acho a maldita opção.

[maiconramones]

Pelo que li eu tenho que fazer o downgrade de 10.10 para 10.04 para poder começar a fazer os testes com o kernel do brother Hqxriven.

É isso mesmo?

[galactus]

Pelo que li eu tenho que fazer o downgrade de 10.10 para 10.04 para poder começar a fazer os testes com o kernel do brother Hqxriven.

É isso mesmo?

Não, você pode usar o 10.10 mesmo! No 10.10 você não precisa usar o mkinitramfs!

[Gunss]

Pelo que li eu tenho que fazer o downgrade de 10.10 para 10.04 para poder começar a fazer os testes com o kernel do brother Hqxriven.

É isso mesmo?

Não, você pode usar o 10.10 mesmo! No 10.10 você não precisa usar o mkinitramfs!

depois de compilado é só instalar os .deb sem usr o mkinrtramfs? maravilha, eu sempre coloco um aviso bem grande para não me esquecer.

[brottor]

Boa noite galera!

Então acabei de terminar de compilar o kernel agora configurado como pentium II em detrimento da configuração de c2d/new xeon.

Amanhã vou fazer alguns testes com ele...

[brottor]

Então... Testando a aqui compilado com o processador em pentium 2. O q eu percebi, teve uma melhora bem pequena, nada q mude muito! Melhorou na hora de carregar imagens e talz...

Mas piorou muito o consumo de bateria... to usando aqui parece q não dura 2 horas direito. em 1h já tá mais de 50%... acho q pra quem tem notebook, acho q vale a pena pegar a conf de core2duo/newer Xeon pois mesmo com o acpi em modo performance a bateria durou 3h.

[Gunss]

Então... Testando a aqui compilado com o processador em pentium 2. O q eu percebi, teve uma melhora bem pequena, nada q mude muito! Melhorou na hora de carregar imagens e talz...

Mas piorou muito o consumo de bateria... to usando aqui parece q não dura 2 horas direito. em 1h já tá mais de 50%... acho q pra quem tem notebook, acho q vale a pena pegar a conf de core2duo/newer Xeon pois mesmo com o acpi em modo performance a bateria durou 3h.

é, talvez marcando core2 na hora de compilar o GCC instrua melhor o kernel à gerenciar o consumo de energia do processador.
Talvez você note um desempenho melhor fazendo igual a mim. Low Latency Desktop + 300hz + performance

LLD + 1000hz é melhor para um quad core parrudo. Seu sistema vai ser quase um sistema RT assim.

[Hqxriven]

Então... Testando a aqui compilado com o processador em pentium 2. O q eu percebi, teve uma melhora bem pequena, nada q mude muito! Melhorou na hora de carregar imagens e talz...

Mas piorou muito o consumo de bateria... to usando aqui parece q não dura 2 horas direito. em 1h já tá mais de 50%... acho q pra quem tem notebook, acho q vale a pena pegar a conf de core2duo/newer Xeon pois mesmo com o acpi em modo performance a bateria durou 3h.

1000 ou 300 Hz no escolha core2duo?? E na Pentium II?? (Só para saber)

Low Latency Desktop + 300hz + performance

Gunss vc se lembra do nosso teste com o handbrake??

Aquilo foi um teste legal ganhamos quase o dobro da performance no programa!!

[MSXManiac]

To na torcida que o HQX consiga muito em breve chegar a alguma conclusão sobre o novo omni!

Aliás, de repente tudo que ele aprender e testar poderá ser usado no novo 2.6.38, até pq parece que os chips da intel se sairão melhor com drivers melhor escritos neste kernel!

Tomara!

[Gunss]

Low Latency Desktop + 300hz + performance

Gunss vc se lembra do nosso teste com o handbrake??

Aquilo foi um teste legal ganhamos quase o dobro da performance no programa!!

sim, só que usando o kernel 2.6.36 o desempenho é o mesmo usando Voluntary ou Low Lantecy. Fantastico o que esses novos patchs juntamente com esse kernel fazem

ps: alguém aqui já testou o kernel da árvore linux-next?

[Hqxriven]

só que usando o kernel 2.6.36 o desempenho é o mesmo usando Voluntary ou Low Lantecy. Fantastico o que esses novos patchs juntamente com esse kernel fazem

Interessante... como estou usando mais o 2.6.35 ainda não percebi. Vou colocar uma prioridade RT xo xorg para testar. Valeu pela observação!

[Gunss]

só que usando o kernel 2.6.36 o desempenho é o mesmo usando Voluntary ou Low Lantecy. Fantastico o que esses novos patchs juntamente com esse kernel fazem

Interessante... como estou usando mais o 2.6.35 ainda não percebi. Vou colocar uma prioridade RT xo xorg para testar. Valeu pela observação!

os patchs que uso são esses:

Código Selecionar Expandir

Ureadahead
patch -p1 < 0001-trace-add-trace-events-for-open-exec-an.patch

BFQ
patch -p1 < 0001-bfq_iosched-block-prepare_IO_context_code-v1-2.6.36.patch
patch -p1 < 0002-bfq_iosched-block-add-cgroups-kconfig-and-build-bits-for-BFQ-v1-2.6.36.patch
patch -p1 < 0003-bfq_iosched-block-introduce_BFQ-v1-2.6.36.patch

BFS:
patch -p1 < 2.6.36-sched-bfs-357-1.patch
patch -p1 < bfs357-worker_fix.patch

Classic RCU
patch -p1 < rcu_classic.patch
patch -p1 < kernel_rcuclassic.c.diff
patch -p1 < fixes_for_2.6.36.diff
patch -p1 < lib_Kconfig.debug.diff


X com Prio RT e nice -10 e smarter-realtime:
patch -p1 < boost_privileged_tasks-2.6.36-bfs.patch
patch -p1 < smarter_relatime-2.6.33.patch


Selecionei Pentium III durante a compilação. (Não sei pq, acho que cliquei sem querer kkkk)

ps: Por curiosidade repeti o teste com o HandBrake. Como era de se esperar com o sistema em repouso quase não houve diferença entre a velocidade em que o programa realizava o encode.
Mexendo no google-chrome, escutando música e colocando um vídeo no YT o desempenho tendeu para a configuração que tinha o omnislash que funciona em Voluntary. Porém a diferença foi de no máximo 20%, a média é de 10~15%. Cenário completamente diferente utilizando o kernel 2.6.34 + omnislash, onde a diferença era de 60~80%.
Com o kernel 2.6.36 + patchs citados para mim compensa utilizar Preempt Forced + 300hz + Performance.