The Xeon E5-2600: Dual Sandy Bridge for Servers
by Johan De Gelas on March 6, 2012 9:27 AM EST- Posted in
- IT Computing
- Virtualization
- Xeon
- Opteron
- Cloud Computing
SQL Server 2008 Enterprise R2
We have been using the Flemish/Dutch Web 2.0 website Nieuws.be as a benchmark for some time. 99% of the loads on the database are selects and about 5% of them are stored procedures. You can find a more detailed description here.
We have improved our testing methodology (read more about it here) and updated the SQL Server, so the results are only comparable to our last Opteron 6276 review (and not comparable to older ones than the latter).
Since performance/watt is an extremely important metric, we follow up with a power measurement:
The Xeon E5-2690 is by far the fastest in this discipline, but the difference power consumption compared to the rest of the pack is significant. The Xeon E5-2690 needs 140W more than its slower brother, the 95W TDP Xeon E5-2660. That is 70W extra per CPU. This clearly indicates that the fastest Xeon is running closer to its TDP than the 2.2 GHz version. The Xeon E5-2660 offers more than 20% better performance per Watt than the 135W TDP Xeon.
The Xeon E5-2660 is especially impressive if you compare it with the older Xeon. Despite the lower clockspeed, the new Xeon is capable of outperforming the Xeon 5650 by 30%.
Clock for clock, core for core the Xeon E5 is 23% more efficient at SQL Server workloads than its older brother. Considering that it is pretty hard to extract higher IPC out of server workloads, we can say that the Sandy-Bridge architecture is a winner when it comes to SQL databases.
Finally, let's check out the response times with 600 users sending off a query every second (on average):
Response times are more or less linear (and low!) when the server is not yet saturated . Once the server is closer to or over its maximum throughput, response times tend to increase almost exponentially. Since the Xeon E5-2690 is capable of sustaining more than 600 users, it can still offer a very low response time. The other CPUs are saturated at this point.
But as we pointed out in our previous article, server benchmarks at 100% are just one datapoint and we should test at lower concurrencies as well. Most people try to make sure that their database server almost never runs at 100% CPU load.
Facebook
Twitter
RSS
81 Comments
View All Comments
alpha754293 - Tuesday, March 6, 2012 - link
Thanks for running those.Are those results with HTT or without?
If you can write a little more about the run settings that you used (with/without HTT, number of processes), that would be great.
Very interesting results thought.
It would have been interesting to see what the power consumption and total energy consumption numbers would be for these runs (to see if having the faster processor would really be that beneficial).
Thanks!
alpha754293 - Tuesday, March 6, 2012 - link
I should work with you more to get you running some Fluent benchmarks as well.But, yes, HPC simulations DO take a VERY long time. And we beat the crap out of our systems on a regular basis.
jhh - Tuesday, March 6, 2012 - link
This is the most interesting part to me, as someone interested in high network I/O. With the packets going directly into cache, as long as they get processed before they get pushed out by subsequent packets, the packet processing code doesn't have to stall waiting for the packet to be pulled from RAM into cache. Potentially, the packet never needs to be written to RAM at all, avoiding using that memory capacity. In the other direction, web servers and the like can produce their output without ever putting the results into RAM.meloz - Tuesday, March 6, 2012 - link
I wonder if this Data Direct I/O Technology has any relevance to audio engineering? I know that latency is a big deal for those guys. In past I have read some discussion on latency at gearslutz, but the exact science is beyond me.Perhaps future versions of protools and other professional DAWs will make use of Data Direct I/O Technology.
Samus - Tuesday, March 6, 2012 - link
wow. 20MB of on-die cache. thats ridiculous.PwnBroker2 - Tuesday, March 6, 2012 - link
dont know about the others but not ATT. still using AMD even on the new workstation upgrades but then again IBM does our IT support, so who knows for the future.the new xeon's processors are beasts anyways, just wondering what the server price point will be.
tipoo - Tuesday, March 6, 2012 - link
"AMD's engineers probably the dumbest engineers in the world because any data in AMD processor is not processed but only transferred to the chipset."...What?
tipoo - Tuesday, March 6, 2012 - link
Think you've repeated that enough for one article?tipoo - Wednesday, March 7, 2012 - link
Like the Ivy bridge comments, just for future readers note that this was a reply to a deleted troll and no longer applies.IntelUser2000 - Tuesday, March 6, 2012 - link
Johan, you got the percentage numbers for LS-Dyna wrong.You said for the first one: the Xeon E5-2660 offers 20% better performance, the 2690 is 31% faster. It is interesting to note that LS-Dyna does not scale well with clockspeed: the 32% higher clockspeed of the Xeon E5-2690 results in only a 14% speed increase.
E5-2690 vs Opteron 6276: +46%(621/426)
E5-2660 vs Opteron 6276: +26%(621/492)
E5-2690 vs E5-2660: +15%(492/426)
In the conclusion you said the E5 2660 is "56% faster than X5650, 21% faster than 6276, and 6C is 8% faster than 6276"
Actually...
LS Dyna Neon-
E5-2660 vs X5650: +77%(872/492)
E5-2660 vs 6276: +26%(621/492)
E5-2660 6C vs 6276: +9%(621/570)
LS Dyna TVC-
E5-2660 vs X5650: +78%(10833/6072)
E5-2660 vs 6276: +35%(8181/6072)
E5-2660 6C vs 6276: +13%(8181/7228)
It's funny how you got the % numbers for your conclusions. It's merely the ratio of lower number vs higher number multiplied by 100.