5 ms·

I'm not sure I understand, they're basically selling you less than one continuous CPU thread and upcharging if you use a full core? So suppose the machine has 5

I'm not sure I understand, they're basically selling you less than one continuous CPU thread and upcharging if you use a full core? So suppose the machine has 56 cores and they're putting 3 customers on each vCPU. What happens in the case that everyone needs to burst to the full performance of each thread they're paying for (56 * 3)? I imagine they'd price that as if you utilized 100% but give you degraded performance due to hardware limitations. Please correct me if I'm wrong but this sounds like "unlimited shared hosting for people who can SSH" (except you pay extra instead of unlimited)

wmf 8y ago
What happens in the case that everyone needs to burst to the full performance of each thread they're paying for (56 3)? I imagine they'd price that as if you utilized 100% but give you degraded performance* There's no reason to assume that. The hypervisor can track how much time each VM actually executed and subtract credits appropriately. AWS pricing is generally high enough that they don't need to use undocumented gotchas. I would say it's more like shared hosting with full AWS API and ecosystem compatibility. Shared hosting for people who can SSH is Digital Ocean.
awsinside 8y ago
T2 and T3 use live migration to get around this, but it's not public knowledge.
- dagenix 8y ago
  Why doesn't ec2 support live migration for more instance types?
  - lozenge 8y ago
    Why would they? None of the others are oversubscribed so it is guaranteed that the physical machine has the resources to provide everything that the virtual machine wants. Except network, but AWS doesn't guarantee anything about network speed. In the case of hardware failure, say a malfunction or an error detected by ECC RAM, most people would prefer the machine to be turned off and they can restart it, rather than continue in a potentially corrupted state. As all the storage is network attached, it can immediately be restarted on another physical machine.
skywhopper 8y ago
I'm going to guess that AWS is slightly more sophisticated than this, and has good data showing that the vast majority of users of this sort of instance type basically sit idle all the time. Certain customers may consistently max out their t3 instances, but those instances would be spread across thousands of host boxes, sharing resources with the tens of thousands of other customers who aren't utilizing the full capacity.
- londons_explore 8y ago
  That rarely works in reality. Lots of instances will all burst at the same time, for example when someone has thousands of T3 instances and then dumps a bunch of work into a work scheduling system, or when debians cron kicks in at exactly midnight. I'd much rather Amazon say "You have X% guaranteed CPU, and up to Y% extra cpu you can use on a best effort basis" I'd like to see the same for memory and disk too. For those who need fixed performance, there should be a setting to disable that best effort extra bit.
  - jdmulloy 8y ago
    The solution if you need fixed performance is one of the other instance types, so they don't need to make it a setting on the t* types since that's not what they're for.
  - blasdel 8y ago
    The modern instance families support Turbo Boost, which is the X% guaranteed and up to %Y extra best effort you desire. On many of the largest instance sizes you get P-state control which lets you "disable that best effort extra bit" — but most operating systems will by default use it to strategically burst some cores even more at the expense of others. Many workloads really just need a significant fixed amount of memory, and only periodically need high-performance CPU. T2 instances are much faster than you'd intuitively expect, if your workload is very bursty you can easily beat C4. The newer Unlimited model "just" removes the edge case of being throttled if you run out of earned CPUCreditBalance, so you no longer have to reason about its interactions with other scaling factors. It also allows a whole new usecase: if your workload doesn't need much memory or high I/O but will utilize as much CPU as it can get, you can save big by picking smaller burstable instances with Unlimited.
Szpadel 8y ago
I think it is more reasonable to compose it from mixture of big to small machines while keeping healthy margin for reserve. It is very much unlikely to get 20 machines above limit and top up all available cores. Also don't forget, that vCPUs most probably don't have any affinity to psychical cores

wmf 8y ago

What happens in the case that everyone needs to burst to the full performance of each thread they're paying for (56 3)? I imagine they'd price that as if you utilized 100% but give you degraded performance* There's no reason to assume that. The hypervisor can track how much time each VM actually executed and subtract credits appropriately. AWS pricing is generally high enough that they don't need to use undocumented gotchas. I would say it's more like shared hosting with full AWS API and ecosystem compatibility. Shared hosting for people who can SSH is Digital Ocean.

awsinside 8y ago

T2 and T3 use live migration to get around this, but it's not public knowledge.

dagenix 8y ago
Why doesn't ec2 support live migration for more instance types?
- lozenge 8y ago
  Why would they? None of the others are oversubscribed so it is guaranteed that the physical machine has the resources to provide everything that the virtual machine wants. Except network, but AWS doesn't guarantee anything about network speed. In the case of hardware failure, say a malfunction or an error detected by ECC RAM, most people would prefer the machine to be turned off and they can restart it, rather than continue in a potentially corrupted state. As all the storage is network attached, it can immediately be restarted on another physical machine.

skywhopper 8y ago

I'm going to guess that AWS is slightly more sophisticated than this, and has good data showing that the vast majority of users of this sort of instance type basically sit idle all the time. Certain customers may consistently max out their t3 instances, but those instances would be spread across thousands of host boxes, sharing resources with the tens of thousands of other customers who aren't utilizing the full capacity.

londons_explore 8y ago
That rarely works in reality. Lots of instances will all burst at the same time, for example when someone has thousands of T3 instances and then dumps a bunch of work into a work scheduling system, or when debians cron kicks in at exactly midnight. I'd much rather Amazon say "You have X% guaranteed CPU, and up to Y% extra cpu you can use on a best effort basis" I'd like to see the same for memory and disk too. For those who need fixed performance, there should be a setting to disable that best effort extra bit.
- jdmulloy 8y ago
  The solution if you need fixed performance is one of the other instance types, so they don't need to make it a setting on the t* types since that's not what they're for.
- blasdel 8y ago
  The modern instance families support Turbo Boost, which is the X% guaranteed and up to %Y extra best effort you desire. On many of the largest instance sizes you get P-state control which lets you "disable that best effort extra bit" — but most operating systems will by default use it to strategically burst some cores even more at the expense of others. Many workloads really just need a significant fixed amount of memory, and only periodically need high-performance CPU. T2 instances are much faster than you'd intuitively expect, if your workload is very bursty you can easily beat C4. The newer Unlimited model "just" removes the edge case of being throttled if you run out of earned CPUCreditBalance, so you no longer have to reason about its interactions with other scaling factors. It also allows a whole new usecase: if your workload doesn't need much memory or high I/O but will utilize as much CPU as it can get, you can save big by picking smaller burstable instances with Unlimited.

Szpadel 8y ago

I think it is more reasonable to compose it from mixture of big to small machines while keeping healthy margin for reserve. It is very much unlikely to get 20 machines above limit and top up all available cores. Also don't forget, that vCPUs most probably don't have any affinity to psychical cores