3 ms·

Regarding pricing is my assumption right: The Google CPU equivalent is Sandy Bridge, which was released in 2011 onward. While Amazon's is 2007 Xeon equivalent.

Regarding pricing is my assumption right: The Google CPU equivalent is Sandy Bridge, which was released in 2011 onward. While Amazon's is 2007 Xeon equivalent. Also their base memory is 3.75 GB, Amazon's small is 1.7GB. So would it be ok to assume the Google n1-standard-1 equivalent would perform better than medium on AWS?

justinsb 14y ago
Google said 50% better price/performance, and I believe Google's culture is less tolerant of marketing "exaggerations" than is Amazon's. As a simple, concrete, example: Amazon's GBs are 10^9 bytes; Google and the rest of the world defines them as 2^30. That's why EC2 instances have such weird memory sizes. So EC2's "17.1 GB" is what the rest of the world calls 16GB.
- saurik 14y ago
  No: hard drive manufactures and in fact most storage uses define gigabytes the way Amazon does. If you want to talk about gibibytes, please use tr appropriate terminology.
  - justinsb 14y ago
    Well, I think that's still controversial, but it sells hard drives. For RAM, I still buy a 16GB DIMM; if I buy it from Amazon I expect it to show up as 16GB, not 14.9GB. With EC2, that's not the case. But the point is that I trust Google, when I see something from Amazon I know to check the fine print.
- wmf 14y ago
  I'm pretty sure that is not the case. I couldn't find data for xlarge, but here's a dmesg snippet from a small instance: Memory: 1711020k/1748992k available (2071k kernel code, 28636k reserved, 1080k data, 188k init, 1003528k highmem) That's pretty close to 1.7 GiB. Here's a large instance: Memory: 7635512k/7864320k available (3204k kernel code, 388k absent, 228420k reserved, 3714k data, 500k init) That looks like 7.5 GiB to me, just as Amazon claims. 17.1 GiB is actually quite normal when you consider than Nehalems have 3 memory channels with 3 DIMMs/channel so you get numbers like 18, 36, 72, or 144 and then subtract some Xen overhead.
  - justinsb 14y ago
    Interesting - and your 9 DIMM argument makes sense. The large is exactly 7.5 * 2^30. The small is about 1.66 on the same scale, which isn't outrageous to round to 1.7. I guess I'll check the state of play on e.g. the 68.4 GB machine, which is where it would really make a difference!
- oh_sigh 14y ago
  Laughable. A GB is defined as 10^9 bytes. 2^30 bytes is a GiB, or Gibibyte. Just because you don't use appropriate terminology doesn't mean that Amazon exaggerates.
ajross 14y ago
That sounds about right. Sandy Bridge is faster for lots of stuff than Nehalem/Westmere, but not radically so for typical server loads (the larger, full speed L3 cache is the big differentiator). I figure it's 10-20% faster than a EC2 medium, 10% cheaper, and has roughtly equivalent storage and I/O. I don't think that margin is enough to drive customers. They need to be significantly cheaper than AWS.

justinsb 14y ago

Google said 50% better price/performance, and I believe Google's culture is less tolerant of marketing "exaggerations" than is Amazon's. As a simple, concrete, example: Amazon's GBs are 10^9 bytes; Google and the rest of the world defines them as 2^30. That's why EC2 instances have such weird memory sizes. So EC2's "17.1 GB" is what the rest of the world calls 16GB.

saurik 14y ago
No: hard drive manufactures and in fact most storage uses define gigabytes the way Amazon does. If you want to talk about gibibytes, please use tr appropriate terminology.
- justinsb 14y ago
  Well, I think that's still controversial, but it sells hard drives. For RAM, I still buy a 16GB DIMM; if I buy it from Amazon I expect it to show up as 16GB, not 14.9GB. With EC2, that's not the case. But the point is that I trust Google, when I see something from Amazon I know to check the fine print.
wmf 14y ago
I'm pretty sure that is not the case. I couldn't find data for xlarge, but here's a dmesg snippet from a small instance: Memory: 1711020k/1748992k available (2071k kernel code, 28636k reserved, 1080k data, 188k init, 1003528k highmem) That's pretty close to 1.7 GiB. Here's a large instance: Memory: 7635512k/7864320k available (3204k kernel code, 388k absent, 228420k reserved, 3714k data, 500k init) That looks like 7.5 GiB to me, just as Amazon claims. 17.1 GiB is actually quite normal when you consider than Nehalems have 3 memory channels with 3 DIMMs/channel so you get numbers like 18, 36, 72, or 144 and then subtract some Xen overhead.
- justinsb 14y ago
  Interesting - and your 9 DIMM argument makes sense. The large is exactly 7.5 * 2^30. The small is about 1.66 on the same scale, which isn't outrageous to round to 1.7. I guess I'll check the state of play on e.g. the 68.4 GB machine, which is where it would really make a difference!
oh_sigh 14y ago
Laughable. A GB is defined as 10^9 bytes. 2^30 bytes is a GiB, or Gibibyte. Just because you don't use appropriate terminology doesn't mean that Amazon exaggerates.

ajross 14y ago

That sounds about right. Sandy Bridge is faster for lots of stuff than Nehalem/Westmere, but not radically so for typical server loads (the larger, full speed L3 cache is the big differentiator). I figure it's 10-20% faster than a EC2 medium, 10% cheaper, and has roughtly equivalent storage and I/O. I don't think that margin is enough to drive customers. They need to be significantly cheaper than AWS.