No
DQ-FCT/UNL existem dois
alphas pertencentes a um dos grupos de investigação, uma
AlphaStation XP1000[1] e um
AlphaServer ES40[2], que são usados para puro
number-crunching.
No final de 2003 migrámos ambas as máquinas de
Tru64 para Linux, um
port não-oficial do SuSE 8.1, o que acabou por representar um
aumento de performance nada desprezável (se bem que eu não ponho as minhas mãos no fogo por aquelas instalações de Tru64).
Desde então têm funcionado perfeitamente, mas o SuSE 8.1 já não era novo naquela altura e dava jeito passar para algo mais actual.
A
XP1000 está sem uso há alguns meses, o que me deu a oportunidade de a actualizar esta semana.
Comecei por experimentar o
AlphaCore 0.9, um
port não-oficial do
Fedora Core 2 para alpha, com a intenção de actualizar logo a seguir para a versão
1.0a (baseada no FC3), que só está disponível como update através do
YUM, mas não correu lá muito bem...
A instalação correu sem incidentes, o que foi uma supresa agradável considerando que o SuSE 8.1 obrigava a criar as partições com o
fdisk numa consola "por trás" da instalação (porque só cria partições tipo-DOS e são necessárias partições tipo-BSD) e a configurar manualmente o
aboot (o equivalente ao GRUB) após o sistema estar completamente instalado.
Já o resultado final não foi
nada animador. Tudo era lento,
extremamente lento...
O
GDM demorar montes de tempo a arrancar, ou o GNOME arrastar-se, não diz nada sobre a capacidade de mastigar simulações, mas também não deixa grandes esperanças...
Perguntei na
mailing-list da Red Hat se isto era de esperar, e alguns possuidores de
hardware semelhante afirmaram que a versão 1.0a apresentava melhorias significativas de performance. Mas não existem
mirrors e eu não conseguia puxar os RPMs (para criar um repositório local) a mais de
2Kb/s.
Virei-me então para o
port do
Debian para alpha, a distribuição que me parece ser a melhor suportada nesta arquitectura e puxei a ISO do CD de instalação por rede do
Sarge (
testing), já que a versão
stable já tem barbas. Como existem
mirrors portugueses rápidos, não deveriam ocorrer problemas.
Realmente a instalação correu sobre rodas, com apenas um incidente: apesar de ter escolhido
1024x768 para o X, este acabou por ficar a
800x600. A parte chata é que o "dpkg-reconfigure xserver-xfree86" morria antes de gerar um ficheiro de configuração (sem nenhum erro...) e o "xf86config" só gerava configurações que não funcionavam (a primeira vez que vejo isto ocorrer, até porque esta máquina tem uma TNT2 M64
vulgaríssima em x86). Por esta altura o X já não arrancava sequer a
800x600, e eu já estava farto de lutar contra estas ferramentas... Um "/etc/X11/XF86Config" copiado de outra máquina - e alterado à mão, claro - resolveu de vez a questão.
Ainda não consegui perceber porque é que tanta gente acha o Debian a
oitava maravilha do mundo... Em alguns aspectos é um bocado
arcaico e
confuso, se bem que se pode alegar que eu estou apenas a ser tendencioso, uma vez que
o Debian não é bem o meu estilo. Eu prefiro um Red Hat ou SuSE, onde se pode usar sempre a linha de comandos e configurar as coisas editando ficheiros de texto, mas onde também existem ferramentas de configuração gráficas para dar o pontapé de saída.
Mas parece estar tudo a
funcionar bem, portanto as críticas acabam por aqui.
Só é pena não poder passar para o
kernel 2.6.10 (está a usar o 2.4.27), pois este dá um
kernel panic ao arranque. O módulo para o controlador SCSI ("qlogicisp") está quebrado no 2.6 e o resultado é um "Aiee!"
[3].
Mas antes de tomar a decisão de passar o
ES40 também para Debian, a primeira coisa a fazer é certificar-me que o
Compaq Fortran (as simulações são
todas feitas em
fortran) realmente está a funcionar como deve ser, o que só poderá ser feito por quem realmente as vai usar (e as desenvolveu), apesar dos meus testes com código avulso terem tido sucesso até agora.
O caso do
Compaq C e
Compaq C++ já é mais problemático...
Todos estes compiladores foram desenvolvidos para o Red Hat 6.0 (a julgar por alguns ".so", que incluem "_rh60" no nome), e as
binutils evoluiram bastante desde então, o que causa uma variedade de problemas (para além dos problemas causados pela conversão de RPMs para DEBs, que deixou coisas pelo caminho...).
O
Compaq C++ não gera objectos que o "ld" consiga linkar e não traz o seu próprio "ld", portanto é uma carta fora do baralho.
Já o
Compaq C "apenas" parece incapaz de lidar com os
headers da
glibc que não fazem parte do ANSI C ("sys/types.h" fá-lo engasgar-se, mas já o "stdio.h" ou "string.h" funcionam bem). Isto não é assim tão grave porque, se vier a ser necessário optimizar algum código C, sempre se podem compilar os ".c" mais críticos (que normalmente não usam nada de especial) com o
Compaq C e o resto com o GCC, já que os formatos dos objectos são compatíveis.
Se for código puramente ANSI não deverá haver qualquer problema.
Hoje andei a brincar um pouco com a XP1000, fazendo uns
benchmarks com o
nbench e comparando-a com o ES40 e um Athlon 2600+ (SuSE 9.2). Um dia destes talvez faça uns gráficos... :)
Por agora, e como isto já vai bastante longo, deixo-vos com umas fotos do
AlphaServer ES40 que deverão agradar a qualquer
geek que se preze:
- frontal (exterior) - a caixa é uma espécie de "rack" com capacidade para dois ES40 - este só tem um;
- frontal (interior) - 3 discos SCSI3 hot-swap, dois de 18Gb (um "fora-de-serviço") e um de 36Gb. (As manchas amarelas são mesmo pó.);
- topo (interior) - cada placa tem um CPU que controla 1Gb da RAM total do sistema, AFAIK o ES40 é uma arquitectura NUMA. (O interior não tem pó, curiosamente);
- lateral (interior) - sim, aquela placa com os "cubos" coloridos é uma placa de som. É uma "Creative AudioPCI 128" que usámos para experimentar.
[1] Alpha EV67 a 667MHz com 4Mb de cache, 256Mb de RAM.
[2] 4 Alphas EV67 a 667MHz com 8Mb de cache, 4Gb de RAM.
[3] Mas afinal parece que este módulo vai ser removido em breve, e o mesmo hardware é também suportado pelo módulo "qla1280". Mas não vou experimentar já, porque fazer isto remotamente é pedir para ser mordido pela Lei de Murphy...
