Why do you needs so many cores for? Apache threads? Any old school wizard here?
These almost always run many smaller virtual machines on top of a hypervisor. The target market is large enterprise or hyperscalers like the public clouds, Meta, etc...
Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
151–160 of 303 posts
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#152Earlier quoted context omitted.
$120K isn't going to cover the fully loaded costs of an SRE who can set up and run that. Hiring 1 person to run the infrastructure means that 1 person is on-call 24/7 forever. If there's an issue with the server while they're sick or on vacation, you just stop and wait. If they take a new job, you need to find someone to take over or very quickly hire a replacement. There's a second bus factor: What happens when that…
> There's a second bus factor: What happens when that 8xH100 starts to get flakey? These come in a non-flakey variant?
It's called a warranty.
And the other argument: every company I've ever know to do AWS has an AWS sysadmin (sorry "devops"), same for Azure. Even for small deployments. And departments want their own person/team.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#153Earlier quoted context omitted.
> If we can't bill a customer for it, and it's not scaling regularly, then it shouldn't be in the public cloud. That's my take, anyway. It sucks the wind from the sails of folks gung-ho on the "fringe benefits" of public cloud spend (box seats, junkets, conference tickets, etc...), but the finance teams tend to love such clear numbers. I agree, but . For one, it's not just the machines themselves. You also need to bu…
> Then, you need a second site, no matter what. At least for backups, ideally as a full failover. Either your second site is some sort of cloud, which can be a PITA to set up without introducing security risks, or a second physical site, which means double the expenses. You can technically have backblaze's unlimited backup option which costs around 7$ for a given machine although its more intended for windows, there…
>
You can technically have backblaze's unlimited backup option which costs around 7$ for a given machine although its more intended for windows, there have been people who make it work and Daily backups and it should work with gdpr (https://www.backblaze.com/company/policy/gdpr) with something like hetzner perhaps if you are worried about gdpr too much and OVH storage boxes (36 TB iirc for ~55$ is a good backup box) and you should try to follow 3-2-1 strategy.
Sure, but it doesn't solve the issue of "the datacenter is on fire" - neither if you're fully on prem or if you use colocation. You still need to acquire a new set of hardware, rack it, reconfigure the networking hardware and then restore from backups. That's an awful lot of work, and yes, I've been there.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#154I’ve not kept up with Intel in a while, but one thing that stood out to me is these are all E cores— meaning no hyperthreading. Is something like this competitive, or preferred, in certain applications? Also does anyone know if there have been any benchmarks against AMDs 192 core Epyc CPU?
In HPC, like physics simulation, they are preferred. There's almost no benefit of HT. What's also preferred is high cluck frequencies. These high core count CPUs nerd their clixk frequencies though.
I'm so sorry for being juvenile but "high cluck frequencies" may be my favorite typo of all time.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#155These sorts of core-density increases are how I win cloud debates in an org. * Identify the workloads that haven't scaled in a year. Your ERPs, your HRIS, your dev/stage/test environments, DBs, Microsoft estate, core infrastructure, etc. (EDIT, from zbentley: also identify any cross-system processing where data will transfer from the cloud back to your private estate to be excluded, so you don't get murdered with egr…
The main cost with on-prem is not the price of the gear but the price of acquiring talent to manage the gear. Most companies simply don't have the skillset internally to properly manage these servers, or even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. For those that do, your scaling example works against you. If today you can merge three ser…
You need the exact same people to run the infra in the cloud. If they don't have IT at all, they aren't spinning up cloud VMs. You're mixing together SaaS and actual cloud infra.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#156Earlier quoted context omitted.
The main cost with on-prem is not the price of the gear but the price of acquiring talent to manage the gear. Most companies simply don't have the skillset internally to properly manage these servers, or even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. For those that do, your scaling example works against you. If today you can merge three ser…
> even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. This is really the core problem. Every time I’ve done the math on a sizable cloud vs on-prem deployment, there is so much money left on the table that the orgs can afford to pay FAANG-level salaries for several good SREs but never have we been able to find people to fill the roles or even kno…
I work in SRE and the way you describe it would give me pause.
The first is that SRE team size primarily scales with the number of applications and level of support. It does scale with hardware but sublinearly, where number of applications usually scales super linearly. It takes a ton less effort to manage 100 instances of a single app than 1 instance of 100 separate apps (presuming SRE has any support responsibilities for the app). Talking purely in terms of hardware would make me concerned that I’m looking at an impossible task.
The second (which you probably know, but interacts with my next point) is that you never have single person SRE teams because of oncall. Three is basically the minimum, four if you want to avoid oncall burnout.
The last is that I don’t know many SREs (maybe none at all) that are well-versed enough in all the hardware disciplines to manage a footprint the size we’re talking. If each SRE is 4 racks and a minimum team size is 4, that’s 16 racks. You’d need each SRE to be comfortable enough with networking, storage, operating system, compute scheduling (k8s, VMWare, etc) to manage each of those aspects for a 16 rack system. In reality, it’s probably 3 teams, each of them needs 4 members for oncall, so a floor of like 48 racks. Depending on how many applications you run on 48 racks, it might be more SREs that split into more specialized roles (a team for databases, a team for load balancers, etc).
Numbers obviously vary by level of application support. If support ends at the compute layer with not a ton of app-specific config/features, that’s fewer folks. If you want SRE to be able to trace why a particular endpoint is slow right now, that’s more folks.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#157I think everyone's focusing on the core count, but the packaging story is way more interesting here. This thing is 12 separate chiplets on 18A stacked on base dies made on Intel 3, connected to I/O tiles on Intel 7. Three different process nodes in one package, shipping at volume. That's nuts.
And it's clearly an IFS play too. Intel Foundry needs a proof point — you can publish PDKs all day, but nothing sells foundry credibility like eating your own cooking in a 288-core server part at 450W. If Foveros Direct works here, it's the best ad Intel could run for potential foundry customers.
The chiplet sizing is smart for another reason nobody's mentioned: yield. 18A is brand new, yields are probably rough. But 24 cores per die is small enough that even bad yields give you enough good chiplets. Basically AMD's Zen playbook but with a 3D twist.
Also — 64 CXL 2.0 lanes! Several comments here are complaining about DDR5 prices, which is fair. But CXL memory pooling across a rack could change that math completely. I wonder if Intel is betting the real value isn't the cores but being the best CXL hub in the datacenter.
The ARM competition is still the elephant in the room though. "Many efficient cores" is what ARM has always done natively, and 17% IPC uplift on Darkmont doesn't close that gap by itself.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#158Earlier quoted context omitted.
The main cost with on-prem is not the price of the gear but the price of acquiring talent to manage the gear. Most companies simply don't have the skillset internally to properly manage these servers, or even the internal talent to know whether they are hiring a good infrastructure engineer or not during the interview process. For those that do, your scaling example works against you. If today you can merge three ser…
You need the exact same people to run the infra in the cloud. If they don't have IT at all, they aren't spinning up cloud VMs. You're mixing together SaaS and actual cloud infra.
I'm one of those people, and I don't agree.
Before I drop 5 figures on a single server, I'd like to have some confidence in the performance numbers I'm likely to see. I'd expect folk who are experienced with on-prem have a good intuition about this - after a decade of cloud-only work, I don't.
Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem.
I've estimated our IT workload would roughly double if we were to add physically racking machines, replacing failed disks, monitoring backups/SMART errors etc. That's... not cheap in staff time.
Moving things on-prem starts making financial sense around the point your cloud bills hit the cost of one engineers salary.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#159Earlier quoted context omitted.
"Is something like this competitive, or preferred, in certain applications?" They cite a very specific use case in the linked story: Virtualized RAN. This is using COTS hardware and software for the control plane for a 5G+ cell network operation. A large number of fast, low power cores would indeed suit such a application, where large numbers of network nodes are coordinated in near real time. It's entirely possible…
is RAM a concern in these cluster applications, cause if prices stay up, how do you get them off the shelf if you also need TB of memory.
> how do you get them off the shelf if you also need TB of memory
You make products for well capitalized wireless operators that can afford the prevailing cost of the hardware they need. For these operations, the increase in RAM prices is not a major factor in their plans: it's a marginal cost increase on some of the COTS components necessary for their wireless system. The specialized hardware they acquire in bulk is at least an order of magnitude more expensive than server RAM.
Intel will sell every one of these CPUs and the CPUs will end up in dual CPU SMP systems fully populated with 1-2 TB of DDR5-8000 (2-4GB/core, at least) as fast as they can make them.
Re: Intel's make-or-break 18A process node debuts for data center with 288-core Xeon
#160A bad moment to have a make-or-break moment for your CPU business - a lot of customers will probably hold off purchases right now because of the RAM prices, no matter how good your CPU might be.
In my experience, RAM costs will have very little impact on businesses buying servers. When we buy is pretty much set by contract and warranty cycles.