I think most "noisy neighbor" complaints actually come from the noisy neighbors. EC2 lets you use CPU resources of your neighbors if they aren't using them. So people hammer the machine and expect that level of performance, then when a neighbor does something and suddenly you are scaled back to only using the resources you actually pay for, you feel it is slow and complain.
But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are.
What you say might be true for CPU usage, maybe even for network usage, but definitely not for I/O. In that case it's definitely noisy neighbors causing problems for others, but in a way it doesn't matter. Whether it's noisy neighbors or hard resource limits, the variability is still there. For single-machine stuff you just have to assume the worst case. For things that are distributed among large enough numbers of nodes you can do a certain amount of averaging, but high variability still forces you close to the worst-case assumption.
I've run a lot of tests in this area, and even presented some of the results at LISA last month. When it comes to I/O, EC2 is considerably less consistent than many others[1] and that's what really hurts their users. Their prices might be only 2x someone else's if you're only looking at the average case, but it's more like 10x if you consider their extreme variability as well.
[1] Side note: this is a hint that Amazon has an unusually high oversubscription ratio. The same practice has been evident in shared web hosting, with the same effect, since that industry was created.
>But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are.
yeah, that's pretty much the crux of virtualization; it's a lot like buying bandwidth. Yes, your upstream is oversubscribing. Yes, if they do this right, 99% of the time, you won't notice the oversubscribe; you will get more service for less money vs. something that isn't oversubscribed. But, oversubscription needs to be managed carefully.
One thing I've noticed? If your upstream has a 1000mbps line, and sells 1000 unlimited 10Mbps ports, you are almost never going to see contention, even though it's a 10x oversubscribe.
If your upstream has a 1000Mbps port, and sells 10 1000Mbps ports? that's the same 10x oversubscribe. But I /guarantee/ that you will hit contention at least once a week. Probably more often. If people expect 1000Mbps reliable off that, they will be very unhappy. (Of course, if you setup your QoS properly, and tell the customers that it's 100Mbps CIR and up to a gigabit of best-effort burst? it can work out just fine. But nobody is going to get a reliable full gigabit out of that deal.)
90% of your users are using like 10% of your resources. But you've always got a few who are running torrents (or, in the case of CPU, mining primecoins) In the 1000 10Mbps port situation? it doesn't really matter if you've got a few bittorrent users. In the 10 users who can all completely fill the pipe situation? it matters a /lot/
That's the thing about CPU sharing, though; most of the time you don't put that many guests on one machine, and often you give each guest the ability to use the whole machine (when it's otherwise idle) - so you are in the situation of selling 10 1000Mbps links when you only have 1 1000mbps uplink, which ends in tears if anyone actually expects a reliable 1000Mbps uplink. (Now, if everyone understands that it's actually 100Mbps CIR that can burst to 1000Mbps, then sure, people can be happy. but you have to be careful with those expectations. With the 1000 10Mbps links on a 1gbps uplink, customers can treat their 10Mbps link as 10Mbps dedicated, and 99% of the time, they will get what they expect.)
"If your upstream has a 1000Mbps port, and sells 10 1000Mbps ports? that's the same 10x oversubscribe. But I /guarantee/ that you will hit contention at least once a week. Probably more often. If people expect 1000Mbps reliable off that, they will be very unhappy. "
I like that example.
Reminds me of account receivable and bad debt.
Better to have 1000 customers that owe you $30 each rather than 10 customers that owe you $3,000 each. I'm not factoring into this example the cost of billing or customer service. Strictly that if you have 1000 customers it's much less aggravating and you don't loose sleep at night worrying about a big customer that doesn't pay a bill.
Yup. And either way, you can solve the problem with capital. (Having a bunch of money laying around to cover the shortfall in the case of A/R, or having a very large burstable uplink with a small commit in the case of overselling bandwidth.)
Of course, burstable uplinks all suffer from the 'best effort' issue... if you go beyond your CIR, well, there's usually headroom, but not always.
But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are.