% | $
Quotes you view appear here for quick access.

Intel Corporation Message Board

  • alexander.dumbass alexander.dumbass Dec 8, 2012 12:30 PM Flag

    Boston Viridis Servers

    New thread .... thank you Yahoo for state of the art message board. 8-)

    You have to be very careful when comparing benchmark results. Comparing benchmark results is a game. The goal of the game is to figure out how the benchmark publisher has "tilted" the results. Intel has done it but the ARM newbies have much to learn about this art of benchmarking.

    The Boston Viridis ARM Apache benchmarks are among the first released. There are some more per CPU results on Phoronix that I will have some comments on.

    Boston Ltd is a UK company that currently builds and configures servers based on AMD, Intel and now ARM CPU. It will be nice to have a single point of reference when discussing what can be done with ARM.

    Boston Ltd has announced it will be releasing a line of green (Viridis) servers on the Calxeda ARM chips. If I read it correctly, they have released a 32-bit server version that contains up to a dozen of the 32-bit Calxeda cards and is currently priced at $50,000. This configuration contains up to 48 4-core, 32-bit ARM CPU, 192GB of memory on 12 of their 4-socket boards. The system contains 24 SSD drives of size ???

    The server is a 192 32-bit core, 192GB system.

    The only benchmark that I can find is the Apache benchmark that they released on this new ARM system and compared it to a standard 80-watt Sandy Bridge system Xeon E3-1240 processor.

    Calxeda totaled the worst case power specs for the Intel CPU, memory and disk drives but not for their system.

    Calxeda matched the two configurations but the Intel CPU was IO constrained and the CPU was running at 14% load. They were comparing 14% of a Sandy Bridge to their solution.

    google for more detail on the first Intel reply to their Apache benchmarks.
    Xeon breaks Calxeda's ARM in Apache benchmark

    SortNewest  |  Oldest  |  Most Replied Expand all replies
    • Calxeda matched the two configurations but the Intel CPU was IO constrained and the CPU was running at 14% load. They were comparing 14% of a Sandy Bridge to their solution.

      That's the point of these ARM based servers. In any workload which is IO bound (such as a basic webserver) you rightsize the CPU to the task in had. In this case, the network port is saturated so you can't virtualize to increase CPU utilization, you have to add more (or higher bandwidth) network ports which add cost and power.

      It's worth reading Calxeda's response to Intel's response, quite funny:)

      Clearly it's still early days, and I'm looking forward to seeing full open benchmarks of whole clusters running rather than single nodes.

      • 1 Reply to theblueredmonk
      • I couldn't find the Calxeda reply to Intel. I need some more info ...

        "you rightsize the CPU to the task in hand"
        My problem is Calxeda chose a point workload that was right sized for their server and then said that the other server was not as good. To compare a workload that is tuned for your configuration and then to compare it with another system that has a different "tuned spot" is OK. They were just dishonest about computing the metrics to compare.

        Example: An older Atom D525 results on a Supermicro board yields 2100 requests per second on a dual core w/ hyperthreading.

        A Supermicro with a 1.6ghz Atom D525 CPU w/ 2 core and 2 threads measures at 2,100 requests per second. The Atom D525 is a 13W Pineview design released in Q2/2010. It operates at 1/3 the Calxeda performance and take 3x the power. It does not say where the bottleneck is or what that system configuration is other than a Supermicro X7SPF5 with a price of $199.

        The network connnection is with a Dual Intel 82574L Gigabit Ethernet Controller so I would have to assume that the Atom was CPU saturated like the Calxeda part.

        Specifications Mfr Part Number: X7SPE-HF-D525-O
        CPU: Integrated Intel Atom D525 processor(1.8GHz)
        Chipset: Intel ICH9R
        Memory: 2x 204-pin DDR3-800 SO-DIMMs Slot, Single Channel, Non-ECC, Unbuffered, Max capacity upto 4GB
        Slots: 1x PCI-Express x4 Slot (runs on x16 Slot)
        SATA: 6x SATA2 Ports, Support RAID 0, 1, 5, 10
        Video: Matrox G200eW Graphic Controller
        LAN: Dual Intel 82574L Gigabit Ethernet Controller
        Ports: 8x USB 2.0 Ports (2 rear, 5 by headers, 1 Type A connector); 2x PS/2 Ports; 2x Serial Ports (1 rear, 1 by header); 1x VGA Port; 2x RJ45 LAN Ports
        Form Factor: Proprietary, 7.5 x 6.75 inch / 19.05 x 17.15 cm
        Package: Retail
        RoHS Compliant

    • Part of the AMD settlement was INtel compilers could no longer turn off the optimizations when it recognized an AMD CPU...

      • 1 Reply to getanid61
      • Yes. True. Now Intel HAS to make the assumption that the silicon supports a feature the way the Intel CPU does if the feature bit is on.

        It is not about the compiler but more about the hand optimized runtime libraries that are shipped with the compiler. The issue is more complex than the simple minded thinking "Intel cheated" and "AMD had to go to court for a fair deal".

        Now, the Intel runtime library code checks the FEATURE bits and if set, assumes that the feature is properly supported on the silicon. If the bit is set, is an AMD CPU and it has a bug, there is no way to turn off the feature and no way to avoid running the program on the AMD CPU.

        There are some subtle differences in the way AMD handles the AVX instructions. The GIMP math library built with GCC runs fine on Intel Sandy Bridge but fails intermittantly on the AMD Bulldozer parts when using AVX instructions. AMD users cannot correctly run the program and if the program was compiled with the Intel compiler could not check to see if it was on an AMD part.

        For some fun reading, google
        amd avx problems

35.15-0.28(-0.79%)Oct 21 4:00 PMEDT