Live data from Hacker News

CPU Usage Differences After Applying Meltdown Patch at Epic Games

epicgames.com

241–250 of 296 posts

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#241

Earlier quoted context omitted.

Yep, I was actually debating whether I'd mention sendmmsg/recvmmsg in my original post but I left it out. Definitely an option for UDP, but you're out of luck if your game server uses TCP (surprisingly many do) because you have to recv from each socket separately.

The majority of online games use TCP these days with good prediction it’s more reliable than UDP.

It really depends on the type of game.

If it's a latency sensitive (like a twitch FPS), UDP is the way to go. Having up to date data is more important than having all the data.

If it's a synchronized game (like a turn based game or an RTS where all clients run at the same logic framerate), or not latency sensitive (an MMO like WOW), TCP is fine and probably easier.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#242
post #222

Earlier quoted context omitted.

> Lawsuits are a fine way to stifle innovation. I'm not sure about this. At any large company like Intel, the cost of potential - even predicted - lawsuits are already factored into their budgets.

I know almost nothing about law but I would assume a large company would be insured against contingencies like this. I remember reading something about how rich people can get 'everything else's insurance that's basically applicable to anything bad that could happen to them. Maybe its the same with companies?

You can insure almost anything, assuming you’re willing to pay the premium, and that the insurers are satisfied with their due diligence. BUT... that insurance company will look for any technicality, any little way that you failed the extensive duty to protect your insured assets, and try not to pay out.

So really, in this case insurance is just another word for “more lawyers to drag through the courts for people years, with uncertain results.”

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#243

Earlier quoted context omitted.

Actually, there is not any measurable difference. Our architecture is completely state-less and when compared with equivalent load there's no difference at all. I guess, default network throughput bottle-neck itself is higher than the random memory cache bottle-neck in my case. There was no impact on the latency either. Fearing automatic update by AWS resulting in performance issue, we rushed to update all our serves…

> Actually, there is not any measurable difference. That doesn't strike you as a little odd?

It's the same result as Google apparently observed across their fleet. It doesn't seem like it should be that odd.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#244

Huge real world performance impact, they didn't say how much but it looks like close to 100%. I smell a class action lawsuit coming.

With the Pentium floating point bug (1994), Intel offered to replace the defective CPUs. https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug

IIRC almost nobody took them up on the offer. But today there is far more cloud computing, so datacenters might.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#245
post #135

Earlier quoted context omitted.

Replying here, since the other post I replied to disappeared: Despite the avalanche of downvotes burying my posts, not even one person can actually answer the question I asked: The poster could have simply stopped typing after "Thank you for the explanation". He chose to unnecessarily add something more. So, for everyone who disagrees with me: if what he said wasn't itself "snarky", what was it?

> if what he said wasn't itself "snarky", what was it? A complaint that Hacker News is a less agreeable place than it used to be. Whether that's true or not, don't you think you might find a more effective way of counter-arguing than by being as disagreeable as you can possibly manage without outright swearing in your responses? I get that you're sure that you're right. That's great! That's a source of strong motivat…

> A complaint that Hacker News is a less agreeable place than it used to be.

Which makes the place no more agreeable.

> Whether that's true or not...

This is amazing.

I ask a question, and the only "answer" is simply an excuse to segue into a weird, patronizing, passive-aggressive wall of text that has zero to do with what I actually posted, and is nothing but a personal attack dressed up as a lecture on politeness. Amazing.

I guess you don't reach 10k karma on a throwaway by not having a gallery to play to.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#246

Earlier quoted context omitted.

Whilst I sympathise with your frustration, at least with Intel, I can't help feeling like you might be storing up bigger problems for yourself with this course of action.

I get what you are saying but right now there are no known exploits and with so much patching happening will there ever? These things are always over blown in the media and the reality is very little damage happens to the average user. It’s servers perhaps that are most at risk. Also I don’t do much on my Windows, mostly gaming, I run an iMac and boot into it only for certain tasks, so it’s extremely unlikely I will…

Yea sounds like you need all the CPU you can get. Good decision.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#247
post #106

Maybe off-topic: Is formal verification viable anywhere in CPU logic design? Also, could any existing "CPU static analyzers" have caught the issue that caused Meltdown? Edit: It looks like the answer to the first is a definite yes.

In my mind Meltdown is a failure of implementation due to the choice to violate the logical design. If the logic of your design says "do not access ringX memory if you are not executing in ringX" then don't do it. Intel instead decided that they would access it but thought they could hide the results of that access from the process by never providing the read results. The problem is that actions always leave evidence in the physical world, simply assuming that no one could detect those actions (which was true at the time) is not the same as not committing the action. The benefit for Intel in violating the logical design rule was speed (and probably a reduction in gates) and the optimistic view that there were no consequences to the violation. Unfortunately hubris invited Nemesis to the party, as usual.

Spectre is a different problem in that the very design of speculative execution contains the seeds of its flaws so there really is no way to implement it in such a way as to avoid the intra-process snooping although the inter-process exploit may be avoidable via implementation.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#248

Earlier quoted context omitted.

Thanks - this is what's worrying me: the result of patching seems to be all over the map, and it's somewhat hard to predict. My biggest worry is SQL Server, so our plan is to fix a performance issue we isolated recently before we patch - I'd like that system running optimally before we take the hit.

Judging from our MongoDB instance, I'm optimistic that your SQL server wouldn't face much impact either. Even Redhat tests put the risk at modest. But for something like Redis, the case could be different. If you are on a cloud provider, do check that automatic update is not scheduled; if so it's better to update manually to follow up with mitigation if necessary.

This is almost entirely subjective and workload dependent.

We know that the biggest performance factor in both of these patches (spectre, meltdown) is the kernel boundary.

So saying something along the lines of "Redis is more affected than Mongo" is.. odd.

MongoDB (I HOPE) will save files more frequently than redis, since redis is primarily in in-memory DB with some lazy IO access (depending on configuration).

So if you have a lot of small network calls to redis (which, is a kernel boundary event.) then it will be more impacted than a mongodb which takes only a few very large requests.

My gut is that the opposite would be true for the same workloads on both, MongoDB needs its files to return data, redis doesn't.

Even the vfs-cache is in kernel "space", so if your entire data sat in vfs cache it wouldn't help.

But that's my gut, and your exact usage may not mirror the 1:1 of this scenario.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#249

Earlier quoted context omitted.

Fortnite doesn’t use UDP at all (80, 443 and 5222 all TCP), UE4 uses TCP for its network stack by default.

Are you sure? I would be extremely surprised if it wouldn't use UDP. For things like getting stats, probably from a HTTP endpoint, sure, but for gameplay? The lag would be very bad, no? Lose a packet and everything is slowed down I see this, which indicates it uses UDP: https://imgur.com/al6KTwT and according to wireshark it's used heavily when in a game, so I assume that's the gameplay protocol. Also when I left my…

It's not entirely uncommon to have TCP on the backend even for AAA games.

I worked on a huge open world third-person shooter always-online AAA game and it uses TCP for everything.

Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games

#250
post #130

Looks like it may be time for Epic Games to consider switching to AMD Ryzen/EPYC.

I have been looking at AMD/Epyc CPUs recently.

(Because making NUMA aware C++ code is hard, and AMD Epyc is a single socket on a server with 4 very closely knit NUMA zones so non-NUMA code will run better on that vs Intel)

But unfortunately there's no comoddity server from HP/Dell available yet. But I hear one is on the way on the Dell side.

Post reply on HN