Slashdot Mirror

I realize that the user stated they were only concerned w/ CPU load. Storage devices also generate significant heat when large transfers are occuring.

Maybe run an instance of Bonnie. This is a benchmarking tool for storage issues. It can be found at http://www.textuality.com/bonnie/

I use bonnie to test disk IO. It is a good reliable way to put the filesystem under load, and may help you determine if the scheduler is a problem.

Its one thing to turn on the echo ports and toss 1Gb back and forth to each other...its another to see what actual file transfers would be like. Of course, then you have to find disks that will keep up...

I'm not fond of Microsoft (indeed, some people consider me a 'basher'), but I don't think the majority of Slashdot's reaction has been rational in this case. For instance, some quick googling brought up the following comment by Tim Bray; he is one of the authors of XML, by the way. ;-)

From: MS Office 'Office 11' XML as Seen by Tim Bray

Justin Lipton wrote:

> Does anyone know or have ideas about what XML enabled Office 11 actually
> means?

I got an extended (hours-long) demo of Word & Excel & XDocs from JeanPa and a product manager whose name I don't have handy, two or three months ago, so things may have changed but here's what I saw:

Both Word & this new XDocs thing can edit arbitrary XML docs per the constraints of any old XSD schema. No DTD supprt. There are some of the usual XML editor goodies such as suggesting what elements can go here and picking attributes. They have pretty cool facilities for GUIfied schema customization. Neither of them can help much with mixed content, which has always separated the men from the boys in the *ML editing sweepstakes.

I'm not sure that either of them are really being positioned as general-purpose XML content creation facilities up against Arbortext & Altova & Corel. I'm not sure that market is big enough to interest MS anyhow. XDocs is (strictly my opinion) an attempt to build a desktop application constructor at a level that is a bit more declarative and open than VB, but richer & more interactive than a Web browser. I'm not really convinced yet - I think MS would agree there's still quite a bit of product management to do - but it does seem to be a pretty clever piece of software. I'm pretty sure it's safe to interpret the advent of XDocs as MSFT's declaration that they're not going to do anything with XForms.

What actually turns my crank is that you can save word docs as XML and they have their own "WordML" tag set that gets generated. I took a close look at this and it's pretty interesting. Very verbose - every word on the page gets its own markup. Suppose you have the word "foo" in bold with single-underline, the WordML looks something like:

<r>
<rps>
<rp class="bold" />
<rp class="underline" lines="1" />
</rps>foo</r>

When you get something like a Word table or floating text box the markup gets really severely dense and ugly, but I didn't see anything that seemed egregiously wrong, it's not pretending to do anything more than capture all the semantics that Word carries around inside, which are correspondingly severely dense and ugly. And HTML tables get pretty hideous too.

Why did I like this? I didn't see anything that I couldn't pick apart straightforwardly with Perl, and if someone asked me to write a script to pull all the paragraphs out of a Word doc that contain the word "foo" in bold, well you could do that. Which seems pretty important to me.

The idea is that you can have a Word document with all that formatting and then you can mix that up pretty freely with your own schema stuff, and have validation, then you can save it as Word (your markup plus Word's) or as pure XML (discards Word's markup, leaving just yours). The old Corel WPerfect SGML editor used to be able to do this too. [snip]

I think it would be interesting to take a look at an example WordML document. Unfortunately, I don't have - nor to I plan to get - the beta for Office 2003. Would anybody like to post an example document of what Word 2003 presents?

I didn't see anything that I couldn't pick apart straightforwardly with Perl, and if someone asked me to write a script to pull all the paragraphs out of a Word doc that contain the word "foo" in bold, well you could do that. Which seems pretty important to me.

Part II

Here's something interesting:

Cheaper & faster, too
Several readers, including an Apple sales rep, sent me references to a set of Xserve benchmarks on the Apple site. All of these show the Xserve beating competitive models from other companies, including IBM, Sun, and Dell.

What makes two of these results particularly interesting is that they show the value of optimizing software to take advantage of the hardware, reversing an effect I think of as "regression to the dumb" to achieve impressive results.

"Regression to the dumb" reflects, I think, the marketing tendency to focus on simple things that are easy to communicate in a volume market and elevate these simplifications to the level of de-facto standards. Engineers then have to accommodate these standards in product or process design.

The "megahurtz" wars, long a sore point for both Mac and Sun users, seem to illustrate this perfectly. Each new generation of x86 CPUs does less per cycle than the one before, but it drives the claimed megahertz number up because that's the number that moves product. Along the way, some very good technologies have been abandoned, and software developers have been taught to avoid making their code dependent on chip-specific features that could easily go away with the next iteration.

What happens if you look carefully at the technical advantages you've got and optimize your code and hardware accordingly instead of just going with industry-averaging practices?

1. Apple's PowerPC has an underappreciated facility marketed as the "velocity engine." This is actually a short-array processor with powerful features such as hardware FFT, but, like SPARC's VIS/SIMD, it's more honored in the breach than the observance.

   In this case, Apple's Advanced Computation Group, working with Genentech, modified an application widely used in genetics and related research to make maximum use of the facility. As a result, the Blast benchmark, which searches a genetics database for matches, shows the dual 1-GHz Xserve beating an IBM x330 with dual 1.4-GHz P3 CPUs by factors ranging from 5.8 to 21 (and a Sun V100 by up to 52 times) depending on the length and precision of the matches.

2. Internally, the Xserve has DDR (double data rate) memory feeding a 4-gigabytes-per-second data path to the CPU cache along with four ATA controllers -- one for each disk -- that operate as one. Using Bonnie to compare I/O to a Dell 1650 with dual 1.4-GHz P3 CPUs; SDR (single data rate) memory; and, a single Ultra160 RAID card with 128MB of buffer, Apple finds that the Xserve can be more than twice as fast as the Dell.

   Technically, I believe that there are two factors at work here: the Xserve has faster memory and a cleaner data path to the CPU, and Apple's four-way ATA design is both faster and cheaper than the single-path RAID card.

In both cases, better technology used in smarter ways wins. As in, duh? But managerially what they've done here is pretty cool because they're standing up for excellence instead of collapsing the technical tent and going off in search of volume.

On ext2, I see slightly faster (~10%) on per character io, and significantly faster (30-50%) on block io.

This is on the same partition on the same disk. The reiser page, of course, says how much faster it is than ext2, but I can't verify that. Has anyone else seen anything similar? I recently read a review of reiser that came up with the same results... although I can't find that review now.

I spent a fair amount of time looking at RAID 5 solutions this past summer for a client. Both external and internal, for Linux. Tried several different controller card brands and drive configurations, did a lot of reading, and bugged a lot of vendors.

You really should try to test your options and all of the configuration combinations using something like Bonnie, on a machine with a simular configuration to your target server. Make sure that your Bonnie test file size is at least twice physical RAM, to eliminate the effects of RAM and controller caching on the results.

I found that using 6 drives in a RAID 5 config was a LOT faster than 5 drives, most of the time. In fact, 3 drives in an array was faster than 5 in some cases. I think it has to do with the way the controller cards were calculating the distributed parity, and perhaps also due to things the driver was doing. 4 drives usually wasn't much better than 3, either.

Stripe sizes for the array can also make a big difference. 32k vs 128k, etc. Larger strips sizes are usually better for I/O speed, but you may find for email that having a higher number of random seek transactions per second is better than raw speed.

I did not get a chance to do any hard testing of multiple channel configurations with these cards. I suspect that splitting the I/O onto multiple channels would be a win.

IMHO, you definately want a i960 based board or system, with the fastest CPU you can find on them. I noticed a signifigant difference between boards with the 33Mhz part vs. the 66Mhz part.

FYI for others: for controllers, the AMI MegaRAID (alias Dell's PERC2/SC) just blows chunks. Older non-LVD, non-raid SCSI systems can run rings around it, at least on write speed.

It has been my experience that the write speed on a RAID 5 system is generally only a fraction of the reading speed, like 1/4th to 1/2. For a quick and stupid test, do something like 'time cat /proc/kcore > /tmp/kcore' and do the math for MB/second.

oh, and my current favorite card is the DPT Millenium V controller, using it in several systems in various places for the last 3 or 4 months. Here are some Bonnie results for a system with a DPT with 6x 7200 RPM drives, all on the same channel (internal) Linux kernel 2.2.10, dual P3 500Mhz:

-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1024 7637 97.5 16743 15.2 9561 19.4 8384 98.3 52923 36.2 583.2 9.0