sledgehammer

Esqueçam. CPUMark não é para multiprocessamento. O 4400+ vai ter o mesmo desempenho de um FX-51 ou Opteron 148 e 248. O programa foi desenvolvido em 98/99, então já viu.. []s

Aqui: http://pages.sbcglobal.net/redelm/ Baixe a versão com o front-end

Significa que está ocorrendo ou irá ocorrer clipping naquela música. Se o S está na coluna clipping, é porque a música já está com o ganho muito alto, saturando o sinal (o que se chama de clipping). Já se o S está na coluna clip(Rádio) ou clip(album), ele está informando que o volume pretendido é maior do que essa música permite (irá ocorrer clipping). Mas ative no menu opção o "Don't clip when doing track gain" que ele não irá deixar que ocorra clipping nunca.

Esse assunto é complicado. O MP3Gain surgiu das propostas feitas pelo ReplayGain, de um método para equalizar os volumes das músicas. Inicialmente, o volume indicado era 83dB (chamado de K-20, que é 20dB abaixo do limite), que é o que raramente ocorrerá clipping, considerando todos os tipos de música. Mas como atualmente as músicas tem grande compressão dinâmica (permite um volume muito mais alto sem ocorrer clipping), se as músicas são ajustadas para este valor, a redução é muito drástica e a música perde resolução. Reduzir uma música em 6 dB, é o mesmo que reduzir a resolução dela em 1-bit (ao invés de soar como uma música 16-bit, soará como uma de 15-bit). Os problemas começam a aparecer com reduções em torno de 12 dB (redução de 2-bit) e maiores, bastante comuns com músicas atuais se você usar o padrão k-20. Por este motivo, adotou-se um valor mais alto, 89dB (ou K-14, 14dB abaixo do limite). Isso já melhora bastante o resultado, apenas algumas músicas acabam soando mais "estranhas" por causa da grande redução. O que eu faço é não ser tão radical ao forçar o volume da minha coleção de músicas. Por padrão eu uso 92dB ou 93dB (K-11 ou K-10). Fiz isso porque a maioria da minha coleção tem volume próximo de 98dB e algumas ultrapassam 102dB (inclusive tinha uma música que passava do limite de 103dB sem ocorrer clipping e nunca entendi isso). Essas músicas a redução era grande quando usando 89dB. Mesmo usando 93dB, algumas faixas eu até deixo que fiquem com volume maior (essas eu escolho na mão, quando o CD inteiro tem um som mais alto, mas evito deixar passar de 95dB). E outras irão ficar com volume menor, entre 89dB e 92dB. Sö muito raramente aparecem músicas que pedem volume abaixo de 89dB para não ocorrer clipping. O importante é isso, não ocorrer clipping, nunca, pois acaba com a música. Então eu chego a ter músicas com volume de 89dB até 95dB. São 6dB de diferença, o que é o dobro do volume. Mas esses são os extremos. Na média, a diferença de volume é bem menor e não preciso ficar aumentando o volume porque um música é muito baixa ou abaixando porque a música era muito alta. Tinha algumas músicas que o volume para não clipar era de 81dB, mas a música tinha uma falha, um "pop" que era um estouro e formava um pico muito mais alto que a música, dai foi só editar esse trecho, que terminou esse problema, então vejam se a música não tem algum problema quando o volume para não ocorrer clipping for demasiadamente pequeno, abaixo de 87dB. Ai vai de cada um saber o quanto quer músicas com volume idêntico (não esqueçam, de dentro da própria música, o volume chega a variar bastante, então uma pequena variação, de 3dB ou mesmo 6dB não é tanto assim). Ah. Quando é para gravar um CD de áudio, eu copio os mp3 que irei gravar em uma pasta separada e rodo o MP3gain para deixar elas com o maior volume possível (todas com o volume parecido) em que não ocorre clipping. Vou aumentando o volume desejado de 1 em 1 dB até ele apontar que vai ocorrer clipping em alguma(s) música. Dai volto ao anterior e aplico o ganho. Na verdade expliquei o método burro. O que eu faço é organizar as músicas pela coluna Ganho NoClip Máximo, olhar o MENOR valor de todas as músicas e aumentar o volume pretendido por este valor. Exemplo: o menor valor na coluna Ganho NoClip máximo é 4.5dB e o volume pretendido selecionado é 92dB, então eu passo este para 96.5dB, vejo que agora o menor valor na coluna é 0dB e nenhuma música irá ocorrer clipping, é claro, então é só aplicar.

Que driver que ele instalou? Existem alguns pacotes de drivers que são apenas para 2D, que são aqueles para quem não usa aceleração 3D e quer o máximo de confiabilidade. No 3DMark o desempenho é satisfatório? Se não for, nem aceleração via DirectX ele tem. Aqui tem o driver referência da ATI: http://www2.ati.com/drivers/wxp-w2k-radeon...05m-009438c.exe Aqui a última versão: http://www2.ati.com/drivers/wxp-w2k-ccc-8-...29a-018115c.exe Para esse último driver tem uma mensagem que o usuário DEVE ter o MS .NET Framework 1.1 instalado. Isso você instala usando o Windows Update. Outra coisa é ter a última versão do DirectX instalado. E imagino que você já procurou rodar o prime95 e memtest86 para verificar que o processador e a memória estão sem erros. Drivers atualizados da placa-mãe e atualizar a BIOS. Isso é o mínimo a fazer.

Bem, tente isolar os problemas. você trocou a fonte e o problema parou por algum tempo e depois voltou? Estranho, não? Já tentou atualizar a BIOS da placa-mãe e talvez até o da placa de video (não sei se a sua permite)? Está usando qual versão dos drivers da VIA? Atualize para a última versão. Qualquer coisa, tente forçar AGP 4x pra ver se muda em algo. Já testou a sua máquina por horas e horas com MemTest86 e Prime95?

A diferença é considerável sim. O Northwood tem área de 146 mm^2. O Athlon XP Barton tem 101 mm^2 e o Throughbred tem apenas 84 mm^2. O Prescott é menor que o Northwood, tem 112 mm^2. O Athlon 64 com 1MB de cache tem 193 mm^2 e o de 512kB cerca de 144 mm^2. O Athlon XP tem um core bem pequeno, porém como o contato com o cooler é direto, não é tão difícil assim o transporte de calor, mas ele obriga o uso de uma material excelente condutor, como o cobre (depende muito da densidade de energia, que é o máximo dissipado dividido pela área de contato, que nos modelos mais poderosos atinge valores bem altos). Próximo de 0.9 Watt / mm^2 no Athlon XP 2800+ TBred. Os Prescott mais rápidos já romperam a barreira do 1 Watt / mm^2 (e por bastante) e ainda tem o dissipador integrado, que atrapalha um pouco.

Faltou falar sobre outro detalhe: a densidade volumétrica. O alumínio tem densidade bem menor (2,7g/cm^3 contra 8.9 do cobre e 10,5 da prata). Isso significa que é difícil fazer um dissipador compacto com massa adequada a necessidade do projeto. Isso é uma vantagem do cobre, que com uma mesma área de contato tem uma massa bem maior. Por outro lado, se tamanho não é importante, é possível fazer um dissipador de alumínio com massa parecida, porém com área de contato das aletas (muito importante para a troca de calor) muito maior, o que compensa as outras deficiências. Dependendo do projeto, a diferença entre os materiais não é tão grande (mas o preço é, então em geral se usa o alumínio). Mas com a limitação no tamanho dos dissipadores dos coolers, o cobre e a prata (cara demais e a vantagem sobre o cobre é muito pequena) levam vantagem sobre o alumínio.

Paulo, o link do stresscpu ainda aponta para a minha ex-página no kit.net. Quando puder atualize o link para http://www.cleberlr.hpg.com.br/stresscpu.zip

Programas atualizados: http://www.cleberlr.hpg.ig.com.br/cpuid.html http://sledgehammer.jbrasil.com/cpuid.html quem participa dos rankings deve fazer a atualização (CPUID 1.6 e Benchlauncher agora devem funcionar sem problemas no Windows 9x).

Pra funcionar em multiprocessamento não precisa de tantos pinos, apenas 1 (esse 1 que foi retirado do 940). A maioria desses pinos é para a controladora de memória. Um pente de memória DDR tem 184 pinos. 754 + 184 = 938. Tem algum pino usado para outra função ai (não sei qual, mas é relacionado a memória)

o mesmo problema ocorreu com o north north 2.6ht bus clock 163.29 bus speed 653.16 multi 16x northwood 2.6ht Valeu PC. Acho que era está ok. Percebi o que eu errei. Aproveitei e corrigi para o Celeron também (esses Celeron Tualatins podem variar pra caramba o código, o seu é um diferente dos que eu tinha observado pela net). Baixe a nova versão aqui: http://sledgehammer.jbrasil.com/cpuid.html []'s

No P4 NW está funcionando direito? Ninguém ainda me enviou esses resultados. Em Athlon eu já vi que não zuou nada. Pode ser que apenas o Prescott tenha uma codificação diferente. Até aonde eu sabia, era igual ao do Nortwood. Vou averiguar isso. Valeu PC

Versão de testes do CPUID: Agora está funcionando: http://www.cleberlr.hpg.com.br/cpuid-15033.zip Troquei o device driver (roubado do CrystalCPUID) pra ver se terminam os problemas em algumas máquinas aonda não é possível instalar o iomonkey. Por favor, que tinha problema de não aparecer o multiplicador, FSB, etc, testem essa versão.

Pessoal, nova versão do CPUID. Corrigi alguns bugs de reconhecimento do Prescott. Gostaria que o pessoal que tem um teste pra ver se agora reconhece o cache L1 corretamente. Quem controla algum ranking, favor atualizar se está com link direto para o arquivo. Como não tenho um Intel por aqui, pode ser que apareça algum bug (tomei cuidado para que não acontecesse, mas tive que alterar uma pancada de coisas pra suportar o Itanic também, qualquer coisa apago, pois dificilmente alguém irá comprar um processador desses e usar com Windows 32-bit emulado). http://sledgehammer.jbrasil.com/cpuid.html

Caso aquele não tenha funcionado, já fiz alterações novamente. Agora se não funcionar eu desisto (brincadeira). Pergunta. Como são os teclados de vocês ai no Japão? Como são os nomes dos diretórios? É que eu vejo vários caracteres esquisitos na tela do BenchLauncher.

Galera, tentem ai a primeira versão especial para os japas. Testei aqui e aparentemente não vai aparecer nenhum problema para as máquinas que já rodam normalmente e quero ver se resolve o problema nos SO japas. Amanhã cedo já estará no meu site. Phoenix, atualize quando puder.

Soyti, vocês já tentaram usar um diretório tipo C:\benchs e jogar todos os programas lá (e apagar o diretório velho, senão ele continuar usando aquele)? Alguém pode postar uma tela do que dá erro? Com certeza tem algo relacionado com o japonês. Preciso descobrir uma forma de resolver isso.

Seu SO é em japonês? Pode até ser algo do tipo. Antes tente ir no registro do Windows, faça uma busca por iomonkey e apague todas as chaves que você encontre (e consiga apagar, algumas não é possível). Esse tipo de problema tem acontecido com certa frequência no Windows XP. Preciso fazer uma ferramenta para limpar automaticamente.

Só uma observação. Acho melhor não rodar o CPUBurn em High Priority. Pode rodar em idle mesmo ou no máximo em normal. Isso não irá fazer o processador esquentar mais (um tico, talvez 0.1%). O problema é que você irá praticamente perder o controle sobre a máquina, dando certo trabalho para parar o teste.

Lógico que faz sentido. O que não faz sentido é eu rodar uma vez dar um resultado rodar de novo e dar mais de 500pts de diferença . É isso mesmo que injuria!!! Seria efeito do cache? Tentaram rodar 3 vezes seguida pra ver se estabiliza? Eu não esperaria resultados com pequenas variações em se tratando de um HD. 10% não é tão absurdo assim.

Gente, acho que a questão não é Windows 98/Me versus Windows 2000/XP, mas sim FAT32 x NTFS. FAT32 costuma ser mais rápida mesmo e acho que ninguém poderá mudar isso. Se alguém tiver paciência de rodar um teste em partição FAT32 e depois converter ela para NTFS (usando o convert.exe) e testar novamente para comparar seria ótimo. Não adianta ser partições diferentes, pois estas se localizam em posições diferentes no disco, portanto tem desempenho diferente por isso. Precisa ser a mesma partição. Alguém já testou se usar um defrag melhora o resultado? No HDTach não faz diferença porque é leitura em baixo nível. Não sei como é o caso deste.

Deixa colocar a resposta que dei ao Rosted sobre a dúvida dele do porque o HD com 2MB de cache foi mais rápido que o de 8MB. "O HDTach mede taxa de transferência em uma leitura sequência e essa leitura é feita em baixo nível. Portanto não depende do buffer (os efeitos podem aparecer em outras coisas, como na latência ou na menor flutuação da curva) e nem do sistema de arquivos. A taxa de transferência depende do quê então? Depende principalmente da rotação e da densidade dos discos. Existem vários discos de 80GB. Se você procurar as especificações de cada um, você irá ver que existe discos de 80GB com dois discos (plates) e um disco (em geral é isso, antigamente existiam HDs com até 4 plates, talvez até mais). Vamos pegar o caso do que tem dois plates. Se diz que a densidade dele é de 40GB por disco (o plate), sendo 20GB por cada lado desses discos. Discos de 60GB poderiam ser montados com dois desses discos, porém com apenas 3 cabeças, sendo que um dos lados ficaria sem uso (20GB inacessíveis), ou então com dois disco de menor densidade (30GB por plate) ou então com apenas 1 disco de 60GB por plate. O que pode acontecer é que o seu HD com 2MB de buffer usa apenas um disco com 80GB por plate e o outro usa 2 discos com denssidade menor (o seu é Samsung, não consegui pegar informações, mas no site da Seagate você encontra esse tipo de coisa). Também existem diferenças no firmware que podem causar esse tipo de coisa. Mas é estranho acontecer isso com uma versão mais barata do mesmo modelo (não são HDs de épocas diferentes). Nesses discos mais densos, a cabeça de leitura, que cobre uma áreas delimitada, bem pequena, acaba lendo bem mais informação de uma vez só. Muitas vezes um disco de 5400rpm mais denso pode ter maior taxa de transferência que um disco de 7200rpm menos denso (o de 7200rpm só irá levar vantagem no tempo de acesso menor). A taxa com que os dados são lidos depende da densidade do disco (quanto maior te diz que será melhor), e da velocidade com que o a cabeça percorre as trilhas. Essa velocidade depende do raio do disco (HDs maiores do que 3,5" seriam melhores, mas o problema é que não costumam ter rotação alta devido ao tamanho) e da rotação. Na parte mais externa do disco (aonde é o início do dele, diferentemente de um CD que começa no centro) é a parte mais rápida, o início do gráfico do HDTach. E o final são as trilhas mais centrais. É meio difícil de explicar pro povo que taxa de transferência não é desempenho. Alias, determinar desempenho de HD talvez seja uma das coisa mais difíceis de se fazer. O desempenho varia de todo jeito, pois existem muitas formas de se acessar os dados (que podem estar distribuidos aleatoriamente ou em sequência pelo disco, ter tamanhos dos mais variados, etc). O Winbench pra mim tem a melhor ideia de se medir desempenho, que é usar um padrão de acesso de programas reais. Pena que é de 99, e usa programas do tempo do onça. HD SCSI não costuma mostrar grande vantagem sobre os IDEs nele (hoje, antigamente mostrava). Ah, no HDtach a fragmentação não interfere, já que a leitura é sequêncial e em baixo nível, sem que o Windows participe (não deveria, mas lembre que o Windows também pode atrapalhar a execução do teste caso ocorra uma leitura paralela, para gravar algo que estava no cache do Windows, etc, coisas típicas no WinXP que parece ter vontade própria). Por fim deixa eu falar mal do HDTach 2.7. Esse 2.7 é basicamente o 2.61 MUITO PIORADO. Eles diminuiram demais o tempo de execução do teste, o que o tornou um teste bem mais impreciso. Na minha máquina tem variações absurdas. O 2.61 só tinha um defeito, que era o bug (na verdade quando foi feito imagino que 80MB/s era algo absurdamente alto) de não mostrar burst além de 80MB/s. Isso foi resolvido com um patch que o pessoal do BrazilianTech fez e ai o programa ficou perfeito. Eu só tenho uma dúvida. Se ele roda normal em partições NTFS. Se não me engano só a versão registrada faz isso (aqui é a parte ilícita da coisa ) Então HDTach é mais um teste, mas que não reflete a realidade sobre qual HD é melhor, como a imensa maioria dos testes, que mostram apenas uma parcela dos responsáveis pelo desempenho, que é a taxa de transferência sequêncial. " Complemento, DiskSpeed faz a mesma coisa.

Acho que é menos cheio de frescuras e mais fácil de se ajustar. E não é como o XP, que tem vontades próprias e faz verificações periodicamente, coisa que eu odeio, pois parece que não tem jeito de desativar muitas delas, o que dá pra fazer é mandar ele processar as mensagnes aumuladas antes de rodar o teste, mas se demorar muito o teste já vai ter coisa atrapalhando novamente. Quando a briga por um centésimo de segundo é importante, isso faz diferença. Só para quem tem P4 que o XP acaba tendo melhorias que faça valher a pena, mas como SO, o 2k é muito mais sóbrio.

Para AMD o negócio é o Windows 2000. Olhe no Orb e veja as primeiras posições do pessoal que usa AMD Veja aonde estão os que usam o 2k.