draft hardware guide, looking for comments/contribs

[Kai Stromler]

I've been grinding around on a guide to building x86/x86-64 systems for AMV editing and have finally reached the point where I've said more or less all I can, and would like help from other people with experience in hardware and/or systems. This is meant to be a best-practices guide rather than making specific recommendations.

guide: http://www-personal.umich.edu/~psdel/amvh/

Here's what I already know I'm not satisfied with in the current version:

There is a lot more that can be said technically about optimizing RAM selection for your particular situation that has not been discussed. A good technical discussion of what to look for from memory in those areas would be really helpful. I probably should also write up some notes on virtual memory (and why you should try to stay out of it) before this guide goes gold; I'm qualified on this end but just haven't written it yet.

Some notes on ATA/SATA would probably be very helpful, especially as it isn't discussed at all. I'm not familiar with this interface and what benefits it extends over IDE/EIDE, but that doesn't change the fact that it's the future, as well as a good bit of the present, of block device interfaces.

It may not be under scope, but there probably also should be some notes on general best practices for successful OS installation. I haven't been personally very successful at this, so my comments might not transfer as well in practice.

If anyone out there uses Intel and can discuss the benefits of HT to editing, it would be much appreciated. This guide tilts AMD-heavy and talks a lot of smack against the P4 architecture (much of which is deserved), but it's not right or valid to write Intel's engineers off as morons who don't know the first thing about chip design. It's probably not necessary to examine Athlon64 versus "real VLIW" chips.

The section on software price/performance could stand to be a lot more substantial, or just completely absent. That I'll leave as a judgment call informed by public opinion.

The actual system-building part is as long as fuck and maybe makes too many obscure jokes or references to semiconductor industry practices. Any help tuning it up will be greatly appreciated.

The guide might need a deeper discussion of cache, but I suspect not; if someone wants to write one, they’re welcome to it. The one serious point that's punted is that I didn't mention anything about out-of-order writes, but that’s a fairly deep operating-systems issue, and anybody who *wants* to modify their harddisk firmware to do write-through caching doesn't need this guide.

The first section could have been better laid out; in fact, the whole guide needs some more rigorous order to it. When I initially sat down to write this stuff, I thought it was going to come out a lot shorter.

Above all else, the guide probably needs more terms definitions -- unfortunately, all the stuff listed above is mainly of interest to experts, and the best way to see what terms need to be defined is to point a rank amateur at the material and see what they don’t understand. If you don't know anything about hardware, or are generally intimidated by the internal workings of computers, please take a look at the guide and report on what you don't understand. The intended audience of this guide feels confident in their ability to build their own system, but isn't totally informed about all phases of the process; however, we can't assume that everyone is going to have certain bits of information and lack certain others.

I might have posted this under Video Hardware as well, but this is somewhat of a "site" thing if it's going to be sent in as an official guide; hopefully people will help me patch up some of the above.

--K

[DrngdKreationz]

not done reading it.. but kudos on the Megatokyo reference.