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 -
Networking tends to have much higher peak-to-averages, and there's a whole layer of dynamic feedback loops from awesome folks who are building and tuning meshes and sidecars specifically against AWS's network performance.
1 reply 0 retweets 1 like
It's like we measure everything and analyze it, then deploy our latest fairness improvements, and then a bunch of folks change the behavior we measured in response, and on. It's not an arms race, because we're on the same side, but it's something!
-
-
My feedback is that stronger contracts from infra can simplify building distributed systems. I think this could be helpful even if it was a very loose floor (like the fallback that happens if you push “unlimited” LTE plans too far).
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.