Re: various rants about 7-currnet on AMD64

On Mon, Oct 01, 2007 at 03:30:59AM +0000, Aryeh Friedman wrote:
> Sorry for the negative tone of this message but a little background
> may help.... about 1.5 months ago I bought a new machine for personal
> use [my only machine actually]... hw (upgraded from a p4-2.8):

Understood; although your message does come off more as a "rant" than
anything else, it's worth hearing, since you have *incredibly*
bleeding-edge hardware.  I can't comment on the video aspects of your
system, because I don't use X (on any system I own/maintain).

> intel p35 mobo (ihc9)

This is an incredibly new chipset.  Heck, there's even reports of
driver issues on Windows.  I don't doubt the P35/ICH9 will be fantastic
(I'm a big advocate of Intel chipsets), but right now it *is* very new,
and you should keep that in mind.

I'd also like to know what motherboard vendor you went with.  You'd be
surprised how many issues are caused by BIOSes; there isn't anything you
or anyone else can do about BIOS problems, though.  It's all up to the
mainboard vendor.

> 6.2 --
> 
> * Horrid non-SMP kernel performence (acceptable after SMP was added)

In another thread you said installworld took 4 hours.  I have numerous
ICH7-based systems running RELENG_6 with and without SMP.  None of
them take 4 hours to installworld; heck, the single-CPU systems build
world in about 45 minutes.

> * Many TCP/IP stack issues

I *really* want to hear about this.  If there's any evidence you can
provide, I'm all ears.  I'm not doubting your claims, I just want to
know what you experienced.

Additionally, since you didn't state what PHY and NIC are used on your
motherboard, it's hard for me to accept that there's IP stack problems.
What PHY and NIC is on the motherboard?

> * Doesn't recognize PATA drives if installed at the same time as SATA

This is also worth expanding on.  This really sounds like a BIOS thing
though, although I can't deny that there's some ATA changes which need
to be addressed in 6.2.  Soren is working on all of them (both RELENG_6
and CURRENT), but he's limited for time right now.

> 7-CURRENT i386 --
> 
> * Horrid performence under default kernel needed to switch to
> ULE/IPI_PREMEPTION/DEVICE_POLLING

Expand on "horrid" if you could.  I run CURRENT i386 on my home machine,
and I've never had any need for device polling (in fact, I've never had
any need for it *ever* -- the one time I tried it back in the 5.x days,
the system became absurdly sluggish to keyboard input, serial I/O, or
anything else.  Network I/O was just fine though.)

> 7-CURRENT amd64
> 
> * Many desktop ports fail with i386 vs. amd64 errors

This is known.  There is a 32-bit compatibility shim in place on amd64
for libraries; you'll find /usr/lib (64-bit) and /usr/lib32 (32-bit) on
amd64 systems.  That is, unless you disabled building of them.  :-)
Easiest way to see if they're being used is to look at your dmesg -a
output and look for the ldconfig line stating what directories are used
in the library search path.

> Misc Rants:
> 
> CPUTYPE naming --
> 
>     For people who have been around for a while (read mid-90's) and
> have never used any AMD mobo's we are used to "historical" differences
> between early pentiums and amd equivs (for that reason I have never
> bought a AMD machine)... so calling the 64bit x86 architure amd64 is
> confusing and misleading.

Okay, you're confusing two things here: the "amd64" nomenclature used
on FreeBSD to describe the 64-bit OS, and CPUTYPE, which is used mainly
by gcc (and some portions of the /usr/src framework) to determine what
processor architecture to optimise for.

Regarding the "amd64" naming convention: I agree, but solely from a
"brand new FreeBSD user" point-of-view.  The first time I tried out
amd64, I went through the same thing you did: "but I've an Intel CPU,
should I be using IA64?"  I spent about 30 minutes reading on the 'net
and determined IA64 is in no way shape or form what I wanted.

Regarding CPUTYPE: if you want a good list of what all the CPUTYPEs are,
I recommend you look at /usr/share/examples/etc/make.conf and pick the
one that's most suitable for you.

The next question you'll have is: "how the heck do I know what's most
suitable?!".  There was a thread 5-6 months ago where someone made, more
or less, a map of CPUTYPE <--> processor conventions and posted it in a
thread about CPUTYPE.

In your case, you should be using CPUTYPE?=nocona.

> HARDWARE.TXT --
> 
>     hardware.txt sheds absulutly no light on the above issue except to
> make it clear that ia64 is not the right choice.

See above.  And yes, ia64 is not the right choice.

> Suggestions:
> 
> * Figure out why xorg should care if your on a 32 or 64 bit addressing
> bus (has to do with placing pci's buffers at the high end of RAM I
> think)
> 
> * AMD64 should be recommended (or at least better documented) for all
> dual-core machines

This argument is flawed, in my opinion.

I think a more appropriate phrase would be: "amd64 should be recommended
for anyone that uses 4GB of RAM or more, and doesn't want to be hit by
performance penalties induced by PAE on i386".

You see, dual-core really has nothing to do with it.  I recently posted
buildworld times on one of our RELENG_6 i386 servers (Intel C2D 6420):
19 minutes.  All of the servers we use have 2GB of RAM in them; if I
ever have the need to increase that to 4GB, I'll consider amd64.

For comparison, that CURRENT i386 box of mine is an AMD X2 3800+, again
with 2GB.  I tried amd64, and it worked, but I felt somewhat
uncomfortable with the whole 32-bit library shim thing going on.

As I mentioned, PAE is an alternative solution, but it's much more ideal
to run amd64.

-- 
| Jeremy Chadwick                                    jdc at parodius.com |
| Parodius Networking                           http://www.parodius.com/ |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |