Certo, foi o que eu fiz entao hehehe. Com lagencka 250ns nao deu boot. Precisaria preencher os outros valores tambem de trfc2, trfc4, etc? Ou é desnecessário? Vou tentar 255ns agora.
-
Prezados usuários,
Por questões de segurança, a partir de 22/04/2024 os usuários só conseguirão logar no fórum se estiverem com a "Verificação em duas etapas" habilitada em seu perfil.
Para habilitar a "Verificação em duas etapas" entre em sua conta e "Click" em seu nick name na parte superior da página, aparecerá opções de gestão de sua conta, entre em "Senha e segurança", a primeira opção será para habilitar a "Verificação em duas etapas".
Clicando alí vai pedir a sua senha de acesso ao fórum, e depois vai para as opções de verificação, que serão as seguintes:
***Código de verificação via aplicativo*** >>>Isso permite que você gere um código de verificação usando um aplicativo em seu telefone.
***Email de confirmação*** >>>Isso enviará um código por e-mail para verificar seu login.
***Códigos alternativos*** >>>Esses códigos podem ser usados para fazer login se você não tiver acesso a outros métodos de verificação.
Existe as 3 opções acima, e para continuar acessando o fórum a partir de 22/04/2024 você deverá habilitar uma das 03 opções.
Tópico para tirar dúvidas>>>>https://forum.adrenaline.com.br/threads/obrigatoriedade-da-verificacao-em-duas-etapas-a-partir-de-24-04-2024-duvidas.712290/
Atencionamente,
Administração do Fórum Adrenaline
[TÓPICO DEDICADO] AMD Ryzen Socket AM4 - Zen, Zen+, Zen 2 & Zen 3
- Iniciador de Tópicos DemonbrsX
- Data de Início
Certo, foi o que eu fiz entao hehehe. Com lagencka 250ns nao deu boot. Precisaria preencher os outros valores tambem de trfc2, trfc4, etc? Ou é desnecessário? Vou tentar 255ns agora.
sempre deixei o IF em AUTO..
alguma possibilidade ser meu fator limitante dos 3533@CL16?? meus chips são UNKNOWN ahhahaha , são aquelas memorias risemode xmp 3200@16... Nenhum app reconhece qual chip é. Porem já me deixa muito surpresa em conseguir esse resultado.
apenas usa-lo em manual irá mudar alguma coisa ?
Entendi.
Configurado o IF manual, essa regra de ser metade da frequência pode ser alterada? Ou alterar o IF altera indiretamente a frequência?
Vai subindo, esse é um timing que pela minha experiência não tem meio termo. Ou funciona ou não funciona.
--- Post duplo é unido automaticamente: ---
Se você quebrar a regra (1:1) vai ter penalidade na latência e perda de desempenho.
Por isso a melhor opção é baixar a memória junto com o IF e apertar ao máximo os timings da memória.
255ms deu boot, trC consegui reduzir pra 56 também. Vou deixar o memtest rolando por uma horinha aqui enquanto faço algumas coisas fora do PC pra ver como ta.
Acho improvável, mas eu por segurança sempre configuro manualmente pra não correr o risco da BIOS configurar errado, fora do 1:1.
sempre que mudo frequencia/latencias , confirmo no cpuz se esta correto , e sempre esta certinho ( deixando em auto na bios )
Estou usando só uma memória da Crucial chip Micron 3200 @ 3600 mhz com 16-18-18-36-72 e no Aida64 a latência da 69.6 ns
Será que consigo diminuir apertando os timings? Ou é pouca diferença? Não aumento a frequência porque meu cpu não consegue, 3700 ele já cai pela metade o IF
E outra, será que em dual channel mudaria a latência? Futuramente vou colocar
Será que consigo diminuir apertando os timings? Ou é pouca diferença? Não aumento a frequência porque meu cpu não consegue, 3700 ele já cai pela metade o IF
E outra, será que em dual channel mudaria a latência? Futuramente vou colocar
putz isso tudo pros 2000mhz ou mais não compensa mesmo, acho que o marketing de 2000mhz no if da amd vai ficar só propaganda mesmo, pq eles prometeram que no agesa 1.1.9.0 funcionaria já e nada nem no 1.2.0.0É bem comum algumas atualizações de AGESA alterar o comportamento de um overclock no FLCK.
Acima de 1600MHz no FLCK é considerado overclock.
Quando o FLCK está no limite do chip, e 1900MHz costuma ser o limite para os Zen 2, um ajuste de 0.02v pode ser a diferença entre estabilidade e crash.
@dayllann , falando de FLCK, atualizei para o AGESA 1.2.0.0.
Essa é a versão que traz overclock melhorado no FLCK.
E já adianto que consegui com meu 5900X dar boot e carregar o sistema operacional com 4000MHz / 2000MHz 1:1
No final de semana devo ajustar para estabilizar 100% e eliminar os erros WHEA.
Mas já adianto que não estou convencido que vou usar 4000MHz / 2000MHz no dia a dia, 24x7. Foi bem custoso, tive que subir a tensão do PLL de 1.8v para 2.1v.
2.1v é o padrão do PLL da Crosshair VIII quando você liga o modo nitrogênio líquido.... Nessas condições 2000MHz vai ser algo "exclusivo" das placas mãe mais caras.
Usar 2.1v de PLL numa placa mãe de baixo padrão, pelo que li, é no mínimo arriscado.
aqui eu consigo os 5.1ghz no single e 4.6ghz no multi setando a curva de -30 nos 2 melhores núcleos, -20 em 4 deles e -10 no resto, pbo override clock em 125mhz, offset voltage do vcore pra -0.500
assim bate 1.41v no single e 1.28v no multi, assim que consegui os 700/10100 no cpu-z mas já aviso que as temps subiram 5 graus mas é o esperado né
é esse o over que to te falando pra fazer há 5 páginas atrástodos seus post são uma Aula.. muito bom
"PBO + otimizador de curva é perfeito. Você aumenta o all core, aumenta o single core, faz undervolt ou aumenta tensão e mantém o comportamento stock quando o pc estiver ocioso."
desde que vc comentou isso a páginas atrás, fiquei curioso para brincar, principalmente pelo fato do (undervolt) , pois preso muito pelo consumo/temp/ruido.
Se um dia tiver um tempinho e puder fazer uma "RECEITA DE BOLO" com prints e passo a passo , acho que uns 90% aqui do grupo , desde o mais leigo ao mais expert , aprenderia algo ou somaria ao que ja conhece.
eu ainda sou do TEAM UV/FIX core , pois o resultado ingame é 100% , meu idle é 30-34w , full <105w e temperaturas são excelentes, Games 62c , Benchs 78c.
mas dessa forma que vc faz , parece uma mistura de tudo isso e com possíveis ganhos, mesmo que em aplicações que não sejam o foco diário.
Com aqueles times de tRC 56 e tRFC em 484 (255ns) e também aumentando o tCWL de 14 para 16 (acredito que esse nao seja o problema, né?) o memtest parou com uns 4 min de teste acusando erro, seguido de tela azul. Nesse caso você acha que eu subo um pouco do tRC em conjunto com o tRFC ou vou procurando o problema em cada um deles? Qual jeito mais fácil e eficaz? Valeu!!!
O jeito mais fácil é vc estabelecer um baseline estável sem errors e refinar grupos de timings um de cada vez, senão vc vai ficar baixando 1 por 1 tentando descobrir o que é.
1.8v para 2.1v foi muita coisa, mas foram 200MHz no FCLK e 1:1, nossa, finalmente a AMD corrigiu isso, tava na hora.É bem comum algumas atualizações de AGESA alterar o comportamento de um overclock no FLCK.
Acima de 1600MHz no FLCK é considerado overclock.
Quando o FLCK está no limite do chip, e 1900MHz costuma ser o limite para os Zen 2, um ajuste de 0.02v pode ser a diferença entre estabilidade e crash.
@dayllann , falando de FLCK, atualizei para o AGESA 1.2.0.0.
Essa é a versão que traz overclock melhorado no FLCK.
E já adianto que consegui com meu 5900X dar boot e carregar o sistema operacional com 4000MHz / 2000MHz 1:1
No final de semana devo ajustar para estabilizar 100% e eliminar os erros WHEA.
Mas já adianto que não estou convencido que vou usar 4000MHz / 2000MHz no dia a dia, 24x7. Foi bem custoso, tive que subir a tensão do PLL de 1.8v para 2.1v.
2.1v é o padrão do PLL da Crosshair VIII quando você liga o modo nitrogênio líquido.... Nessas condições 2000MHz vai ser algo "exclusivo" das placas mãe mais caras.
Usar 2.1v de PLL numa placa mãe de baixo padrão, pelo que li, é no mínimo arriscado.
Agora é manter um 1900MHz ai estável com timmings apertados que será só sucesso :3
O que não entender é só perguntar, se a notificação aparecer aqui eu respondo sem problemas, só precisa ter paciência que nem sempre respondo rápido xD
Agora partindo para notícias, esta é a última que todo mundo leu: AMD fala (quase anda) sobre o Zen4 e RDNA3.
Lisa Su fala sobre RDNA3 e Zen 4, prometendo produtos extremamente competitivos
A Dra. Lisa Su, CEO da AMD, deu uma entrevista coletiva para alguns dos principais sites internacionais de tecnologia e hardware. A presidente falou sobre
adrenaline.com.br
Mas esta aqui é a última que quase ninguém viu: Nova patente sobre uma nova abordagem de IOD, interessantíssima diga-se de passagem.
METHOD AND APPARATUS FOR SERVICING AN INTERRUPT
Complete Patent Searching Database and Patent Data Analytics Services.
www.freepatentsonline.com
Como não tem sobre o que falar da primeira notícia, todo mundo aqui está careca de saber que o Zen4 e RDNA3 vão ser melhores que o Zen3 e RDNA2, vou me esticar um pouco na patente: Ela aborda a quebra de um processador em três estágios de processamento, onde um processador muito simples (GPIO, entrada/saída de propósito geral) e de baixíssimo consumo cuidará do IO e tarefas de primeira ordem, caso essa tarefa seja complexa de mais ou requeira um poder computacional maior esse GPIO acorda o fabric (conexão entre uma unidade e outra) e manda essa tarefa para um mini-processador, que tem unidades computacionais mais fortes e opera uma gama maior de instruções, com acesso a cache do CPU princpipal. Caso esse mini-processador não consiga dar conta da tarefa ele acorda o CPU e manda para ele resolver o problema, e este é o CPU que todos conhecemos. Com essa quebra em três estágios o consumo se CPU seria reduzido vertiginosamente, e vale ressaltar que tanto o GPIO quanto o mini-processador podem ser ARM, FPGA ou CPU x86 simplificado (apenas no caso do MPU).
Traduzindo esta patente para a plataforma Zen, que é o que importa, o IOD teria um CPU ARM (ou FPGA) que cuidaria de monitorar e processar dados leves, além de colocar as partes do IOD que não estão funcionando "para dormir", fazendo com que este finalmente o IOD entre em modo de repouso/idle. Caso a tarefa exigida pelo usuário seja complexa de mais, esse GPIO "acordaria" o IF e o CCD, e mandaria os dados para serem processados por um outro processador dentro do CCD, o MPU (mini unidade de processamento). Este aqui poderia ser um FPGA ou um um CPU x86 de instruções simples (aka, sem SIMD/FP32) que cuidaria de todo e qualquer tarefa menos complexa e que não exija grande poder computacional, isso sem que precise acordar os núcleos do CPU mas ao mesmo tempo estaria utilizando a LLC dele (cache L3, no caso) para ajudar no processamento. Caso a tarefa seja complexa ou pesada demais para este MPU, ele acordaria os demais núcleos do CCX e ai o processador como conhecemos entraria em operação.
O interessante dessa abordagem que é todos estes três processadores (GPIO, MPU e CPU) podem funcionar de forma paralela, então não necessariamente porque a tarefa complexa esta no CPU que o GPIO estará esperando ele concluir para pegar a próxima, e o mesmo vale para o MPU. Percebam também que isto não é um sistema big.LITTLE, é uma outra abordagem e nem pode ser considerada híbrida, já que existe a possibilidade do MPU e GPIO serem FPGAs (ou seja, eles podem ser customizados para tarefas específicas a pedido de alguma empresa, vulgo semi-custom), então não necessariamente eles cuidarão de tarefas leves, a patente apenas garante que eles serão despertados antes do CPU principal e apenas isso, eles podem muito bem fazer tarefas distintas.
Por fim, a AMD tem uma patente de abordagem híbrida, vulgo big.LITLE, e esta patente aborda uma forma diferente de funcionamento da presente do Alderlake (que é a mesma do Lakefield) e nos ARMs existentes, no caso esta patente que eu falei seria complementar tanto a os CPUs existentes hoje quanto a um possível híbrido futuro. Ah, esta patente não vale apenas para CPUs não, ela também se aplica a GPUs, CPU+GPU, SoCs, NPUs, XPUs e afins. Marcar o @igormp por que... porque sim xD
putz isso tudo pros 2000mhz ou mais não compensa mesmo, acho que o marketing de 2000mhz no if da amd vai ficar só propaganda mesmo, pq eles prometeram que no agesa 1.1.9.0 funcionaria já e nada nem no 1.2.0.0
aqui eu consigo os 5.1ghz no single e 4.6ghz no multi setando a curva de -30 nos 2 melhores núcleos, -20 em 4 deles e -10 no resto, pbo override clock em 125mhz, offset voltage do vcore pra -0.500
assim bate 1.41v no single e 1.28v no multi, assim que consegui os 700/10100 no cpu-z mas já aviso que as temps subiram 5 graus mas é o esperado né
é esse o over que to te falando pra fazer há 5 páginas atrás
Interessante.
Eu ainda não brinquei de misturar undervolt no otimizador de curva com undervolt direto no VCore VID.
A princípio reduzir o VCore VID reduz o pico do boost curto/momentâneo e também o boost single core se for muito agressivo.
Mas talvez ele esteja atuando na frequência alta que é o "pior cenário" de oportunidade de redução de tensão para o otimizador de curva.
Enfim, tem que testar e validar, mas quanto mais variáveis se coloca, mais demorado os testes e validações.
--- Post duplo é unido automaticamente: ---
Não conheço as implicações de se usar 2.1v no PLL em 24x7.
Tem BIOS que ao configurar o IF acima de 1600, se a tensão do PLL estiver no modo automático, a BIOS vai configurar em 2.1v automaticamente.
Sei que aumentar a tensão do PLL é um macete conhecido há anos, usado para estabilizar overclock no BLCK.
O comportamento do sistema com IF a 2000MHz com 2.0v no PLL (0.1v a menos) é simplesmente horrendo, a BIOS parece que funciona a 2fps, obviamente nessas condições o boot do sistema operacional é impossível.
*especulação minha* Talvez o IF elevado interfira de alguma forma com o BLCK. O BLCK precisa de mais do que os tradicionais 1.8v PLL para permanecer estável, mesmo operando no padrão 100MHz.
Última edição:
Hoje é ritmo de festa, pois adivinhem o que aconteceu? A AMD passou a Intel em marketshare (desktop), depois de 14 anos!
Mas não se animem muito, o melhor é que fique assim ou até 60-40 no máximo, mais que isso não é bom para ninguém
Vamos ver como a Intel irá contra-atacar, pois o CEO mudou não foi só para esquentar o banco não, e esse novo é da velha guarda, braço firme e já chutou um CEO da AMD no passado
Agora é partir para reduzir um pouco estes outros aqui: Mobile e Server xD
Mas não se animem muito, o melhor é que fique assim ou até 60-40 no máximo, mais que isso não é bom para ninguém
Vamos ver como a Intel irá contra-atacar, pois o CEO mudou não foi só para esquentar o banco não, e esse novo é da velha guarda, braço firme e já chutou um CEO da AMD no passado
Agora é partir para reduzir um pouco estes outros aqui: Mobile e Server xD
Última edição:
O ideal é voltar na configuração que estava estável, esse é seu porto seguro / referência.
Modifique um dos dois e faça o teste, para então isolar o culpado.
Se eu tivesse que dar um palpite eu aponto o dedo para o tRC.
Lembro que tu estava com GDM ligado, ele pode subir seus timings primários ímpares para o próximo valor par.
A recomendação do tRC é não ser menor do que tRP + tRAS, no seu caso 20 + 38 = 58, enquanto o valor que você utilizou é 56.
Se for o tRC você tem potencialmente duas soluções.
1: Subir / afrouxar o tRC (obviamente).
2: Diminuir o tRP ou tRAS de forma que a soma dos dois não seja superior a 56. Nesta abordagem eu sugiro colocar 36 no tRAS.
Essa segunda abordagem só vai funcionar com duas condições, se não estiver no limite do chip e se houver tensão suficiente.
Perfeito então, mais tarde farei mais testes. Tenho o perfil da configuração estavel salva na bios. Quanto ao gdm li em alguns lugares recomendando deixar ligado e até no próprio dram. Acha que eu deva deixar desabilitado mesmo então? Valeu cara, ta me ajudando e ensinando demais!!!
Os que compraram no Brasil com nota em 2020, recebem um código e cadastram no AMD Rewards, estes vão receber o Far Cry 6 no lançamento.
Não sei se todas as lojas participam, precisa ler o regulamento.
--- Post duplo é unido automaticamente: ---
GDM pelos testes a fora é equivalente a um Command Rate "1.5T".
Na prática ele pode ajudar a estabilizar o overclock com um impacto leve na performance.
Ele faz isso subindo os timings ímpares sem afetar a configuração salva na BIOS.
Ex: Se teus timings primários são 16-19-19-39, o GDM na prática executa 16-20-20-40.
Desativando o GDM, e colocando o Command Rate em 1T, você vai ganhar mais um pouco de performance, mas pode perder estabilidade e causar mais erros. Esse tipo de ajuste fino é tentativa e erro.
A calculadora do 1usmus é uma referência do que e como você provavelmente vai conseguir, mas tem que lembrar que existe loteria do silício, cada chip é único. Você pode conseguir um resultado melhor ou pior do que está na calculadora.
Última edição:
Queria fazer textão e discutir bem a fundo, porém meio cansado pra isso1.8v para 2.1v foi muita coisa, mas foram 200MHz no FCLK e 1:1, nossa, finalmente a AMD corrigiu isso, tava na hora.
Agora é manter um 1900MHz ai estável com timmings apertados que será só sucesso :3
O que não entender é só perguntar, se a notificação aparecer aqui eu respondo sem problemas, só precisa ter paciência que nem sempre respondo rápido xD
Agora partindo para notícias, esta é a última que todo mundo leu: AMD fala (quase anda) sobre o Zen4 e RDNA3.
Lisa Su fala sobre RDNA3 e Zen 4, prometendo produtos extremamente competitivos
A Dra. Lisa Su, CEO da AMD, deu uma entrevista coletiva para alguns dos principais sites internacionais de tecnologia e hardware. A presidente falou sobre
Mas esta aqui é a última que quase ninguém viu: Nova patente sobre uma nova abordagem de IOD, interessantíssima diga-se de passagem.
METHOD AND APPARATUS FOR SERVICING AN INTERRUPT
Complete Patent Searching Database and Patent Data Analytics Services.
Como não tem sobre o que falar da primeira notícia, todo mundo aqui está careca de saber que o Zen4 e RDNA3 vão ser melhores que o Zen3 e RDNA2, vou me esticar um pouco na patente: Ela aborda a quebra de um processador em três estágios de processamento, onde um processador muito simples (GPIO, entrada/saída de propósito geral) e de baixíssimo consumo cuidará do IO e tarefas de primeira ordem, caso essa tarefa seja complexa de mais ou requeira um poder computacional maior esse GPIO acorda o fabric (conexão entre uma unidade e outra) e manda essa tarefa para um mini-processador, que tem unidades computacionais mais fortes e opera uma gama maior de instruções, com acesso a cache do CPU princpipal. Caso esse mini-processador não consiga dar conta da tarefa ele acorda o CPU e manda para ele resolver o problema, e este é o CPU que todos conhecemos. Com essa quebra em três estágios o consumo se CPU seria reduzido vertiginosamente, e vale ressaltar que tanto o GPIO quanto o mini-processador podem ser ARM, FPGA ou CPU x86 simplificado (apenas no caso do MPU).
Traduzindo esta patente para a plataforma Zen, que é o que importa, o IOD teria um CPU ARM (ou FPGA) que cuidaria de monitorar e processar dados leves, além de colocar as partes do IOD que não estão funcionando "para dormir", fazendo com que este finalmente o IOD entre em modo de repouso/idle. Caso a tarefa exigida pelo usuário seja complexa de mais, esse GPIO "acordaria" o IF e o CCD, e mandaria os dados para serem processados por um outro processador dentro do CCD, o MPU (mini unidade de processamento). Este aqui poderia ser um FPGA ou um um CPU x86 de instruções simples (aka, sem SIMD/FP32) que cuidaria de todo e qualquer tarefa menos complexa e que não exija grande poder computacional, isso sem que precise acordar os núcleos do CPU mas ao mesmo tempo estaria utilizando a LLC dele (cache L3, no caso) para ajudar no processamento. Caso a tarefa seja complexa ou pesada demais para este MPU, ele acordaria os demais núcleos do CCX e ai o processador como conhecemos entraria em operação.
O interessante dessa abordagem que é todos estes três processadores (GPIO, MPU e CPU) podem funcionar de forma paralela, então não necessariamente porque a tarefa complexa esta no CPU que o GPIO estará esperando ele concluir para pegar a próxima, e o mesmo vale para o MPU. Percebam também que isto não é um sistema big.LITTLE, é uma outra abordagem e nem pode ser considerada híbrida, já que existe a possibilidade do MPU e GPIO serem FPGAs (ou seja, eles podem ser customizados para tarefas específicas a pedido de alguma empresa, vulgo semi-custom), então não necessariamente eles cuidarão de tarefas leves, a patente apenas garante que eles serão despertados antes do CPU principal e apenas isso, eles podem muito bem fazer tarefas distintas.
Por fim, a AMD tem uma patente de abordagem híbrida, vulgo big.LITLE, e esta patente aborda uma forma diferente de funcionamento da presente do Alderlake (que é a mesma do Lakefield) e nos ARMs existentes, no caso esta patente que eu falei seria complementar tanto a os CPUs existentes hoje quanto a um possível híbrido futuro. Ah, esta patente não vale apenas para CPUs não, ela também se aplica a GPUs, CPU+GPU, SoCs, NPUs, XPUs e afins. Marcar o @igormp por que... porque sim xD
Só irei deixar dois questionamentos: será q isso vai impactar muito na latência das trocas de contexto? Será que ao invés de ARM eles não usariam algum RISC-V? A nvidia já mostrou uns cases bem legais de dumb coprocessors em Risc-V.
creio que minha AGESA esteja ainda bem defasada ( se é que virá atts para b450 ).
dai não acha interessante o pbo+curve+under ??
Instalei o 5800X que chegou ontem do Ali na Taichi X470 (bios 4.60) e aparentemente, está tudo certo! As temperaturas estão ok (tenho wc custom), agora é começar a brincar com o over nas memórias!
Vi o pessoal usando o PBO negativo pra melhorar a performance e baixar a voltagem, é só isso mesmo ou tem algum outro ajuste?
Vi o pessoal usando o PBO negativo pra melhorar a performance e baixar a voltagem, é só isso mesmo ou tem algum outro ajuste?