Hacker News Reader

Comment by iknownothow | Hacker News Reader

Aren't 't' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

> It does appear that the Arm-based instances can’t consistently maintain the same performance at high request rates.

I'm unwilling to trust that statement at face value for now given it's been tested against a 't' instance.

EDIT: Removed note about network burst credits in compute and memory optimized instances. I'm not sure if these instances have that.

View on HN

The T3 instances are all burstable, but they come with the "unlimited" feature toggled on by default. The T2 instances had this feature toggled off by default. So with this instance type you never really run out of credits, but you could quickly end up paying more than with other general purpose instance types, like M series, if you burn through a lot of credits.

Thanks for pointing that out, I never noticed that setting. I just tried to launch an EC2 instance looking for this setting and here's what I found.

> A credit specification is only available for T2, T3, and T3a instances. Selecting Unlimited for the credit specification allows applications to burst beyond the baseline for as long as needed at any time.

So that would mean Unlimited is not a setting available for T4g (ARM instance) and therefore may explain inconsistent behavior in the ARM instance.

It's the same for t4g.

    > T4g instances start in unlimited mode by default, giving users the ability to sustain high CPU performance over any desired time frame while keeping cost as low as possible. For most general purpose workloads, T4g instances in unlimited mode provide ample performance without any additional charges. If the average CPU utilization of a T4g instance is lower than the baseline over a 24-hour period, the hourly instance price automatically covers all interim spikes in usage. In the cases when a T4g instance needs to run at higher CPU utilization for a prolonged period, it can do so for a small additional charge of $0.04 per vCPU-hour. In standard mode, a T4g instance can burst until it uses up all of its earned credits. For more details on T4g credits, please see the EC2 documentation page.

https://aws.amazon.com/ec2/instance-types/t4/

That note did not show up for me when launching the EC2 instance. Probably because I was switching between ARM and AMD quite a bit which caused the info pop ups to stop refreshing and not display info for T4g and were stuck on T2 and T3.

I don't recall ever seeing pop-ups for that. I've always handled that via the "advanced details" section when launching instances manually through the web console.

I've just launched a test t3 instance and it didn't pop up anything.

My bad, not pop ups, instead there's an info symbol next to each option under "advanced details". I was being lazy with the terminology, I don't know what such info buttons are called.

How is that implemented? If a particular machine is 2x oversubscribed and everyone selects “unlimited,” I doubt AWS has special hardware that can run twice as fast by sticking a bit of money in the machine. I assume some customer workloads get migrated, which has its own performance cost.

Yes, it's done by instance migration behind the scenes.

Citation Needed

I don't think they document how how they're doing things in the background. Based on personal experience I've been notified that EBS-backed instances have been rebooted due to hardware failure. For instances with ephemeral storage you're given some time to migrate for scheduled maintenance, for hardware failures you're tough out of luck. I've never been notified about scheduled maintenance on an EBS-backed instance, which leads me to think that they just migrate it without telling you.

They're using KVM under the hood, which supports things like live migration, interrupts to facilitate memory transfer, and so on. At home I'm doing live migration with less than 300ms of interrupts with high memory pressure. It would make sense for them to move things around, just for things like maintenance and distributing load.

Reply on news.ycombinator.com