Hardware Selection for AMD64 + Linux?

MrClever asks: "After a disaster involving my cat, a pot of coffee and my workstation, I am now in the market for a new machine. I thought I'd jump on the AMD64 wagon and keep running Linux. After some initial investigation, it became clear that ATi, Promise and other manufacturers don't have 64bit drivers for Linux, which rules out most motherboards with onboard P/SATA RAID, thus limiting my available choices. I know you can run 32bit on AMD64, but if I wanted that I'd get an AthlonXP. So, what AMD64 hardware is the best supported in 64bit mode under Linux? Seems NVidia have 64bit drivers, does anyone else?"

Comments

I think I know what happened

[CptChipJew]

You spilled coffee on your cat, causing 3rd degree burns. S/he starting meowing in pain and you jumped to the rescue, accidently knocking your computer off the desk.

Oh, you mean your cat just knocked the coffee onto the computer? Never mind...

Re:I think I know what happened

[phasm42]

You know what they say... you can lead a cat to coffee, but you can't make it drink.

don't buy an Athlon 64 until new socket comes out!

[Tumbleweed]

Wait for Socket 939 boards & CPUs - the current Socket 754 has a very limited lifespan. Socket 939 processors are due VERY soon now (just saw the first leaked report on one yesterday). FYI.

Of course, this doesn't apply if you're thinking about the Opteron, with its Socket 940.

Hardware RAID on the motherboard

[jmauro]

Most of the RAID on the motherboards are really software RAID that runs in a Windows driver or Linux driver. Since each slot usually shows up as a normal PATA or SATA device, one could then just use Software RAID under linux and get the same effect as the "on board" RAID under 64-bit x86.

Re:Hardware RAID on the motherboard

[Paladin128]

The difference with the on-board RAID on most mobo's is that you can boot to the RAID array. With pure software RAID, you need a non-RAID drive to boot from.

Re:Hardware RAID on the motherboard

[photon317]

The real difference is just that the exact layout of the raid is a pre-set standard by the BIOS vendor, and thus if you run Promise or whoever's softraid drivers in both OSes, you can have multi-platform softraid for a dual-boot setup. Linux boots just fine from a software raid device on it's own without this stuff, I assume windows can do the same.

Re:Hardware RAID on the motherboard

[aminorex]

But that "drive" can be a ramdrive, or a tiny partition which is mirrored and never mounted after
boot. I don't see the disadvantage, frankly.

Even the CPU cost of soft RAID is vanishingly small
these days, when caches are 2-8MB and CPUs are
approaching 5000 bogomips.

I see the difference as being MORE PORTS. Lets
me cram more drives into the box.

Re:Hardware RAID on the motherboard

[cheide]

Not necessarily, though there are limitations. LILO can't boot from a software RAID-5 array, but it can if it's RAID-1.

The way I've got mine set up is with /dev/hd?1 on each drive as a small RAID-1 array where I only put kernel images, /dev/hd?2 as the root filesystem in a RAID-5 set, and /dev/hd?3 as swap.

Promise works fine

[OrenWolf]

The Promise controller on the Tyan Opteron motherboards works perfectly in both Red Hat Enterprise Linux (with Update 2), and Fedora Core 1/2 for AMD64.. That same chipset (PDC20378) is available on Athlon64/AthlonFX motherboards as well.

Re:Promise works fine

[alienw]

Yep. I'm running an Opteron 140 on a Tyan Tiger K8WS motherboard. It's rock-solid, and it uses the AMD8000 server chipset instead of the crappy VIA one.

Re:Movies way of destroying computer

[daeley]

Since I hate in movies when someone pulls a gun and shoots a screen which magically destroys all the data on the computer

Unless of course it's a first edition iMac. :)

Consider 3ware...

[isaac]

3ware cards work a treat in amd64 systems with one caveat - using the PATA Escalade 7500-series cards on the Tyan Thunder K8W (opteron) MB is asking for trouble. The SATA cards work fine.

Promise is junk anyhow; it's not a hardware raid controller, just a dumb ATA controller card with software RAID drivers.

Just do your own software raid in Linux or buy a real (e.g 3ware) controller.

-Isaac

Re:Consider 3ware...

[iamcadaver]

Please elaborate.
I just deplowyed two Tyan Thunder K8W workstations equiped with Escalade 7500 RAID controllers.

Its on a research vessel ready to SAT and deport by mid next month. I've never heard anything about this.

*suddenly nervous*

Re:Consider 3ware...

[xoba]

would appreciate any links to or further info on troubles with PATA Escalade 7500-series cards on the Tyan Thunder K8W (opteron) MB. thanks! mike

Re:Consider 3ware...

[Anonymous Coward]

make sure your 7500s are on PCI-X A *NOT* B.
everything should be fine except the 7500s are a PoS. Hardware RAID like Intels boards are much better. or just use linuxes software raid which is much more stable anyway.

Re:Consider 3ware...

[Yenya]

Do not use 3ware 7506 with tyan boards - they are not compatible (details at http://www.3ware.com/KB/article.aspx?id=10964).

I have two Tyan S2882 (K8Spro)-based computers, and the 3ware 7506-8 works only in slot 3 (PCI-X bus A, IIRC), thus degrading the whole bus A (including two on-board gigabit NICs) to the 66MHz. After ordering a 3ware-recommended riser card it works in PCI-X bus B, and now I have 3ware board on one bus and two gigabit NICs on the other one, running at 100MHz.

Be sure to check Tyan and 3ware compatibility lists.

Other than that, 3ware is a great board, just make sure you run a Linux software RAID on top of it - it is faster (with more of RAM you can do more optimizations than the 3ware CPU wit 32MB of RAM).

And if you want an Opteron box, Tyan Thunders are excellent choice (their BIOS can even be managed via serial line!). Not sure about workstation use, though :-)

Re:Consider 3ware...

[Anonymous Coward]

I use 3Ware 7512 on Tyan S2885 K8W. It works perfectly.

I believe there was a problem with some older models of 75xx, so one should check before purchasing...

Re:Consider 3ware...

[kzadot]

Software RAID should be fine should it? After all in RAID the drives are more of a bottleneck than the CPU, so a few extra CPU cycles per RAID access wont slow anything down unless the CPU is already maxed out.
Of course hardware RAID is "simply better" than software RAID, but are performance differences very noticable?
I mean you are still getting the same benefits right?
In fact, isnt "hardware RAID" just embedded firmware running on the controllers CPU anyway? Surely once the software RAID drivers are loaded into the OS, we are looking at the same thing, except in one case the RAID software runs on the controller, and in the other case the system CPU.

I could easily imagine a situation where the system CPU is faster than the controller CPU, and this results in a "software RAID" thats actually faster than its hardware counterpart. (Probably not though, I am sure theres plenty of task specific optimizations available to controller designers)
Are there any performance comparisons online?

Software selection

[hackstraw]

Maybe you should either tell us what kind of applications that you want to run. Video drivers aren't too important for a headless box that sits in a closet.

I'm guessing that you are planning on running very large memory applications (> 2 Gig per process), otherwise 64bit support is useless. Especially since _many_ of Linux's applications still have 32bit limitations, even when compiled for 64bit platforms. I've run 64bit linux for 6 or 7 years now, and I'm still pissed that I run into 2Gb file size limits. Remember an int on 64bit linux is still 4 bytes as it is on 32bit systems, so each application has to either use size_t or long to get 64bit integers (which will work on either a 32bit or 64bit machine). Just today I had a user mail me with an error with rcp because it could not transfer a file that was 2.1Gigs. I believe 'cat' has the same limitation, unless it is done as a pipe. For example, cat over_2Gig_file > /dev/null will fail, but cat /dev/null will not. You will find these limitations from time to time, and rarely does the platform matter.

Also, Linux has other limitations like it cannot access a block device over 1 or 2 Tb (depending on the kernel version).

I think that the 64bit hype is amusing. I'm not sure, but an amd64 system running int 64bit mode might be slower than a 32bit offering from either intel or amd. You will have to look at the numbers, but they are hard to find. All of the benchmarks for the opteron that I have seen were run on 32bit applications that were complied with the _Intel_ compiler, or sometimes gcc (and then I believe that they were in 32bit mode).

My recommendation is to 1) kill you cat (just kidding), and 2) just by a stock machine that is either 32bits or look for an integrated 64bit system for linux already, or get a really nice 64bit system (but I wouldn't put Linux on one of those).

Re:Software selection

[Paladin128]

• I'm guessing that you are planning on running very large memory applications (> 2 Gig per process), otherwise 64bit support is useless.

Not at all true! AMD64 has twice the number of general-purpose registers available in 64-bit mode. Some apps also just run faster in 64-bit, like POVray.

Re:Software selection

[Paladine97]

Having twice the general purpose registers will typically improve performance 10-20% just by recompiling everything into 64 bit mode. The grandparent is smoking some major crack.

Re:Software selection

[Anonymous Coward]

I would like to point out that the speed gained on an Itanium or AMD64 is largerly b/c of throughput. Think Disk.

Re:Software selection

[hackstraw]

Having twice the general purpose registers will typically improve performance 10-20% just by recompiling everything into 64 bit mode.

Data please? this thread mentions povray, well this povray benchmark site clearly shows that the $259 amd64 chip is slower than the $200 Intel offering.

this site has some benchmarks. Note that they use gcc for the pentium machines, which is not a very good optimizing compiler. For floating point apps, I typically see 2x speedup when using the Intel compiler (like oggenc, povray, etc). I cannot say which is faster, but being that there is no good (free) compiler for the amd64 you will just have to take the numbers for what they are (meaningless).

The grandparent is smoking some major crack.

Damn, I've gotta be more discreet.

Re:Software selection

[Paladine97]

Well I did say typically improves, so it won't improve in all cases.

I too would be interested in seeing results from a highly optimized x86_64 compiler.

Re:Software selection

[alienw]

Ummm... Lay down the crack, man. The AMD64 platform offers many more advantages than just it's 64-bitness.

First, the Opteron has an integrated memory controller. That means FAST memory access. If you are running two of them on a dual-channel board, you get a really fast NUMA configuration. That's very important for applications that actually need to calculate stuff, assuming your OS supports it.

Second, it has twice the number of registers. That gives you a large performance advantage over IA-32 because apps don't need to constantly swap out variables into RAM.

Third, the Opteron has 1 meg of L2 cache. That is twice than what Athlon 64 or Mac G5 has, for about the same price. It sure as hell makes a difference, even for normal desktop use.

Also, I see no reason whatsoever to buy an expensive pre-built system when a really nice machine can be put together in a few hours for well under $900. I just upgraded my workstation to an Opteron 140 for only about $600. That's with a server-class board, 400W power supply, and 512 megs of DDR400 registered ECC RAM. Apple doesn't even offer the same features, and a comparable machine costs about $2000 from them. Not to mention that OS X is 32-bit.

Re:Software selection

[aminorex]

Grandpa's on crack again? Bummer. Well, at least
that's better than my mom on meth.

Re:Software selection

[aminorex]

You *do* know that registered RAM is shooting your
bandwidth to hell, right? Don't use registered
unless you need it for SMP.

Re:Software selection

[Anonymous Coward]

I'm guessing that you are planning on running very large memory applications (> 2 Gig per process), otherwise 64bit support is useless.

The AMD64 architecture has numerous other advantages over 386, besides just the address space.

Computing got corrupted when people started stressing "bits". It was worst in the Wintel world, when people used "32-bit" when they really meant "Win32 API" and "16-bit" when they meant MSDOS or Windows 3.x API. But that's another rant for another time.

Whenever someone talks about bitness, kick 'em. If the 386sx or 68000 a 32-bit processor or a 16-bit processor? It a Pentium4 with AMD64 instruction set extensions, a 32-bit processor or a 64-bit processor? Bah.

The path to enlightenment is to quit thinking of Opteron as a "64-bit processor" and starting thinking of it as a "kickass processor" that just happens to also support 64-bit addressing.

Re:Software selection

[alienw]

First, the processor/mobo requires it. Second, it doesn't affect the bandwidth, just the latency (and not that much). Third, you can actually fill all the RAM slots on the mobo without causing instability.

Re:Software selection

[Too Much Noise]

the recompile has to do with performance jumps of amd64 in 32bit mode vs. 64bit mode with the same compiler (gcc). Now, if you compiled the 32bit code with icc and had fp math that icc likes, you won't see much of an increase for gcc-compiled 64bit code vs. icc-compiled 32bit one. But you might still see faster code, depending on the particular app. That is due to a bunch of factors:

• scalar math w/ 16 SSE2 registers vs. vector math with only 8: you can balance out the timings between loads and math ops; in particular, unaligned loads hurt less (besides, AMD's SSE2 unit behaves about the same in scalar and vector mode anyway from typical benchmarks - if you really want timings for that I can check it)
  
• 64-bit registers mean easier data moves between GPRs and SSE2
  
• not least, cache and integrated memory controller issues.
  
• drawback: clock speed is actually important for fp math crunching, so athlon64 is handicapped here.
  

besides, those benchmarks don't show such a 'clear' difference. An amd64 3200+ slower by 5% than a p4@3GHz in 32bit mode w/ WinXP. Not exactly relevant for 64bit.

Re:Software selection

[Too Much Noise]

not just instability. Try filling all the slots in a desktop box (read: non-ECC memory) and you'll see the RAM speed throttle down. You get a trade-off, speed for size. Server-type memory doesn't have that problem with all slots full (different addressing scheme for ECC, if I remember correctly).

Re:Software selection

[turgid]

drawback: clock speed is actually important for fp math crunching, so athlon64 is handicapped here.

Only if your code and data are cache-bound. If you have large amounts of data c.f. cache size, and your FP code is not in tight loops (e.g. 1000s-10000000s iterations over a few 100 bytes of code) the Opteron's superior memory bandwidth will totally kick everything else's butt.

Re:Software selection

[Too Much Noise]

True enough - but not really everything else. Take Itanium2, for instance: large cache, high fp IPC count, low clock speed, slow bus. Large SpecFP scores (it's about the only thing I2 is really good at).

Re:Software selection

[turgid]

It'll be interesting to see what performance Cray gets out of its Red Storm Opteron supercomputer :-)

Re:Software selection

[Too Much Noise]

yes, although that's not going to be anywhere near my price range :-)

For what's worth, here are some numbers on performance increase due to extra registers. Mind you, this is just a dumb double multiplication loop.

• increase from simple (default compiler behavior for -mfpmath=sse) to explicit vector using 8 SSE2 registers: ~19%
  
• increase from simple to explicit vector with 16 registers: ~24%
  

Re:Software selection

[Visaris]

It's not ECC that allows more high-speed RAM on server class systems, it's the use of registered or buffered memory. See this.

Re:Software selection

[Too Much Noise]

You're right, my bad. I didn't ckeck that there are non-registered ECC modules, it didn't seem to make too much sense. Oh well, servers usually require both error-correction and buffered memory, but I guess there must be a market for non-registered ECC after all.

Search the support databases of linux distributors

[Rauchbier]

Maybe the support database of a linux company like SuSE may be helpful.

Re:Software selection (< > missing with cat)

[hackstraw]

the second cat command should be cat < over_2Gig_file > /dev/null

the 1st one took I guess because the < > were unbalanced.

Dyslexia?

[itwerx]

After a disaster involving my cat, a pot of coffee and my workstation...

I can just see it:

"So there I was, petting my cup of coffee and drinking my cat..." :)

SATA with promise chipset works

[MerlynEmrys67]

I am running Fedora Core 2 on a dual opteron Tyan motherboard. I have a 80Gig SATA drive that works fine right out of the box (FC 1 didn't see it though, in fact FC 2Test 3 didn't either)

Dual opteron just rocks

Re:don't buy an Athlon 64 until new socket comes o

[isorox]

64 bit is very fine and snazzy, but what are the consumer options and why do I want them? Lets assume I dont plan on having more then 2^32 bytes of memory for a while, why do I want a 64bit cpu?

Re:don't buy an Athlon 64 until new socket comes o

[Anonymous Coward]

because a lot of software can use 64 bits of data at a time in their maths loops which makes everything a lot faster ?

VIA BIOS problems

[S.I.O.]

I'm using a VIA-based Gigabyte m/b and basically everything works fine (SATA, sound), but the famous AMD HALT bug is still not fixed in the latest BIOS, so the kernel is running in polling mode. It means that the CPU cannot switch to sleep mode when there's nothing to do. *Very* irritating. BIOS coders are eventually more evil than trade mark/IP lawyers.

Re:VIA BIOS problems

[Anonymous Coward]

Some manufacturers have fixed this on some boards, but they have all been really slow about it.

There are two "sort of workarounds" for this problem:

"Workaround" #1:

You can turn off "Legacy Support" in your BIOS for USB 1.1 HID (input devices). The side effect is that, if you are using a USB keyboard, you have no control of the boot process until after the kernel boots (better set a timeout on your boot manager!).

So, if you do this and want to pass kernel arguments or select a different kernel or OS in lilo or grub before the countdown, you have to temporarily turn the option back on in your BIOS and then temporarily pass "idle=poll" in addition to whatever other arguments you were going to pass to the kernel.

But, if everything is good to go, and you don't mess with kernel arguments or dual-boot much, you can just setup your lilo or grub config to automatically timeout after a couple of seconds and boot a kernel with built-in usb hid and then you don't have to pass "idle=poll".

"Workaround" #2:

Use a PS/2 keyboard or a PS/2-USB keyboard adapter until they release a fix for your BIOS. Your mouse and everything else can still be USB, but it is the USB keyboard support provided by the BIOS that is causing the problem (kernel panics unless you pass "idle=poll".

I am using a PS/2 keyboard right now. Both of these "workarounds" are pretty lame. More motherboard manufacturers need to get their acts together and release BIOSes that fix this problem (known as CPU Errata 93).

Re:don't buy an Athlon 64 until new socket comes o

[Tumbleweed]

You may not want an Athlon 64 simply because it's 64-bit capable, but because it runs 32-bit x86 software (on average, depending on application, of course), faster than anything else. Even if you never run it in 64-bit mode, it's still the fastest thing out there, especially for the money. Don't worry about the 64-bit stuff for now.

Slackware doesn't come in 64bit :(

[arfonrg]

I just got a Presario R3000 (R3140US to be exact) and it's not bad.

Linux (slackware) runs just fine in 32bit mode. Even faster than the WinXP that came with it.

It's got the Nividia Video/sound chipsets, Broadcom wireless, RTL8139 ethernet, and modem built in. All I have working (the Broadcom needed the Linuxant driver but it's working like a charm).

I haven't tried the modem yet, but I may in the future.

To answer your question, Linux works fine in 32 bit mode on AMD64s. I'll let you know how 64bit Linux works when Slackware comes out with a AMD64 version.

Sorry to cut this short but, work calls

New Cat

[lcde]

After a disaster involving my cat, a pot of coffee and my workstation, I am now in the market for a new machine.

And a new cat.

Re:New Cat

[Cyrano_De]

I don't know, the penny pincher in me says to just format and re-install the old one.....

Re:New Cat

[SnoBall]

And a new cat.

Train it well in the ways of the /.

Re:don't buy an Athlon 64 until new socket comes o

[Anonymous Coward]

-why do I want a 64bit cpu?
In nerd-world, it means you have a bigger dick.

This proprietary driver situation sucks

[7-Vodka]

For some reason I'm finding myself extremely upset at companies refusing to release the specs to their harware and forcing linux users to use proprietary drivers. That's not what linux is about. There are a lot of us who actually care about using free software.
What's more it's really fucking inconvenient and I hate being forced to use lower-quality software because of greed.

I'm sure there are more than a few upset nforce users for example. The ones who aren't upset, wait till they find a bug or find their performance isn't up to par and take their problems to the lkml. They'll find out that since their platform is a black box they can't get any support and are stuck with what they're forced to use.

I was going to buy an nforce3 dual opteron motherboard but I can't stomach having to use a bunch of proprietary drivers.

I also used to think that it was ok if just the video card had a proprietary driver. It's just one driver afterall right? well apparently the slippery slope has slipped. From now on I will refuse to use any drivers which taint the kernel.

On top of all this, I have to really question the legality of all these proprietary drivers that are popping up. I know there were some threads on the lkml about this recently.
Basically they came to the conclusion that if a driver was written for another OS and merely released for linux as an afterthought it was legal. However if it was written for linux it came under a derrivative work and was not legal.

Either way... PROPRIETARY DRIVERS SUCK

Re:This proprietary driver situation sucks

[mattyrobinson69]

im sick of reinstalling nvidia's driver every time i recompile the kernel, so now i just use the standard nv driver

This is mainly because when i recompile the kernel, i might do

make xconfig ; make bzImage ; make modules ; make modules_install ; cp /usr/src/linux/arch/i386/boot/bzImage /boot/slackware ; lilo ; sleep 1m ; init 0

then configure the kernel in xconfig, then press save and close and it will compile and turn off. my girlfriend might turn on the computer the next day (especially if im not in) and not beable to use it, because the console is scary, etc

Re:This proprietary driver situation sucks

[Micah]

AMEN!!!!

Any idea which is the best video card that is well supported in 2D and 3D acceleration with totally Free/Open Source drivers?

I'm still using a Matrox G400, which is OK for now, but eventually I'll want to get something at least a little better.

new 64bit hardware sug

[cwg_at_opc]

i didn't see it mentioned here by anyone else, but as reported on a couple of (sites for one)
there's a neat new box coming out from IWILL that crams two(2) Opterons in a SFF case.
Unfortunately, if you need something now, this one will be coming too late for you unless you're a
developer/partner/etc:

"IWILL ZMAX based on nVIDIA nForce3 Pro 250Gb chipset will sample in July.
Volume production is planned in September, with a suggested price of $499.
IWILL plans to get attention in workstation market. ZMAXdp will include proprietary
form factor motherboard, 300W power supply, up to 2x3.5" HDD bay, and 1xAGP;
PCI and SI can offer various configurations for workstation market demand."

it sounds like it could be a nice little box...

other pre-built systems include:

Pre-built
Caliber

there are others, but I've lost my wish-list ;-)
You could also build one yourself, but I'd look for the nForce3 pro 250 or 250Gb, the NF3-150 didn't
exactly get extraordinary reviews.
Good Luck!

You can boot from software RAID-1

[Anonymous Coward]

I do it all the time. It is true that it just boots of the first responding drive, so a bad block halfway through the kernel image can hang the boot until drives are swapped (while a BIOS hook would allow changeover to a good drive mid-boot), but that's still awfully damn good.

Re:don't buy an Athlon 64 until new socket comes o

[BillyBlaze]

The x86 architecture is register-starved. AMD's extensions allow 64-bit code to make use of many more registers, which gives a performance improvement. Lots of fast cache helps, but not as much, because the cache can't reliably know what's needed next or most often, while the compiler often can. For example, Vorbis encoding has a 30% improvement when compiled in 64-bit mode.

Re:don't buy an Athlon 64 until new socket comes o

[Too Much Noise]

well, 8 GPRs + 8 SSE2 does not really qualify as "many more", but an increase of 100% in the number of available registers counts for something. Balance that against slighter larger memory usage due to the 64bit prefixes and pointers and you get ... about 20-30% speed increase on average.

YMMV, of course.

Precisely ...

[vlad_petric]

For modern processors accessing the register file is considerably faster than accessing the memory (even if the memory access doesn't miss in the L1 cache). With 8 GPRs, the compiler can barely alocate 3 for variables (the rest are needed by the compiler for other stuff). That number increases to 10->11 when going to 16 GPRs. This means that for small leaf functions you don't need to go to memory at all ...

The performance increases of 10-20% is precisely what people got by recompiling with gcc for AMD64. This is, indeed, the reason 64-bit architectures perform better than standard x86/32 bits (Itanium has 128 GPRs for instance ...)

Re:Precisely ...

[Anonymous Coward]

For modern processors accessing the register file is considerably faster than accessing the memory (even if the memory access doesn't miss in the L1 cache). With 8 GPRs, the compiler can barely alocate 3 for variables (the rest are needed by the compiler for other stuff).

Sorry, you're talking out of your sweaty anus here son. Why would a compiler need to tie up 5 registers, huh?

Re:don't buy an Athlon 64 until new socket comes o

[polyp2000]

Why do I want a 64bit cpu?

At the end of the day 64bit is the next step for general purpose computing. By jumping on the 64bit bandwagon you are preparing yourself for the future. Although at the moment you may find little advantages in speed or performance for certain tasks, as soon as the software begins to reap the advantages you will be ready.Generally speaking you aint going to lose a huge amount with 32bit backward applications, as soon as that 64bit "killer app" comes along you will be ready and waiting to enjoy the rewards .

64bit drivers...

[cwg_at_opc]

after posting some hardware sugs, i forgot about the driver issue:most of the newest 64bit driver work from the
major manufacturers appear to be for Windows(ech). ( Here's a review that came out today.)

The latest Linux drivers from nvidia aren't too old; their last nForce3 update was in Dec 2003 and the gpu drivers in Jan 2004

Tyan have a page of drivers, as does Highpoint, and Adaptec

Look into the suse amd64 message boards - they seem to be having some success...

My amd64 linux system

[riprjak]

is simple
MSI k8t neo FSIR2 motherboard (some issues with slow bios upgrades)
MSI Geforce FX5950ultra 256MB
Soundblaster Audigy
2 x 120GB ATA4 HDD
1 x 36GB SATA 10k drive
1 x dvd+/-rw CDrw combo
amd64 3200+
1 GB (2 x 512MB) kingston ddr333

This system runs gentoo 2004.1 64bit linux fine. SATA and PATA work fine, but there is not now nor, hopefully, will there ever be support for Software RAID as you find on motherboards (it is pointless feature creep IMHO).

Whilst I would say that ASUS appear to be on the ball with bios updates compared to MSI, my system runs fine (even manages wine using 32bit compatibility libraries and runs windows progs...).

I wholeheartedly recommend 64bit linux and would say that EVERYTHING works except high end ATI radeons (ATI couldn'f find their arsehole with two hands and a roadmap in 64bit terms) and many 802.11g cards (mostly due to the atheros binary driver crap, but support is slowly improving). Couple this with *no* support for software RAID (which is no real use anyway) and you nicely encapsulate most of the problems with 64bit linux. Sure, grub and lilo dont play well at 64 bit, so you will need a liveCD or a chrooted 32bit environment to build them (and some other apps); but 32bit apps execute fine as long as you have a set of 32bit libraries for them to play with.

Go for it, join us, we tools who double as early adopters... then you too can whine at manufacturers for their tardiness in supporting "production ready" 64bit OS'... lol

hope this helps...

err!
jak.

Re:My amd64 linux system

[Janek Kozicki]

does 3d hw acceleration work on your Geforce, did you have any problems setting it up?

do you think it will work on dual opteron? (I'm thinking about buying dual opteron :)

Re:My amd64 linux system

[riprjak]

3d acceleration (nvidia provided kernel dri and glx modlues) work fine on Xorg x11 (presumably on xfree too, but since their poorly adviswed license change, we consider xfree deprecated on gentoo for amd64).

I am using a udev based gentoo system, so the kernel module does not properly create the required device nodes, so I had to create them manually (nvidia, if reading, if the drivers were open source, we would fix this embarassingly poor programming for you!).

but the 64bit drivers released by nvidia work fine, I regulalry play ut2004 64bit :)

As for dual opterons, Im certain it will work a treat, since opterons and their mobos have been around almost a year longer than athlon64 et al. Other than some teething problems with highly optimised kernels and smp, I have heard no major issues working with dual opterons... I recommend a search of the forums on http://forums.gentoo.org/ if you are concerned.

err!
jak

non-executable pages

[j1m 5n0w]

otherwise 64bit support is useless.

Not at all true! AMD64 has twice the number of general-purpose registers available in 64-bit mode. Some apps also just run faster in 64-bit, like POVray.

Don't forget the new nonexecutable page flag! It reduces the severity of buffer overflows, which is far from useless in my opinion. (I'm not sure if the processor has to run in 64 bit for it to work, but as far as I know, its only available on the 64 bit chips -- someone correct me if I'm wrong.)

-jim

64-bit performance revisited

[kompiluj]

This is a comparison done on sparc platform between 64 and 32 bit modes highliting some performance issues. There are two most important things:

• Amount of performance you'll gain/lose when switching to 64 bit mode depends on the application you intend to run (for instance big gains on SSH/SSL )
• sizes of executables (programs, libs) are significantly larger in 64 bit mode

Of course in the case of AMD64 you will also gain something because of ability to use more registers, which is not the case with sparc.
And one more thing - do take a look at the Solaris 64-bit Developer's Guide. They have done the migration 32->64 long time ago. Learn from them.

Re:64-bit performance revisited

[jmauro]

One difference between Solaris 64 and Linux 64 is that most programs running on Linux will include the source and not have difficulties switching between 32-bit and 64-bit because it'll all be compiled into 64-bits. The ability to recompile everything is an advantage Linux has over Solaris in the move to 64-bits.

Re:64-bit performance revisited

[Anonymous Coward]

They used gzip, OpenSSL, and MySQL in their testing. Just because the OS is proprietary doesn't mean that all of the apps that are available for it are also.

third party drivers

[flex941]

Except for NVidia/ATI GPU's you do not need any other drivers from manufacturers. Everything is in kernel. And nobody will help you with kernel proplems if you have third-party drivers/modules loaded (have tainted the kernel). So stick with what kernel comes with and use NVIdia/ATI drivers for their GPUs if you really need 3d acceleration and such.

Re:Slackware doesn't come in 64bit :(

[turgid]

I wonder when Patrick will get round to doing it? :-)

In a moment of madness I though about installing bochs on my Athlon set up to emulate AMD64 and see if I could bootstrap a 64-bit Slackware compiled from source...

Major problems with Promise tech support

[Anonymous Coward]

I've been having major problems with Promise tech support. The technical support manager has NO technical background. The company has been unwilling to fix problems.

Re:Major problems with Promise tech support

[OrenWolf]

The driver in the kernel is *not* Written by Promise - bugs with it should be directed to the kernel maintainer, not them. :)

platform DOES matter

[David Jao]

Most of this post is just pure misinformation. Some of it has already been corrected in the replies. I will focus on the bits that have not yet been corrected.

Just today I had a user mail me with an error with rcp because it could not transfer a file that was 2.1Gigs.

For example, cat over_2Gig_file > /dev/null will fail

I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.

Perhaps your problem is that you're not compiling your applications using the large file support API, which all modern distributions do for you whenever possible.

You will find these limitations from time to time, and rarely does the platform matter.

You take a look at this screenshot and try to tell me that platform doesn't matter.

Also, Linux has other limitations like it cannot access a block device over 1 or 2 Tb (depending on the kernel version).

Ironically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.

Re:platform DOES matter

[hackstraw]

I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.

I realize that this could be corrected, even on 32bit systems, and that there are applications like tar that have had "large file support" for some time, but on my 64bit systems (alpha) running rh 7.1, this is not true. Upgrading is not really an option for me, and I consider them "remotely modern" because they are about 2.5 years old. I realize that compiling with the OFFSET_BITS or whaever the define is will give you large file support, but you cannot say that I did not have the problem with large files recently, because I did on the system that I mentioned.

ronically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.

This is regarding the 1 or 2 Tb limit. Well, I'm running RH AW 2.1 on 64bit Itaniums machines, and when I called RH support the polite Indian guy on the phone told me "maybe 4.0 will support this", I otherwise would have to partition my array. Logical volumes can be created beyond 2Tb, but block devices cannot. There are many kernel posts about this and this kernel trap article about it.

And you have corrected everyone by saying platform does matter, how? I still say for large memory applications, thats about it.

Re:platform DOES matter

[David Jao]

on my 64bit systems (alpha) running rh 7.1, this is not true. Upgrading is not really an option for me, and I consider them "remotely modern" because they are about 2.5 years old.

The person who submitted this Ask Slashdot question is considering buying a new AMD64 machine. Although I don't mean this in a harsh way, your own personal experience with a 2.5 year old linux distribution is not relevant to the submitter's situation, and you should not be using such experience as a basis for advice to someone in that situation.

If someone is purchasing new hardware today, it is pretty safe to say that the new hardware will be running a new operating system. To advise against the purchase based on your experiences with 2.5 year old versions of linux is, at best, not helpful.

Logical volumes can be created beyond 2Tb, but block devices cannot. There are many kernel posts about this and this kernel trap article about it.

Linking to a two year old kernel trap article is not very convincing, especially since the kernel trap article in question contains a fix for the very problem itself. I am quite sure the 2Tb limit for 64-bit platforms is fixed in Linux 2.6. The Linux LFS page dated 2004-04-21 claims that the 2Tb limit is only on 32-bit. However, I admit that I have not yet actually tried to create such a large block device.

platform does matter, how?

You take a look at this screenshot (again) and try to tell me that platform doesn't matter. The 32-bit platform on the left doesn't work, and the 64-bit platform on the right does work. That's pretty clear cut evidence to me.

Where to buy?

[ameoba]

Currently we (computer support for state university EE/CE dept) are looking into picking up some Athlon64 machines. The machines will be dual-booting Windows and Linux, most likely being used as fast 32bit machines.

The problem is that The Powers That Be insist on us purchasing the systems from a large vendor (Dell, HP, etc) and, from what I can tell, none of the large established vendors have Athlon64 systems available (HPaq has one, but it's in their 'home line' and not actually sold through their business division).

Plenty of people offer Opteron systems, but we're looking for a good vendor to pick up some Athlon64 systems from, does anyone know of one?

Re:don't buy an Athlon 64 until new socket comes o

[The_Dougster]

I had a HP9000 PARISC C-200 64 bit machine which I toyed around with for a year or so. I ended up selling it off due to the incredible amount of heat which blasted out of the back of the case. It was kind of nifty, but I never did manage to use any 64 bit software with it. If you were trying to do something like iterative numerical solution of systems of differential equations to a ridiculous degree of precision then 64 bit would be pretty cool, but you can do that kind of extended precision math on a 32 bit machine as well, albeit a lot slower.

I think that 64 bit systems are pretty cool personally, but for what its worth, I'm totally happy with my XP2400+. Cheap, powerfull, and stable. Three good things right there.

if you need to work now

[Schlacht]

Aopen AK86-L
WD HDDs
Aopen DVDROM/CDRW and DVD+RW
Nvidia FX 5900 Ultra
Redhat WS AMD-64

all's running awesome except I cant get damn palmPilot to sync : (

Re:don't buy an Athlon 64 until new socket comes o

[MindStalker]

Comparing your experience with HP 64 bit with future experience with x86-64 isn't really fair. AMD's 64 is the first 64 bit machine that average consumers and most importantly gamers are buying. If these people are buying in mass, you KNOW the software for it will follow. Noone bothered making software for HP 64 because there just wasn't the market for it.

Don't own one

[anti-NAT]

however, I think the ATI 9200 series meets your requirements.

The http://dri.sf.net project is the place to get the scoop on fully open source supported 3D cards.

Nvidia binary drivers aren't "specially supported"

[anti-NAT]

The kernel guys will ignore a system with them installed as well. They taint the kernel too.

I don't understand this comment please help

[Anonymous Coward]

Are you saying that if you buy a graphics card from any manufacturer other than ATI or nvidia, you will find that there is full, 3-d accelerated kernel support for those graphics cards?

Been there, seen that, got the t-shirt

[GoneGaryT]

Shit, this is a fun topic. Back in January, I built myself an AMD 64 3200+, Chaintech MoBo, 1Gb Crucial RAM, 80Gb IDE, 30Gb IDE, 2x 160Gb Seagate Barracuda, SiL SATA RAID0, AOpen CD-RW, NEC DVD+-RW, NVidia FX5900. And I'm running Windows XP Pro as my main OS because it's the most useful across all my apps.

I have SuSE 9 with a self compiled 2.6.5 kernel (no ROM drives and broken bits last fixed in 2.6.2-mjb), Gentoo stage 1 build with self-compiled Gentoo 2.6.5 kernel (lotsa missing kernel options) that just doesn't boot, Slackware 9 with self-compiled 32-bit 2.6.5 that *nearly* hits the mark except for KDE and all (at least it sees the SATA drives, if not as RAID0). Under SuSE, my lovely Sony USB 3.5 inch floppy shows up as a squillion drives or not at all in other builds. Create a boot disk? pffft! And NVidia 64-bit drivers? BWAHAHA!

FreeBSD 5.2 AMD64 is fast, dull, mysterious and very weird, but still lovable even though it doesn't see GRUB.

Windows XP 64-bit runs native 64-bit ports very well, but WOW (Windows On Windows) for your 32-bit apps sucks. "Does your 32-bit app run in 16 colours or 256 colours?". 3DBench that, people.

Then there's the Envy 7:1 surround sound. Win 32 land again only.

It may break my heart now, but all things happen in the fullness of time.

Tyan K8W (S2885) and two Opteron 242s

[Visaris]

I have two Opteron 242s on a Tyan K8W (S2885). Linux has great support for this sytem, and I am verey happy with it. The SATA controller works well, and linux supports the on-board gigabit ethernet controller. I have an AGP nVidia graphics card which is also supported in 64-bit mode. The on-board sound works and sounds great, and the FDD and IDE controllers are supported as well.

I run gentoo, and I would recommend that anyone useing linux on an AMD64 platform do so. I used SuSE 9.0 for AMD64 for a few months, and I was dissapointed with it. Gentoo seems to be much faster and more stable. If you're going ot run linux, also be sure you use a 2.6 series kernel because it has great K8 NUMA support.

This is the fastest system I've ever used, and I would recommend it to anyone!

Re:Nvidia binary drivers aren't "specially support

[flex941]

That's what I said.