231–240 of 296 posts
Earlier quoted context omitted.
If I recall correctly from older posts (I played Fortnite for a while), they're using AWS.
That's still not answering many questions. I hope they publish a full analysis at some point.
Earlier quoted context omitted.
Would you be able to post some ballpark figures, please?
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…
That doesn't strike you as a little odd?
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.
I've been too focused on the tech that I forgot about the legal part of this. Is this why they've all given wishy-washy responses that take no responsibility and seemingly don't even admit there's a problem? Sounds like they expect massive legal recourse and have no real choice but to listen to their lawyers who are telling them to admit no guilt.
Earlier quoted context omitted.
If you know that your product is flawed, do you keep selling it or will you pull it from the shelves? To this date I can still buy broken Intel CPUs.... They knew about the flaw in June. Yet they still kept selling Coffee Lake CPUs. If my 8700k wouldn't still be significantly faster than Amd Ryzen (or I wouldn't have to also return the MB), I would have switched to an Amd in a heart beat.
To be fair to Intel, mitigating this type of issue isn't at all trivial. If it were, it could have been fixed in a microcode update. You can't rush a chip design for something as complicated as x86_64. There are long multi-year development cycles and tons of regression tests. With this they need to add even more tests before they can start on attacking the issues with the design.
It's understandable that they may not have been able to mitigate it in the 8th gen CPUs in just a few months, but they also put those CPUs out on the market, advertised them, and sold them, all the while they knew of their design flaw, without saying anything about it to the unsuspecting customer.
Earlier quoted context omitted.
This is a horrible approach to security. If you only secure against attacks you expect, you're gonna have a bad time.
Some things are just not applicable. There's no point adding another padlock to the outside wall of Fort Knox. If untrusted users don't send instructions to the same physical CPU that you're using, Meltdown/Spectre are not relevant. I also think that we need more information before we really see the long-term performance impact here. First, the patches will likely be optimized over time. Second, I am not sure that PT…
Strongly disagree. No single defense measure is infallible and defense in depth has proven one of the most important topics in computer security.
Earlier quoted context omitted.
Vulnerable to Spectre, yes, like nearly all speculative execution processors. The PS4, XBone and Switch are very likely vulnerable to Spectre all the same but that will probably mostly affect their web browsers. None of these is vulnerable to Meltdown. That is an Intel/Apple/ARM Cortex A75 only thing.
It affects WAY more ARM processors than A75. All the fast ARM cores are vulnerable to one of the two meltdown flaws and half are vulnerable to a subset of the third flaw (with A75 being completely vulnerable). https://developer.arm.com/support/security-update
Do you mean Spectre? Meltdown is the Variant 3 in that link.
> It affects WAY more ARM processors than A75. All the fast ARM cores ...
The ARM cores listed on that page are not all the ARM cores in the market (or running in the real-world). There are many more ARM cores than listen in that table, and the page says any ARM core not listed in that table is not vulnerable to any variant of Meltdown or Spectre.
Earlier quoted context omitted.
Latency is more important than reliability for online gaming because the world state instantly gets stale. Instead of retransmit you want latest snapshot. I'd be curious to find out in what online games that is not the case.
Latency isn’t an issue today what so ever, it’s not like UDP also has a magical lower latency it had in the past because of smaller packets and slower computers but today? Online games work today with fixed ticks and polling usually at half of full frame rate which means that the server updates and polls the client 30 or 60 times a second or any other even multiplier of the expected synced frame rate.
Source: I used to write networking stacks for realtime games.
If it's helpful, Our Node.js, MongoDB, Python servers all with significant network traffic didn't have any measurable impact after KPTI patches on Amazon Linux on T2.medium(burst), M4.large, T2.large(burst) respectively. Our impact is lesser than the figures suggested by redhat's advisory - https://access.redhat.com/articles/3307751
Earlier quoted context omitted.
There's potential for a little rearchitecting to help, at least in the case of UDP: NAME sendmmsg - send multiple messages on a socket SYNOPSIS #define _GNU_SOURCE /* See feature_test_macros(7) */ #include int sendmmsg(int sockfd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags);
That only works if messages are independent of answers received and are all known at the same point in time. In most games this typically would not be the case, you'd use a message to cram as much state change into it as is known to keep the game moving fluidly. Packing more than one such message together would serve no purpose.
Earlier quoted context omitted.
Is that remotely feasible? You're basically suggesting that Intel needs to refund or replace every PC and server CPU they've sold in the last five years. The fdiv recall cost Intel almost half a billion dollars, and that was for a small subset of processors that most people didn't replace. Intel has a lot of assets, but replacing five years worth of CPUs might actually bankrupt them.
I deleted that because I thought it was too flamey after reading it again, but yeah refunding everyone is unrealistic. Maybe just average out the performance impact across large cloud providers and offer that as a percentage? It probably wouldn't be hard for a company like Google to crunch metrics before/after the update and give a number for how much their performance has been affected
I think the important thing here is precedent, rather than making customers whole. The question then is what, if anything, could Intel have done to anticipate and prevent this, and how do we incentivize them to take those measures in the future?
It's also possible that there's nothing to change here. There's always going to be some risk, and trying to force that risk closer and closer to zero will at some point not be worth the tradeoff. As bad as this is, if the caution necessary to prevent it would have resulted in processors being half as fast as they are today anyway, there wouldn't be any point.