Barry and company stated that our knowledge (not belief) of how 3.5 600Gb 15K RPM SAS drives perform was in error. Barry further said:

“If we see in the neighborhood of 125GB/sec from the newer drives, I’m buying the beer. J”

Barry, I feel you got a Get Out of Jail Free card and you do owe me a beer. You folks should not have closed down responses on the Partway There post especially after admitting that testing finally had proven to you what everyone else already knew.

Bad mojo. But I still want my beer.

The views expressed in this comment are my own and do not necessarily reflect the views of Oracle. The views and opinions expressed by others on this comment thread are theirs, not mine.

Are you referring to the point of this blog post? If so, it baffles me that you don’t (or choose not to) follow my point, but let me spell it out for you as simply as I can: Rick made and you supported incorrect assertions, pushed them as fact, without any research or data. If you don’t have either experience or data on something, you certainly should not be blogging on it unless you really have a desire for zero credibility. Take the time, do the research, get some numbers from the lab and then speak/blog intelligently.

You specifically mention:

“We see higher numbers [than 75MB/s] in disk tests, but never anywhere near 125MB/sec.”

Perhaps you would like to elaborate on how ParAccel runs their disk tests (and on what hardware). To demonstrate how poorly researched your comment is, I’ve run a simple disk test (output below) on drive in an Exadata V1 HP ProLiant DL180 G5 server which is able to perform at over 170MB/s, almost 100MB/s more than you have claimed to observed in tests!!! So it really raises the question: Why are your numbers so off base? Granted, application performance won’t achieve what a micro benchmark can, but still… It’s simply a matter of physics, not fiction.

There really is nothing interesting in that “white paper” from Teradata other than the amount of rubbish and FUD it contains. Papers are written by people, not companies, so the author’s experience and knowledge has little to nothing to do with how many dollars of hardware Teradata has sold. Have you any idea the I/O rates a Teradata system gets per drive? They’d be lucky to get 20MB/s with their I/O patterns (around 64K and random). Curt Monash reports “15 MB/second on their fastest disks” in this post. Why do you think that the Teradata 5555 system has 100 146GB (and maybe now the 300GB) 15K RPM FCAL drives per node (A 3/5 clique has 3 two socket quad-core Harpertown nodes [plus 1 spare] with 5 arrays each with 60 HDDs in it). Perhaps it would now seem obvious why Teradata is excited about SSD. With I/O patterns like that I would be too!

I digress…I’ve probably done more than enough technical research for you at this point…

[root@exadata-v1 ~]# dd if=/dev/cciss/c0d11 of=/dev/null bs=1M iflag=direct count=50000
50000+0 records in
50000+0 records out
52428800000 bytes (52 GB) copied, 302.569 seconds, 173 MB/s

[root@exadata-v1 ~]# collectl -sD | grep c0d11
# DISK STATISTICS (/sec)
#           Pct
#Name       KBytes Merged  IOs Size  KBytes Merged  IOs Size  RWSize  QLen  Wait SvcTim Util
cciss/c0d11 170604      0 1499  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 173180      0 1522  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 172684      0 1518  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 171488      0 1507  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 172156      0 1513  114       0      0    0    0     113     5     3      0   98
cciss/c0d11 172932      0 1520  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 172700      0 1517  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 170512      0 1499  114       0      0    0    0     113     5     3      0   98
cciss/c0d11 172776      0 1518  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 173584      0 1526  114       0      0    0    0     113     5     3      0   99
cciss/c0d11 170356      0 1497  114       0      0    0    0     113     5     3      0   99

Interesting that Teradata’s white paper also quotes 80 MB/sec. This is a company that has sold billions of dollars worth of hardware systems with disk drives. It reinforces that their experience matches my experience, but are now eclipsed by the newer drives. Additionally, it wouldn’t be in their interest to downplay the performance of the drives they rely on either. We should all thank Seagate and the other drive vendors for their improvements. These are the class of drives our customers deploy.

However, it is certainly unclear what he means by “saturate”. Certainly, if a drive delivers 125MB/sec and there are 5 concurrent requests, then each request will get 25MB/sec, more or less. On the other hand, combining that with the point of 8MB blocks is a little confusing unless he’s saying that big reads allow the percentage of time spent seeking to be ignored, which is true.

Thanks for posting the full link. I invite any reader to go to it. Good, bad or indifferent, you probably should have included a link to the Teradata document to allow the reader to draw their own conclusions – http://www.teradata.com/t/assets/0/206/276/87e1747c-7ccf-4be3-b812-1dba03dce5d7.pdf

Now you’re going to make me learn hardware. Like I don’t have enough to do? :)

The enterprise class SAS disks used by Exadata, rotating at 15K RPM, are capable of delivering data to requestors at about 80 MBps. To maximize I/O throughput, Exadata reads data off disk in large chunks. Exadata defaults to 8MB data blocks, with an option for 4MB blocks. At an 8MB block size, ten concurrent I/Os saturate a drive, even without allowances for seek time.

Out of those four sentences, three of them contain inaccurate (wrong) assertions. The most entertaining bit is the last sentence. Richard Burns apparently thinks that the throughput capacity of a HDD (in MB/s) divided by the I/O size results in the number of concurrent I/Os…but he would be very wrong. This is, however, some very creative math. I guess that is the difference between a consultant and an engineer. Engineers usually write papers for SIGMOD, VLDB, or similar and consultants write “white paper” FUD.

And Isn’t It Ironic…

I’m not sure why people don’t get this yet. If you do offer an opinion on something you should clearly state, IANAExpert or something along those lines.

I’ve never had a problem with not knowing something, but I tend to keep my mouth shut about it.

BTW, I think you should do more “editorial” type pieces…very well done.