4 ms·

Yeah of course you can. Simply allocate each vm one core for each hyperthread and record the CPU time used in total. Nobody actually does this because it make

Yeah of course you can. Simply allocate each vm one core for each hyperthread and record the CPU time used in total. Nobody actually does this because it makes billing complicated. Both practically and for sales. My guess is this would result in overall less revenue as well, AWS is for sure making lots of money selling the same cpu time to a dozen people not actually using it.

wmf 6y ago
AWS is for sure making lots of money selling the same cpu time to a dozen people not actually using it. They "for sure" aren't; their prices are so high precisely because the resources are guaranteed (in most cases).
- pstrateman 6y ago
  The performance of EC2 instances varies significantly between instances. If the resources were actually guaranteed that simply wouldn't happen. Noisey neighbors wouldn't be a phrase people even knew if they actually guaranteed resources.
- jrockway 6y ago
  I agree with that. Amazon pretends to sell you "burstable" instances, but they know that most people are going to be bursting at the same time a day because most applications want low latency and host them close to their users, applications that are worth paying for are used by businesses, and business users use the app between 9-5 on weekdays. As a result, you don't get much bursting and the instances aren't much cheaper than non-burstable instances. Good resource utilization will only happen when you have non-interactive tasks that can be scheduled to smooth the demand. When I worked at Google, this is something we had; plenty of people were willing to run their mapreduces overnight, and take advantage of the purchased interactive capacity that other services needed during the day. In the real world, I've never had anything like that. Users use our website during the day. Employees use the internal apps during the day. Developers send their code off to CI during the day. That means from 9-5 there isn't enough capacity (builds have to wait) and from 5-9 the computers are just sitting there bored. I don't see a way around it, even at cloud provider scale, just because so many users are like me. I might be willing to send CI builds off to some part of the world where it's nighttime -- if you'll give me the CPUs for free. Nobody appears to have written software to do this (maybe the big CI providers do this in the background; but I haven't noticed a lot of latency while ssh-ing to CircleCI jobs for example), so we sit here using computers very inefficiently. Ultimately, computers are cheap enough that it doesn't matter. I have a 10 core workstation that sit idle most of the time. Having a fast build when I need one is nice; and the cost to have those cores sitting idle is minimal. I would be happy spending even more money on my workstation for that reason. I imagine people treat their servers the same way, and aren't tempted to tweak things because their workloads are interactive and autoscaling introduces latency.

wmf 6y ago

AWS is for sure making lots of money selling the same cpu time to a dozen people not actually using it. They "for sure" aren't; their prices are so high precisely because the resources are guaranteed (in most cases).

pstrateman 6y ago
The performance of EC2 instances varies significantly between instances. If the resources were actually guaranteed that simply wouldn't happen. Noisey neighbors wouldn't be a phrase people even knew if they actually guaranteed resources.
jrockway 6y ago
I agree with that. Amazon pretends to sell you "burstable" instances, but they know that most people are going to be bursting at the same time a day because most applications want low latency and host them close to their users, applications that are worth paying for are used by businesses, and business users use the app between 9-5 on weekdays. As a result, you don't get much bursting and the instances aren't much cheaper than non-burstable instances. Good resource utilization will only happen when you have non-interactive tasks that can be scheduled to smooth the demand. When I worked at Google, this is something we had; plenty of people were willing to run their mapreduces overnight, and take advantage of the purchased interactive capacity that other services needed during the day. In the real world, I've never had anything like that. Users use our website during the day. Employees use the internal apps during the day. Developers send their code off to CI during the day. That means from 9-5 there isn't enough capacity (builds have to wait) and from 5-9 the computers are just sitting there bored. I don't see a way around it, even at cloud provider scale, just because so many users are like me. I might be willing to send CI builds off to some part of the world where it's nighttime -- if you'll give me the CPUs for free. Nobody appears to have written software to do this (maybe the big CI providers do this in the background; but I haven't noticed a lot of latency while ssh-ing to CircleCI jobs for example), so we sit here using computers very inefficiently. Ultimately, computers are cheap enough that it doesn't matter. I have a 10 core workstation that sit idle most of the time. Having a fast build when I need one is nice; and the cost to have those cores sitting idle is minimal. I would be happy spending even more money on my workstation for that reason. I imagine people treat their servers the same way, and aren't tempted to tweak things because their workloads are interactive and autoscaling introduces latency.