I don't know, but wouldn't be surprised if connection tracked packets are more limited than packets that aren't tracked.
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-ne...
11–20 of 44 posts
I don't know, but wouldn't be surprised if connection tracked packets are more limited than packets that aren't tracked.
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-ne...
Amazon also limits DNS queries - probably in a well meaning attempt to prevent DNS amplification attacks from originating within AWS. And I mean DNS queries across their network whether or not they hit Amazon's DNS servers. This is _any_ port 53 UDP traffic. https://www.sparkpost.com/blog/undocumented-limit-dns-aws/
Connect a single server to a network and it's oversubscribed. That's a bit hyperbolic, but even some beefy networks can be seriously burdened by just a single server spamming UDP packets without some sort of QoS.. Especially if they are bypassing user space and using the kernel to just replicate a bunch of packets onto the wire :)
I'm probably a bit biased from having spent time setting up linux TC on xen hypervisors for this very reason; and I think we even settled at 50k pps for the per vm limit too..
The (undocumented) PPS limitation on EC2 instance types before they added SR-IOV NICs is around 150K PPS. If you had your own full machine — usually the top size of a given instance class, but no guarantee — this would be pretty consistent. But it was a shared resource. This made running memcache clusters really painful on EC2, given that they’d easily get limited by packet throughput before CPU or bandwidth. With mo…
???? Where are you getting these numbers? For what instance types? For what protocols? This is just wrong.
Do you have a more accurate dataset? What are your observations?
I'm assuming this affects loads of HN readers and I too am interested in what the facts are.
Side note: you may be getting downvoted because a source, or other details are lacking. I too get downvoted for posts that lack these details.
I guess technically it is, but I hesitate to call the need for PPS limitations in the DC as "over subscribing". Connect a single server to a network and it's oversubscribed. That's a bit hyperbolic, but even some beefy networks can be seriously burdened by just a single server spamming UDP packets without some sort of QoS.. Especially if they are bypassing user space and using the kernel to just replicate a bunch of…
Note that if your traffic hits the ec2 connection tracking security groups, you will also hit per instance limits on the number of tracked connections [1]. As far as I know, they don't come out and say they have a limit on the number of tracked connections, but they do, and it scales by instance type -- better to adjust your rules so the traffic is allowed in a stateless manner. I don't know, but wouldn't be surprise…
Does anyone know if this applies to the dpdk ENA driver?
Here is a demonstration of a software stack that can scale toward hardware limits without relying on a particular vendor https://www.slideshare.net/SeanChittenden/freebsd-vpc-introd.... This approaches 100G line rate for large packets which is what it was optimized for. I don't know PPS at low packet size but do know what would be required to optimize that use case and it could be done pretty quickly.