CAPA | Benchmarks
Proibições, falhas e trapaças em benchmarks
CAPA
O que dizem os números
A melhor referência para uma decisão de compra são testes e benchmarks
de fontes confiáveis. Quem não acredita em propagandas, mas prefere
testar por si próprio e publicar os resultados, acaba caindo em um campo
minado de licenças, proibições de teste e trapaças dos fabricantes.
por Mirko Dölle
Jean Scheijen - www.sxc.hu
A
indústria investe muito em propaganda para convencer os consumidores dos benefícios de seus produtos, não se envergonhando de algumas
meias-verdades e exageros. No campo da
Informática, não basta folhear o prospecto e os dados técnicos de um fabricante
para tomar a melhor decisão de compra.
Outras fontes também costumam ser úteis,
como artigos ou os próprios benchmarks
– nos quais os testes requerem uma boa
preparação para mais tarde adquirirem
significado e confiabilidade.
Sem exageros, podemos falar que
existe uma relação de amor e ódio dos
fabricantes de software e hardware com
os bechmarks. Em relação a produtos
muito parecidos, como por exemplo
impressoras jato de tinta, os fabricantes
não conseguem ultrapassar as características de seus concorrentes. Caso exista
algum teste comumente conhecido, o
fabricante poderá anunciar sua vitória
ou boa colocação nos resultados através
de um logotipo, e com isso o produto
alcança grande reconhecimento com a
publicação do teste.
O benchmark padrão da Linux Magazine para o teste de placas de vídeo de
34
workstations é o SPEC Viewperf Suite [1].
Seu ponto forte é utilizar dados reais de
usuários para o teste dos populares programas de CAD e renderização: o fabricante SPEC captura os dados gráficos de
programas como Catia, Pro/ENGINEER
(figura 1) e Maya (figura 2) diretamente
dos drivers da placa de vídeo, e salva seus
resultados como testes.
A Viewperf Suite transfere apenas esses dados, com velocidade máxima, para
a placa de vídeo – portanto, a CPU do
computador não precisa se ocupar com
os complexos cálculos 3D dos programas
de CAD. Com a Viewperf Suite também
pode ser testado e comparado o desempenho de vídeo em diferentes sistemas
operacionais, independentemente de a
aplicação base ter sido portada para o
respectivo sistema.
Placas diferentes
As taxas de atualização em jogos foram
testadas pela Linux Magazine International, no passado, com os Demo-Levels
de Quake 3 Arena e Parsec. Dois valores
fornecidos com diferentes programas
de teste ajudam a conduzir qualquer
manipulação em drivers. Assim, no ano
de 2001, a ATI “otimizou” o driver para
o processador Radeon 8500: conhecendo a seqüência de demonstração do
Quake, o driver diminui a qualidade de
imagem, produzindo assim melhores
resultados [2].
A Nvidia também não é, de forma alguma, inocente: em 2003 a Futuremark
denunciou a fraude ao fabricante de placa
de vídeo: o driver descobria seqüências
especiais do 3D Mark-Bench e substituia
algumas seqüências de comandos, de
modo que no fim foi obtida apenas uma
parte da imagem com profundidade de
cor reduzida, o que aumenta drasticamente a resolução.
Para o teste dos demais componentes
e serviços de um sistema, são necessários
outros bechmarks especializados. A Standard Performance Evaluation Corporation
(SPEC [1]) possui uma série de suítes de
benchmark prontas; no entanto, algumas
rodam apenas no Windows®. Uma das
excessões, junto com a Viewperf Suite,
é a CPU Suite, claramente melhor indicada para avaliação da capacidade do
computador do que o método preferido
atualmente, o tempo de compilação do
http://www.linuxmagazine.com.br
Benchmarks | CAPA
Figura 1: A SPEC Viewperf Suite utiliza dados de teste bem próximos da realidade. O fabricante
retira comandos gráficos de programas conhecidos como, por exemplo, o programa
de construção Pro/ENGINEER...
kernel como medida da velocidade do
computador.
O tempo que um determinado computador necessita para traduzir o kernel,
no entanto, é estável, e quase não sofre
influência de circunstâncias como a
taxa de transferência de dados do disco
rígido ou a fragmentação do sistema de
arquivos. Nem mesmo para comparações
com testes anteriores ou com diferentes
arquiteturas de processadores a compilação do kernel é útil; as diferenças entre o
kernel atual e a versão de um ano atrás,
por exemplo, são muito grandes. Além
disso, o próprio compilador também sofre
constante aperfeiçoamento.
Por último, a configuração padrão
do kernel está em constante mudança,
e sempre são adicionados novos módulos. Por isso, os tempos de compilação
do kernel só podem ser comparados
quando dois computadores compilam
o mesmo kernel com as mesmas opções
de configuração, o mesmo compilador e
a mesma plataforma.
Precisão enganosa
O volume de dados do disco rígido local
é informado pelo FS-Bench [3], que se
baseia nos valores medidos por ambos os
benchmarks de disco rígido Bonnie++ [4]
e Iozone [5]. Como muitos outros programas de benchmark, esses dois informam
valores de medição com várias posições
depois da vírgula. Entretanto, essa suposta
precisão é enganosa: serviços que rodam
Linux Magazine #27 | Fevereiro de 2007
marks livres, mas até o momento surgiram ao todo apenas quatro benchmarks
de banco de dados [7], que cobrem cenários de aplicação variados, desde livrarias on-line a sistemas de mercadorias de
um grande atacadista. As especificações
dos benchmarks da OSDL se orientam
pelos renomados testes comerciais TPCW, TPC-C, TPC-H e TPC-App do Transaction Processing Performance Council
(TPC) [8].
Com o benchmark do MySQL, temos um segundo teste independente à
disposição. É importante ressaltar, no
entanto, que ele tira pouco proveito de
sistemas multiprocessados; portanto, é
indicado somente para o teste com computadores monoprocessados. Quem fizer
testes com o benchmark do MySQL em
sistemas multiprocessados estará sujeito
a fortes objeções por parte do fabricante
do processador e dos outros componentes do sistema.
Testes proibidos
paralelamente em segundo plano sempre
causam erros de medição que podem ser Implicações jurídicas ameaçam aqueles
detectados através da repetição dos testes. que não observam as condições de licença
Na prática, a diferença entre as taxas de para benchmarks e aplicações. Por exemtransferência são de apenas poucos KB plo, a VMware, fabricante do programa
por segundo. Isso também deve ser re- de virtualização de mesmo nome, proíbe
fletido em uma tabela e um gráfico, nos a publicação de resultados de testes de
quais arredondamos os valores relevantes praticamente todos os seus produtos, que
para MB inteiros por segundo ou para não tenham sido previamente conduzi1% do valor.
dos e liberados pelo fabricante.
Por um lado, isso equivale a uma
Para testes com servidores de arquivo,
o Dbench e o Tbench, da suíte de testes censura de imprensa, constituindo um
do Samba, já estão estabelecidos. Ambos potencial para inúmeras controvérsias,
são escaláveis para sistemas multiproces- pois até mesmo a declaração de que
sados, e por isso foram
utilizados pela Linux
Magazine International [6] para a comparação do primeiro servidor Dual-Opteron com
um Dual-Xeon (figura 3).
Assim como em outros
benchmarks de rede, na
suíte de testes do Samba
é obrigatório que o cliente e o servidor trabalhem
em uma rede de testes
própria, para eliminar as
interferências e a perda
de largura de banda devido ao tráfego de rede
de outros computadores
na mesma rede.
O Open Source Development Lab (OSDL) Figura 2: ...ou o programa de renderização Maya, diretamente do driver de placa
de vídeo. O computador de teste deve transmitir os comandos gráficos ao
trabalha há alguns anos
driver com máxima velocidade.
em uma série de bench-
35
CAPA | Benchmarks
Medidas perfeitas
Dbench
1400
Taxa de Transferência [MB/s]
1300
1200
1100
1000
900
800
700
Dual-Opteron 1,3 GHz (32 Bit)
600
Dual-Opteron 1,3 GHz (64 Bit)
Quad-Opteron 1,8 GHz (32 Bit)
500
400
Quad-Opteron 1,8 GHz (64 Bit)
300
Dual-Xeon 2,8 GHz
200
Quad-Xeon 2,8 GHz
Pentium4 3.0 GHz
100
Athlon XP 3000+
0
0
16
32
48
64
80
Número de clientes
96
112
128
Figura 3: O conjunto de programas de testes do Samba possui o Dbench e o Tbench, dois benchmarks de rede
que escalonam bem em sistemas multiprocessados.
um deteminado programa roda mais
rápido ou mais lentamente em uma
nova versão pode ser o resultado de um
benchmark.
A SPEC também formulou nas
licenças de uso de seus benchmarks
gratuitos algumas exigências mínimas
que devem ser respeitadas pelos realizadores de testes, em relação à publicação dos resultados. Elas dizem respeito,
em sua maioria, à documentação das
condições de teste, bem como à obrigatoriedade de disponibilização de alguns arquivos de teste e configuração
quando solicitado, para que a SPEC
ou uma empresa sem fins lucrativos
possa verificar as medições. Para que
essa avaliação possa acontecer de maneira independente, a SPEC requer até
mesmo que o hardware testado esteja
disponível em local público, e no caso
de protótipos, deve ser fornecida ao
menos a disponibilidade prevista.
Na interpretação dos resultados, independentemente de qual benchmark
tenha sido utilizado, em geral é necessário
prestar atenção; quem tiver, por exemplo,
atribuído a responsabilidade por um resultado a algum componente específico
da máquina deve se certificar da veracidade dessas informações. Por exemplo,
é fundamental garantir que a CPU não
esteja trabalhando no modo de economia de energia devido a configurações
incorretas do daemon de gerenciamento
de energia. O equipamento como um
todo também deve estar dimensionado
de forma correta: um computador que
não consiga disponibilizar nem 60 MB
de dados de teste por segundo, por exemplo, não é apropriado para informar a
taxa de transferência de dados máxima
de sistemas RAID. Esse tipo de engano
invalida totalmente qualquer medição
efetuada no equipamento.
36
Verificação
Alguns fabricantes relutam em aceitar resultados ruins, e contestam-nos.
Para testes na imprensa e em empresas, quando um importante contrato
está em jogo, é necessário que cada
fabricante verifique os critérios e procedimentos do teste. A Lexmark, por
exemplo, exige, em todas as avaliações de impressoras, os documentos
de teste utilizados e a configuração
do aparelho.
Nesses casos, aqueles que não estiverem aptos a fornecer a documentação
detalhada das condições de teste, dos
arquivos de configuração e dos dados
utilizados, acabam perdendo a possibilidade de confirmar suas suposições.
A obrigatoriedade da documentação
se aplica também a usuários particulares que publicarem em suas páginas
pessoais resultados de benchmarks
de seus computadores. Caso atestem
que, por exemplo, uma multifuncional tenha um scanner lento, devem
poder reproduzir esses resultados com
segurança. Do contrário, o fabricante poderia acusá-los de difamação ou
solicitar uma retratação.
Os limites de toner e tinta informados no teste prático diferem necessariamente em até 50 porcento
dos valores do fabricante, mesmo em
aparelhos para uso profissional. Em
testes realizados pela Linux Magazine alemã [9], duas impressoras laser
Lexmark e aparelhos multifuncionais
chegaram somente a cerca de 24.000
páginas, contra as 32.000 informadas,
com um toner cheio. Nas empresas,
entretanto, os custos de operação têm
importância decisiva, visto que a longo
prazo ele é mais alto que o preço de
aquisição dos equipamentos.
Mesmo tomando todos os cuidados necessários, nunca se deve esquecer, ao se
realizar um teste, de que os resultados
nem sempre contam toda a verdade. No
caso de computadores, existem tantas
variáveis em uma medição que é praticamente impossível calcular um erro
de medição de forma exata. Além disso,
é nos detalhes que mora o perigo: mal
se percebe, num teste de discos rígidos,
a execução de um updatedb por parte de
um cronjob. A taxa de transferência de
dados medida pelo Bonnie, nesse caso,
torna-se inaplicável, e a medição deve
ser repetida – o que o realizador do teste
deveria notar logo de início.
Considerando esse cuidado, a desativação de todos os serviços desnecessários e o monitoramento das tabelas de
processos durante o teste são requisitos
fundamentais para os testes amadores.
Portanto, apenas quem faz testes pode
chegar à melhor decisão de compra e não
ter aborrecimentos com o fabricante no
campo minado dos benchmarks. ■
Mais Informações
[1] Benchmarks SPEC:
http://www.spec.org
[2] Scott Wason, “How ATI’s Radeon 8500
drivers ‘optimize’ Quake III”:
http://techreport.com/
etc/2001q4/radeon-q3/
[3] Benchmark de sistemas de arquivos
em Linux:
http://fsbench.netnation.com
[4] Bonnie++, benchmark de disco rígido:
http://www.coker.com.au/bonnie++
[5] Iozone, benchmark de sistema de
arquivos:
http://www.iozone.org
[6] Mirko Dölle e Timmo Hönig, ”Linux
Sledgehammer” (Comparativo Dual
Opteron versus Dual Xeon, em inglês):
http://www.linux-magazine.
com/issue/39/AMD_Opteron.pdf
[7] Benchmarks de bancos de dados do
OSDL:
http://www.osdl.org/lab_
activities/kernel_testing/
osdl_database_test_suite/
[8] Benchmarks comerciais do TPC:
http://www.tpc.org
[9] Mirko Dölle, ”Bussiness Class”,
Linux Magazine Alemanha
10/2006, pg.86 (em alemão)
http://www.linuxmagazine.com.br