Announcement

Collapse
No announcement yet.

AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    heh, I think you guys need to resize how small of a subset you are. Linux/BSD users that are compiling their systems from scratch that also own ryzens.. what 0.001% of the computer industry or less?

    Comment


    • #22
      Originally posted by k1e0x View Post
      heh, I think you guys need to resize how small of a subset you are. Linux/BSD users that are compiling their systems from scratch that also own ryzens.. what 0.001% of the computer industry?
      Compiling is just one of the easiest ways people found.

      CPU compatibility is a matter of standards, not opinion. I expect any x86/amd64/em64t chip I buy to be compatible with the architecture it claims to be.

      There were a lot of suggestions going on - including from AMD - that Ryzen might simply not be 100% compatible, and the fix might have been to compile software for the CPU. Completely ignoring the fact that all legacy code needs to run on these CPUs. And no I am not confusing those statements with simply finding cflags to optimize performance for Ryzen. I am not speaking of any claims where they said this was actually the case, but the suggestion that they might be okay with that explanation was extremely insulting as a potential customer. And don't get me wrong - I'd own a Ryzen CPU right now if this issue hadn't happened.

      People are also having this problem with Windows subsystem for Linux (which doesn't use the Linux kernel itself).
      Last edited by Holograph; 07 August 2017, 04:10 PM. Reason: removed reference to bridgman

      Comment


      • #23
        not the workloads most Linux users will be firing off
        I think you are very wrong here. I was considering replacing my i7-6700K with a Ryzen CPU(and the motherboard) exactly for these use-cases(I do not play games but I do want faster compilations for development).

        Also, at work Ryzen has been considered exactly for development purposes(we don't care for high frequency, we care only about high core/thread count because it speeds our compilation).

        Comment


        • #24
          Originally posted by birdie View Post
          I really doubt this problem is specific to Linux (and *BSDs) but let's give AMD some breathing room here. Hopefully a BIOS update can solve it because we don't need another fiasco akin to the translation lookaside buffer issue which plagued the K10 CPUs.
          That bug literally affected 0 people. This bug is magnitudes worse.

          Comment


          • #25
            I just discovered that I can easily reproduce a hard crash by running:

            PTS_CONCURRENT_TEST_RUNS=4 TOTAL_LOOP_TIME=60 ./phoronix-test-suite stress-run build-linux-kernel build-apache build-imagemagick

            As Michael suggested in his prior articles.

            I'm running a Ryzen 1700 that's overclocked from 3.0 to 3.7 GHz on stock voltage. I didn't have any problems running prime95 (or at least the linux equivalent) overnight, so this has caught me a bit off guard. Currently my system just hard locks in about 1 minute of running the aforementioned command. Disabling SMT so far has appeared to solve the problem, but it might just occur much later. I must admit I'm a bit disappointed by this issue and I hope that AMD can release some sort of fix that does not require an RMA.

            Comment


            • #26
              Originally posted by Holograph View Post

              Compiling is just one of the easiest ways people found.

              CPU compatibility is a matter of standards, not opinion. I expect any x86/amd64/em64t chip I buy to be compatible with the architecture it claims to be.

              There were a lot of suggestions going on - including from AMD and I believe specifically including from bridgman - that Ryzen might simply not be 100% compatible, and the fix might have been to compile software for the CPU. Completely ignoring the fact that all legacy code needs to run on these CPUs. And no I am not confusing those statements with simply finding cflags to optimize performance for Ryzen. I am not speaking of any claims where they said this was actually the case, but the suggestion that they might be okay with that explanation was extremely insulting as a potential customer. And don't get me wrong - I'd own a Ryzen CPU right now if this issue hadn't happened.

              People are also having this problem with Windows subsystem for Linux (which doesn't use the Linux kernel itself).
              Yeah right. hehe

              No, the problem is only occurring on builds due to the way the code is executed. Yea people have noticed this on Gentoo for awhile but they were also doing really dumb shit so it's hard to take them seriously. The FreeBSD guys seem like they really got a handle on this and were able to track it down. There is already a patch (partial?) for FreeBSD.

              Comment


              • #27
                Originally posted by RyzenNewbie View Post
                word - I asked the FreeBSD devs 20 minutes ago whether this CPU's internal signal issue can be fixed by the operating system (me thinks: perhaps by artificial throttling, I don't know) - but I fear that in the end a real fix means a new CPU...
                The elephant in the room quotes this part from Michael's article: AMD's testing of this issue under Windows hasn't uncovered problematic behavior.

                I wonder if this would play out differently if Apple would had made a deal with AMD to use Ryzen in their next gen macs.

                Comment


                • #28
                  Originally posted by Sethox View Post
                  (...) but thank god for good communication from the company
                  I'm missing the "sarcastic" tags around that sentence of you, but I don't see any. Does that mean that...?

                  Comment


                  • #29
                    Originally posted by Holograph View Post
                    It seriously pisses me off that it took Phoronix articles for AMD to realize they needed to look into this. I don't care if they claim they've done it. Too little, too late. What happens next time there is a problem? AMD will ignore their customers unless they feel pressured enough to fix the problems. And if they are pressured into it, they will make a press release marginalizing the problems their customers had. And they will delay talking about anything as long as they can because they don't want to look bad, without realizing that the only way they could look worse would be to say they wouldn't look into the problem at all.
                    uhm - you really think intel would act differently?

                    Comment


                    • #30
                      Originally posted by Holograph View Post
                      What that means is "we still don't respect you and think you should buy Intel instead"

                      Coffee Lake here I come

                      "performance marginality" is nowhere near as bad as AMD thinking they could ignore all of these users until Phoronix stepped in. Thanks Michael, you saved a lot of us a terrible purchase.

                      It seriously pisses me off that it took Phoronix articles for AMD to realize they needed to look into this. I don't care if they claim they've done it. Too little, too late. What happens next time there is a problem? AMD will ignore their customers unless they feel pressured enough to fix the problems. And if they are pressured into it, they will make a press release marginalizing the problems their customers had. And they will delay talking about anything as long as they can because they don't want to look bad, without realizing that the only way they could look worse would be to say they wouldn't look into the problem at all.

                      I'm sure at least one person will call this a troll, but I can't support this kind of behavior from a company with my money. Quality of support is extremely important.
                      It's really rare that I log in and comment on the Phoronix Forums, so... congratulations, you went so far off the deep end that I logged in. If you haven't seen this video, then you really need to see it. (https://www.youtube.com/watch?v=osSMJRyxG0k)

                      AMD has been tracking this issue since day one, and they've been testing on it since day one, they've just been very quiet and secretive, which is exactly how Intel handled their huuuge bug with hyperthreading recently. (https://arstechnica.com/information-...ading-enabled/) It actually took Intel over a year to release a fix for their issue, and they never acknowledged it during that entire time. This affected production software that happened to hyperthread too intensely, not just a developer workflow. Restarting a compiler is small peanuts compared to software crashing in production and losing client requests. If you think Intel is going to provide better support, you're wrong. AMD should have been open from the beginning, I agree! But, the fact that they're being open now is instantly better than how Intel has ever handled any situation similar to this, and that's if we just conveniently ignore how bad Intel is at sportsmanship (which the video talks about).

                      So yes, I will call you a troll if you keep making these ridiculous statements. It's possible that up until now you did not realize how much more Intel has failed at this than AMD has, and I don't know who you would suggest buying from if you disavow both Intel and AMD. Are you going to buy VIA processors? Because that would be a joke of a computer.
                       
                      Last edited by coder543; 07 August 2017, 03:39 PM.

                      Comment

                      Working...
                      X