[Pan-users] Re: Re: ANN: Pan 0.14.2.90 "A Bouquet of Corpses"

[Duncan]

Douglas Bollinger posted <address@hidden>, excerpted
below,  on Sat, 29 Nov 2003 11:45:45 -0500:

> Are you running a 64 bit version of Linux?  I'm using a dual XP 2100
> right now for address@hidden crunching and general use. 
> It loves abuse and is running 100% CPU usage at all times and is _very_
> stable.  I'm probably going to bump-up to regular MP2800's just to max
> this system out this spring, but I'm definitely keeping a eye on the
> Opterons for down the road.
> 
> Bringing it back ontopic, if you are using 64 bit OS, has does Pan work?

Yes, Mdk 9.2 for amd64 rc1, plus a few updates.  Full release should be
shortly. and then 10.0 should be sync released along with the standard
i586 version, I think.  However, once 9.2 for amd64 releases, they are
hoping to sync with i586 cooker right away, and I was running that b4, and
am running not-yet-synced amd64 cooker presently, so I'll probably be more
or less continually upgrading with cooker, long b4 10.0.

As for pan, they already have a 64-bit rpm package for it (pan 0.14.2 with
9.2 amd64 rc1) that runs quite well.  The only thing is they don't enable
spell check in the official Mdk versions because they say its to hard to
switch spell-check languages on the fly.  (It's change the $LANG
environmental variable and restart PAN, but..)  Also, it's just easier for
me to always use the same format, and I often grab the new betas (as I did
this one) when only tarballs are available.  Thus, I keep pan in my urpmi
skip list so it's not updated with the Mdk version, and always compile
from tarball, which is running just fine.

I'm not sure whether it's the slightly faster CPUs I have now, or the fact
I am now running two, or my gig of memory as compared to my former half
gig, but PAN **DEFINITELY** starts up faster now.  It used to take over a
minute the first time, with my 4 gig PAN cache, but now loads in a far
more reasonable time the first time.  As well, with the gig of memory, it
doesn't drive all the PAN info out of cache as easily, so after the first
time, it usually starts almost instantly.

You are probably wise waiting to upgrade..  The second generation will of
course be faster and should have any bugs from the first gen worked out as
well.  It will also be cheaper (or faster still) and require less power
dissipation (or again be faster still).  As well, distrib support for it
is still not 100%, but it should be a few months down the line.

I knew I wanted a dual CPU system this time, as I realized the reason the
upgrade from 500MHz to 1.2G was a bit disappointing (after the upgrade to
my original 500MHz Athlon was far better performing than I ever expected),
was because I really needed a dual.  However, I really thought about
staying with 32-bit this round and waiting for the next to go 64-bit.  I
didn't because I kept the last round longer than I expected, and decided I
may have this one for some time, so I better go with the 64-bit if that's
what I thought I might want say two years down the line.

Also, it IS a hobby system, and I DO tend to run cooker and leading often
bleeding edge stuff on it.  Further, I wanted to vote my approval for
AMD's path with my wallet.  Finally, the port to amd64 is encouraging
removal of a lot of the cruft of backward compatibility in software (tho
it does run 32-bit and even 16-bit real mode, stripped down).  That has
the potential of increasing performance even more, when the platform is
fully optimized for.  IOW, no more loading majority i586 RPMs on something
multiple generations past that..  So.. I bit the bullet and did it.  I
don't presently have quite the same level of functionality or stability,
but I expect I'll match and then exceed it within 6-8 months if not
sooner.  (Mdk 10.0 is supposed to be out b4 summer, and I expect it will
at minimum match and in some areas exceed i586 performance and
functionality, cpu-tick-for-tick.)  Losing a bit of functionality now is
bad in one way, but then I made the choice in part BECAUSE I wanted the
experience of being able to grow WITH the platform.

As for this upgrade cycle.. I plan on investing in significantly more RAM
b4 I'm thru..  The board has 8 slots, for up to 16 gig of RAM, if two-gig
sticks are used.  I bought two half-gig sticks because right now that's
where the capacity "knee" is for registered ecc DDR memory.  I'd hoped to
get two gig sticks and upgrade to at minimum 8 gig eventually, but that
was about four times the price for twice the capacity -- as I said, 512 MB
is the current knee.  Thus, by the time I fill the other six slots, I can
probably buy the gig sticks to replace them ON TOP OF what I paid for the
two half-gig sticks, and STILL save $$.

I DO want to get two more half gig sticks to get full 128-bit x 2 memory
bandwidth, tho, b4 to long.  Right now, I have only 64-bit access on each
per-cpu bank, with one stick in each one.  If I double that to two sticks
per CPU, each CPU memory controller gets full 128-bit access, so I
effectively get 256-bit memory access bandwidth!  Of course, if the gig
sticks have come down by then, I'll get two of them, and pair the gig
sticks on one CPU and the half gig on the other, to at least keep that
interleafing going, even if I only get 256-effective over half the
gig-sticks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin