[cooker-amd64] RC1 installation report

[Jeremy Barnes]

Hi everyone,

I thought that I would document the result of installing the RC1 for the 
benefit of the list.

Summary: had a usable 64 bit system running our complete 32 bit environment 
seamlessly with a semi-complete 64 bit environment within 2 hours.

Machine: dual Opteron 246, 6GB RAM.

Tyan Thunder K8S Pro S2882 board:
  - Adaptec 7902 SCSI
  - Sil3114 SATA controller
  - BCM7504 2xGBe, Intel 82551 10/100 ethernet
  - ATI Rage XL integrated graphics
  - AMD 8111/8131 southbridge (?)

Disks: 1x73GB scsi, 1x250GB SATA

Plextor DVD-R drive.

Nothing in the PCI/PCI-X slots.

32 bit Mandrake 9.2 ix86 installation: everything was fine, except that it 
didn't autodetect the scsi (had to select 79xx driver) nor the SATA (couldn't 
find one, so I left it; this was a test anyhow).  Everything works fine; we 
installed as per our standard 32 bit desktop machines with no problems.

64 bit Mandrake 9.2 amd64 RC1 installation: exactly the same process, exactly 
the same problems (no SATA, had to select the SCSI disk).  I haven't tried 
messing around yet with the ACPI parameters to try to get the SATA working.  
Nor did I try individual package selection.

The goal was to emulate our 32 bit environment on the machine, so that we 
could continue using it just like any of our current servers, and gradually 
transition over to 64 bit as time permits.  We have a standard 9.2 
distribution on all our 32 bit machines, with a whole stack of custom-built 
RPMS against 9.2.

I tried installing the 32 bit RPMS from 9.2/x86 for those that didn't come 
with 9.2/amd64 (there are several which didn't make it in, I guess due to non 
64-bit cleanliness), and then our custom 32-bit rpms.  I was not expecting 
success: amazingly there were only two small problem (see below), and we are 
able to both compile and run 32 bit binaries on the machine, running under a 
64 bit kernel.  I am very impressed.

Authentication, etc uses LDAP and went off fine with only the small problem 
indicated below.

Problems with the environment:
- Our auto-setup script expected the PAM modules in /lib, but they are in 
/lib64.
- The popt package installs libpopt.so.0, but no libpopt.so symlink.  This is 
for both 32 and 64 bit.  I had to create this manually.
- Our auto-setup script calls URPMI after adding some package sources to the 
list.  In order to satisfy dependencies, we have to point it to both 9.2/x86 
and 9.2/amd64.  It then proceeded to ask us many questions about which 
version we wanted, the libxxx or lib64xxx.  Maybe this could be made smarter 
to know that the lib64xxx includes the libxxx, and so the choice is 
unnecessary.
- It would be good to have a JDK
- (Not a problem with Mandrake): Generating both 32 and 64 bit versions of our 
custom libraries is not an easy exercise.  It involves lots of RPM specfile 
hacking, since most packages are not set up to allow this.

Benchmarking: I have only one result, which is a floating point intensive 
simulation of a particular linguistic language model, in C++ and hand-tuned 
SSE assembler.  About 50% of the time is spent in traversing large dynamic 
state machines, and the other 50% of the time is spent in calculating a 
vectorised kernel over a couple of megabyte working set.  (I can't be more 
specific).  The same 32 bit binary was run on both machines.  For us, it is a 
very real-world benchmark.

Dual Athlon-MP 2000+: 103 seconds.
Dual Opteron 246: 57 seconds.

I would put this mostly down to the improved memory subsystem and larger 
on-die cache.  This algorithm is very hard on the cache.

Compiling seems a little faster on the opteron (maybe 30% faster), but not 
nearly twice as fast like our language model.

In summary, it took me very little time to have a useful machine which, 
despite running the same 32 bit binaries as always, has access to the full 
6GB of memory and runs our simulations nearly twice as fast as our old 
machine (granted, not the top of the line anymore).  This is very impressive.  
Migrating to fully 64 bits is going to be quite a lot of work, due mainly to 
3rd party packages that are not 64-bit clean, but is not necessary due to the 
excellent compatibility with Mandrake 9.2/x86 packages.  The Mandrake 
installers (both x86 and amd64) could do with some work on detection of SATA 
hardware and SCSI drivers (or a prominent note somewhere about how to enable 
them), and urpmi could do with some more intelligence about biarch packages.  

I would say overall that it is excellent work by everyone involved.

Cheers,
Jeremy