amd64 slower than i386 on identical AMD 64 system?

[Ken Gunderson]

On Wed, 15 Mar 2006 06:01:25 -0300
JoaoBR <joao at matik.com.br> wrote:

> On Tuesday 14 March 2006 23:28, Kris Kennaway wrote:
> > On Tue, Mar 14, 2006 at 07:14:54PM -0300, JoaoBR wrote:
> > > I can confirm this too
> > > SMP amd64s are having constant crashes when running >2GB and <4GB of RAM.
> > > In order not getting anything wrong I am talking about X2-SMP
> > > mono-chip-MBs this is not happening on dual-chip-MB with two separate
> > > processors. I run the same hardware as UP-amd64 and it never crashes
> > > Since this crashes are more frequent with IPI_PREEMPTION I have now some
> > > servers under test running without PREEMPTION at all and appearently the
> > > crashes are gone
> >
> > Right, IPI_PREEMPTION is not stable (nor is it enabled by default).
> > Why did you decide to use it?
> >
> 
> for the obvious ... the never-ending-search for better performance
> BTW this option is very bad documented and no hint in NOTES that it may not 
> work
> 
> > > Overall the amd64-SMP kernels running on X2 processors are extermly
> > > sensitive to non polling NICs and are crashing often. The overall
> > > performance also is bad.
> > > Soon I change this cards into polling ones, seems XL is best, I do not
> > > have crashes anymore.
> > > Funny that single 64bit AMDs are running fine with non polling NICs even
> > > when running a SMP enabled kernel. Soon I put back the X2 ... boom.
> >
> > Crashing with or without the use of broken kernel options?
> 
> without,  SMP kernel but POLLING enabled
> 
> > > My servers are cache servers in first place and I have some web and mail
> > > server running amd64 and the cpu scheduling seems to work well. Overall I
> > > have the impression that the ULE scheduler is giving better performance
> > > on a machine with more than 2MB/s going through
> >
> > You need to be very careful when claiming bad performance: ULE is
> > well-known to perform badly on many workloads.
> >
> 
> well, read again
>  I said here that ULE is giving me BETTER performance
> 
> > In summary, you need to rule out whether your issues are resulting
> > from a poor choice of non-standard kernel options, or are actually
> > bugs in FreeBSD.
> >
> 
> obvious, but we often do not know all for sure so it's good talking about 
> 
> resuming my experience:
> 
>  SMP with single dual-core processors on standard MBs are sensitive (crashing 
> easily or time-outs) with non polling NICs
> 
> SMP with single dual-core processors are randomly crashing when >2GB and <4GB 
> on standard MBs
> 
> Both issues are not appearing at all when changing the X2 for a standard 
> athlon 64 processor, means same hardware, same OS version and kernel
> 
> Both issues are also not appearing when using the dual-core running same 
> hardware, same os version but UP kernel (only cutting options SMP).
> 
> I understand here that amd64 is still not dealing well with dual-cores and 
> more than 2GB of RAM

fwiw-- I have some dual cores (Opteron 165's and Opteron180).  All
on Tyan K8E updated to latest BIOS rev.  All have 2GB Crucial DDR400
ECC. Running FBSD-6.0- RELEASE w/o issues.  Stock kernel w/SMP
enabled.  After testing under FBSD one of them transitioned to XP Pro
(sigh...). Then saw 7K250 Nvidia4 issues under RAID1 when using supplied
drivers.  Updated drivers fixed that (at least last I'd heard).  The
other FBSD machines are using WD Raptors and gmirror.

I haven't seriously stress tested these machines but did run Memtest86+
for a couple days followed by a few rounds of Ubench.  Didn't keep the
results but seem to recall slightly better scores under amd64 than
i386. Or maybe the other way around.  In any case, to the best of my
recollection it was pretty close (substantial diff under ab though).
Subsequent use hasn't result in much load. No issues during buildworld,
etc. though, wh/is about as "stressed" as they get. Ya wanna send me a
couple hundred bucks and I'll be happy to do some testing w/4 gigs of
Ram...>;-P

Speaking of ram-- just out of couriosity, are you setting your timings
to 1T or 2T in BIOS??

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?