3 ms·

The oversubscription model actually works, just like insurance does. We consume massive amounts of bandwidth on a continuous basis due to thousands of servers c

The oversubscription model actually works, just like insurance does. We consume massive amounts of bandwidth on a continuous basis due to thousands of servers checking in. (We're not spikey in our bandwidth or CPU -- we're surprisingly rigid at 87% to 90% continuous.) We're anomalous, which kinda proves the point. What is ironic about your statement is that t2 CPU allocations are massively oversubscribed in the same way. (but far more aggressively!)

jsmthrowaway 11y ago
A former Linode employee, actually (why did you edit out the ad hominem accusing me of working for Amazon?), but my employment is irrelevant to pointing out that over subscription means you are not actually getting what you pay for. If everybody used it you wouldn't have it any more. It's not yours. You are deciding entirely on perceived instead of actual value. And yes, AWS's CPU over subscription on these instances is important if your workload is CPU intensive. They're very quickly outgrown due to that but useful in a pinch.
- icebraining 11y ago
  over subscription means you are not actually getting what you pay for. If everybody used it you wouldn't have it any more. It's not yours. You are deciding entirely on perceived instead of actual value. I don't agree; as long as you can always use it when you needed, you are getting what you paid for - that's actual. What you're talking about is the value in an hypothetical situation. Now, if you are actually impacted by the oversubscription, then the actual value is below what was promised, but that doesn't seem to be the case for jamiesonbecker's use of DO.
- derefr 11y ago
  Like the parent said, it's just like insurance. You can get what you pay for, because almost everybody else is paying for something they don't use, just in case they need it—and there's no situation where everybody's "just in case" will happen at the same time. Aggregated traffic is predictable in a way that individual flows aren't; you can have enough surety to stake your business on giving some of your customers a throughput/latency SLA, without reserving any circuits for them—because you know that even the peak of your traffic's froth is predictably below your uplink's capacity, and that there's no way for this fact to change on a timescale small-enough that your staff can't cope with it.

jsmthrowaway 11y ago

A former Linode employee, actually (why did you edit out the ad hominem accusing me of working for Amazon?), but my employment is irrelevant to pointing out that over subscription means you are not actually getting what you pay for. If everybody used it you wouldn't have it any more. It's not yours. You are deciding entirely on perceived instead of actual value. And yes, AWS's CPU over subscription on these instances is important if your workload is CPU intensive. They're very quickly outgrown due to that but useful in a pinch.

icebraining 11y ago
over subscription means you are not actually getting what you pay for. If everybody used it you wouldn't have it any more. It's not yours. You are deciding entirely on perceived instead of actual value. I don't agree; as long as you can always use it when you needed, you are getting what you paid for - that's actual. What you're talking about is the value in an hypothetical situation. Now, if you are actually impacted by the oversubscription, then the actual value is below what was promised, but that doesn't seem to be the case for jamiesonbecker's use of DO.
derefr 11y ago
Like the parent said, it's just like insurance. You can get what you pay for, because almost everybody else is paying for something they don't use, just in case they need it—and there's no situation where everybody's "just in case" will happen at the same time. Aggregated traffic is predictable in a way that individual flows aren't; you can have enough surety to stake your business on giving some of your customers a throughput/latency SLA, without reserving any circuits for them—because you know that even the peak of your traffic's froth is predictably below your uplink's capacity, and that there's no way for this fact to change on a timescale small-enough that your staff can't cope with it.