[EMAIL PROTECTED] wrote:
I don't have any facts or numbers to bring forward, but you probably
won't notice that much of a difference.
What do you base this opinion on?
Having said that, I would say go for the AMD64 port.
> I don't think the install is anywhere near less
straightforward than the 32bit port.
The AMD64 port is less straightforward because they do not include the
dpt_i2o driver, which is necessary for my RAID card. Instead, I have to
either use the i2o_block driver, which I gather has had some reliability
issues under load, or else build a patched kernel with dpt_i2o, which
isn't ideal since it always complicates and lengthens the install. Also,
for some reason, my own kernels always seem to end up being slower than
the stock kernels, even though I am careful to go through and build
in/enable everything very specific to the hardware.
But since you are running 4 Gig of RAM, take full advantage of it by
running amd64.
My understanding is that 32-bit can utilize up to 4 GB as well, it's
when you have more than 4GB that it starts to matter.
The developers have done a great job getting this port official and you
won't be disappointed with it. Its rock solid.
I know it's solid, it's been running in my server for over two years.
I'm wondering about real world speed difference between 32-bit and
64-bit given the fact that the 64-bit world is still not as complete in
terms of software support (dpt_i2o being case in point, but there is, I
assume, other software that isn't 64-bit safe yet as well). The 32-bit
version is also rock solid, even more so probably.
If you can, try both in a test environment, and then make your decision.
Perhaps there are some apache, or mysql benchmarks you can try?
This is my only server. It's production, and in colo. I don't have money
to have a multi-server setup at this time. When I take it down, the
whole shebang is down, and I need to get things back up again asap. So
it's going to be, ideally, a process of backing up the essential data,
rebuild, restore essential data, reconfigure for Etch, and go. Also, the
server is in Chicago IL, I am in Saint Louis MO, I don't have much time
up there. The colo company has to accompany me in to the datacenter for
security. They wanted to charge me $100 per hour to have someone be
there with me, but they are doing me a favor by not charging me for
their time. I know, it seems silly, but that's how they do it. I am
getting a relatively good deal on the bandwidth so it's worth keeping
them happy. Upshot is, I don't have unlimited time/opportunity to be at
the console installing and reinstalling operating systems, or mucking
around for that matter trying to get kernels patched. I know that once
we have the base system up I can do stuff via ssh, but we're talking
about console time here. Hence my desire to see how 32-bit would compare
performance-wise, because I know that has dpt_i2o built-in and will work
right out of the box.
Oh, and I would ask you if you have considered Software raid instead
of using an adaptec raid card? If you have time, try benchmarking
between them.
You might be suprised to see which one actually works better for you.
I don't know why it would be faster to use up my main CPU cycles doing
RAID rather than using the hardware RAID that is already in the box. The
guy that built my server seemed to think that this RAID solution was
very appropriate for this setup. In any case, see my previous paragraph
- I won't have time to mess around with testing different setups. Also,
from what I have seen of software RAID in linux, you still have to mess
around with making a new kernel with the RAID personalities built into
the kernel (rather than modules) to be able to boot off a software RAID
partition. The Adaptec makes it all transparent to me, the 4 drives
appear as one single drive and RAID 10 is done under the covers.
Does anybody else have any opinions on whether software RAID would be
faster than using the built-in Adaptec SmartRaid 2015S card?
For reference, my travails using dpt_i2o with AMD64 were documented here:
http://lists.debian.org/debian-amd64/2005/09/msg00201.html
Thanks,
/Neil
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]