(Not a support q., but anyhow...)

I'm in the process of moving databases from an old (DELL) machine to a new
one (DELL 2850). The old one has 2 Xeons (approx. 800MHz) and 512MB RAM,
the new one has 2 Xeons (3GHz, and larger cache than the old ones) and 2GB
RAM. Disk speeds are the same: 15000rpm (but different sizes). Probably
different specs for the RAID controllers as well - both are DELL's. Disks
are mirrored.
The old box is running Windows 2000 and Fb/1.0.3, the new one has Windows
2003 (SP2 I believe, it says version 5.2) and Fb/1.5.2 (SS).
[Yes, I can see a huge gain in speed with a faster server and a newer
Firebird version]

I haven't switched the HyperThreading off yet - just to see the effect of HT.

I observed cpu activity with the TaskManager while restoring a database.
Filesize of gbk: 1.4GB. Filesize of restored database: 2.5GB. The restore
lasted for about 45 minutes.
Pagesize 8KB, cache pages=8K (if that's relevant for a restore).
Default config file (except for the alias section) which means then
fbserver will use only one cpu.

While records were loaded TaskManager reported (in the "Process" window)
11-16% of cpu for the fbserver process, and 4-9% for gbak. The rest was
mostly the Server Idle process.
The four processor kernels (is this the correct name?) [K0-K3] showed in
the "Performance" window (approx!):
fbserver: K0=60% K1=20% CPU 0
gbak: K2=25% K3=25% CPU 1
The split between kernels is different for fbserver (60+20) and gbak (25+25).
When indexes were built, the picture was somewhat different:
fbserver: K0=60-100 K1=0
gbak: K2=0 K3=0 (naturally)
Building an index started out at about 60%, and then quickly rose to 100%
(and stayed there), but only on one kernel.
The indexes aren't declared 'unique', but in practice they are (or nearly so).
I didn't watch the whole process so I may have missed something.

Is there a "ping-pong" effect only when loading records? Why?
Do you think there will be any benefit in turning the HT off?


In my limited test, I haven't observed any delays when connecting from
remote clients. So far everything seems great, and I'm planning to move
production to this server during the weekend.


--
Aage J.