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
    Originally posted by Michael View Post

    Yes they have now said I will be receiving Threadripper and Epyc samples (contrary to previous communications saying not) and also looks like some more Ryzen models too.
    excellent :-) so your hard work will finally pay out for you because more hardware to test and benchmarks means more clicks and more premium users.

    maybe you get a Raptor Engineering Talos II power9 https://www.raptorcs.com/TALOSII/pre...e.php?target=1 workstation to.
    Phantom circuit Sequence Reducer Dyslexia

    Comment


    • #22
      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


      • #23
        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; 08-07-2017, 04:10 PM. Reason: removed reference to bridgman

        Comment


        • #24
          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


          • #25
            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


            • #26
              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


              • #27
                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


                • #28
                  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


                  • #29
                    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


                    • #30
                      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

                      Working...
                      X