The EC2 network fairness system kicks in on instances that share underlying bandwidth, but does not operate on time boundaries, or forever. It is a credit system.
-
-
A persistent sender will see behavior like you're seeing because it keeps sending; the credits never get a chance to build up. This kind of behavior basically only applies to a persistent sender.
1 reply 0 retweets 1 like -
For workloads that are not sitting on send, there isn't a flat "baseline". The behavior will depend on how many credits have built up and are remaining. Ideally, as for the vast majority of workloads, nothing will happen!
1 reply 0 retweets 0 likes -
To mention again, we're always refining these, improving the parameters slightly to accommodate more marginal workloads without sacrificing good fairness.
1 reply 0 retweets 0 likes -
Together these make it hard to document; the behavior is sophisticated, and when we make the specifics public, it becomes very hard to improve for everyone because some folks code or alarm against the specifics.
1 reply 0 retweets 5 likes -
I think this is a good balance, because for the vast majority of customers, on the vast majority of instances, when they try to use the network, they get the burst speed. As you saw, there are generous credits in the system!
2 replies 0 retweets 1 like -
Having a burst system doesn’t preclude you from being transparent on guaranteed minimum bandwidth & token accumulation algorithms, right? Eg, the gp2 IOPS and throughput scheme? I say this from the perspective of someone assuming shared positive intent.
1 reply 0 retweets 3 likes -
Do you think running S3 data analysis on a C5N is a marginal workload? (It's my use case, and how I discovered this.) Do you think the phase I've highlighted indicates that I'll be throttled to 2 Gbps on a C5N.XL after 40 minutes of crunching data from S3?pic.twitter.com/5spQSGh2j7
3 replies 0 retweets 3 likes -
Gah I skipped over “becomes very hard to improve for everyone because some folks code or alarm against the specifics.” Any insight on the difference in approach between networking and gp2?
2 replies 0 retweets 0 likes -
The code/alarm argument against specifying the refill rate is very weak when the burst rate is not only precisely specified, but prominently advertised as a feature for network-intensive workloads. The word Gbps appears dozens of times in the C5 product page.
1 reply 0 retweets 0 likes
The burst rate is line rate, it can't be increased in a laws of physics sense, and I don't think we're going to decrease it ever
Very safe to document and make some kind of contract out of that compared to numbers that can change IMO.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.