Announcement

Collapse
No announcement yet.

Amazon EC2 Cloud Compute Performance: December vs. February

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Amazon EC2 Cloud Compute Performance: December vs. February

    Phoronix: Amazon EC2 Cloud Compute Performance: December vs. February

    For those wondering how Amazon's Elastic Compute Cloud (EC2) performance is now after being mitigated for the recent Spectre and Meltdown CPU vulnerabilities, here are benchmarks of five Linux distributions comparing the performance to last December prior to the Linux kernel mitigations coming about to now.

    http://www.phoronix.com/vr.php?view=25992

  • #2
    Missing space?

    Originally posted by phoronix View Post
    latest Amazon EC2 Linux benchmarkdata can find all

    Comment


    • #3
      Any word from Intel regarding new microcode? And if it is there, will this restore performance to pre-Meltdown/Spectre?

      Comment


      • #4
        The focus on CPU hungry processes is incorrect for the meltdown/spectre mitigations. Pure CPU takes almost no hit.

        Where you really suffer is with programs that are syscall heavy (context switching from userspace to kernel space). so look for network benchmark tools (traffic generation tools especially), or things that are I/O heavy (such as databases)

        Comment


        • #5
          Was PTI enabled on the instances? If yes as I suspect because updates were applied, then this is comparing apple and oranges... What would be useful would be to compare with pti=off which would really allow to test the hypevisor performance after they patched the hosts.
          My tests show that there was a big impact early January and then they rolled out a second update that made the mitigation really transparent, even for redis (if pti is disabled on the instance, but if the instance is just hosting one redis server, why would you enable pti? what secret is there to steal in the kernel or other processes if the only attack vector is redis itself?)

          Comment


          • #6
            Sometimes it's hard to understand is current comparison "Less is better" or "More is better". Especially on long posts when types are mixed. Maybe it's better modify all this bars to able represent comparison type by itself?

            For example:



            and




            or simple fill with ">>>>>" or "<<<<<".

            Code:
            transform="skewX(10) translate(-15,0)"
            stroke-width="0"

            Comment


            • #7
              Originally posted by wpupkin View Post
              Sometimes it's hard to understand is current comparison "Less is better" or "More is better". Especially on long posts when types are mixed. Maybe it's better modify all this bars to able represent comparison type by itself?

              For example:



              and




              or simple fill with ">>>>>" or "<<<<<".

              Code:
              transform="skewX(10) translate(-15,0)"
              stroke-width="0"
              Or two bars one above the other skewed opposite directions so that it actually "points" in the direction of improvement.

              There's also the option of simply flipping the base.. ie instead of N/s make it s/N so that everything remains more is better, or calculating an average of compared systems and then expressing everything as performance vs the average, and again that is always more = better.

              Comment


              • #8
                Were the tests done on instances that were paravirtual instances or HVM instances?

                The paravirtual instances have PTI patches put in by Amazon (the Xen patch). This was the patch that required reboots on all instances that were PV. For HVM instances, the fix is controlled by the customer (updated kernel). This is applies to Meltdown only.

                The Spectre V2 fixes are also by the customer. It can be fixed by running "retpoline" compiled kernels and applications. Microcode updates only comes into play when running on processors that are KabyLake or newer. It appears most (all?) of our instances are running on pre-KabyLake CPU's.

                Comment

                Working...
                X