> I have a Red Hat v9 2.4kernel with Fb 1.5 Superserver. I´am using ext
> 3 for the Partition Type.
> 100 users use thist Server to access a single Database.
> The Server Hardware is an IBM Server Series 206, with 3GB Ram and 2
> disks in Raid 1.

> Is this OS the best choice for my equipment ?

Unix is always a better choice if you've got support people for it, and
management/your boss lets you use it.
Windows has poor SMP support, and requires process affinity if you have
multiple CPU's to overcome scheduler inadequacies(process shuffling between
unloaded CPU's) when dealing with small numbers of highly CPU hungry
processes(SuperServer).

> Does Fb runs better with a Server 2003 and NTFS ?

It will run slower than a decent unix

> Does Fb Clasic Server run s better for 100 users with 3Gb of Ram ?

It depends on what your application does, and how it's used.

SuperServer has a large central cache where record sets are stored for quick
access by the same query run at a later stage. It lends itself strongly to
applications where the same information is requested very frequently, as
cache hits are faster than going down to disk, and pulling records.
SS, therefore, it great for OLTP (On-Line Transaction Processing) - short,
simple transactions and queries.
On the other hand, SuperServer is a single-process, multi-threaded model
server(and can thusly only use one CPU), and while all architectures of
Firebird have exclusive "serialized" sections where only one operation can
occur at a time(new page request, etc), SuperServer has the tendency to
stall other transactions/operations if a large, complex query is performed.
Rest assured, the other operations will be performed, but their requests
will be serialized, and done one after the other. Therefore, if it's deep
reporting you're after, SuperServer might not be the ideal choice.

Classic Server has a cache inside every process that's launched to do
database operations (one process per connection). If these connections are
re-used(persistent connections), the caches can result in very high speed
operation - at the expense of ram. On most OS's, each process has it's own
executable space in memory, then it's data space, which swells to contain
it's cache space, and can get large if persistent connections aren't closed
regularly.
On the other hand, Classic will scale enormously. It will use as many CPU's
as you can throw at it, and allow massive amounts of operations to be
performed simultaneously. Some sections of some operations are still
serialised, as Firebird needs to keep track of new/deleted pages, etc, but
it hammers along.
Deep, complex reports can be performed with little impact on other users,
especially if you're using SMP hardware. Very stong for OLAP (On-Line
Analysis/Analytics Processing).

So, in a nutshell, there is no one "Ideal Solution". There are two "Ideal
Solutions" - perfectly tuned and tailored to your needs.
Super Server:
Ram Usage: Low, with large central cache
Simple Query Speed: Amazing if it can pull from the cache
Doesn't like: Long, complex queries(Causes a pause on other operations
until complete)
SMP suitablilty: Poor. If allowed to swap between CPU's on a windows box,
it'll run like a dog, and can only use one CPU at the best of times
Ideal Uses: Web Content Management, POS systems, data aquisition, logging,
network traffic logging/recording

Classic Server:
Ram Usage: Medium to High, especially if persistent connections aren't
recycled
Simple Query Speed: Amazing if persistent connections are used, great
otherwise
Doesn't like: Not so thrifty with ram, and having multiple caches can
result in cache misses, meaning records will be pulled from disk if the
result is not in this process's cache
SMP Suitability: Brilliant. Scales almost linearly across CPU's
Ideal Uses: accounting systems, CRM, ERP, logistics/transport systems,
deep reporting systems.

Two ideal solutions, depending on your needs.

> Another Question.
> How can I check if The Raid Card is apropiate for my workload ?
> Can I see some statictis or something else ? I have not experience
> with Linux.

On FreeBSD, I can do a `systat -iostat 1`, and see the load on disk
subsystems. There should be a similar tool on Linux.

N.