Re-examining the unusual frame time results in our Radeon RX 470 review

It's never fun to admit a mistake, but we made a big one while writing our recent Radeon RX 470 review. That piece was our first time out on a new test rig that included an Intel Core i7-6700K CPU and an ASRock Z170 Extreme7+ motherboard. Once we got that system up and running, it delivered some weird-looking frame time numbers with some games. For example, the spikiness of the frame-time plot below didn't match any test data we had ever gathered before for Grand Theft Auto V, and we puzzled over those strange results for some time. We decided to go ahead and publish them anyway after doing some extended troubleshooting without seeing any improvement.

Compare that to a more typical GTA V result from our Radeon RX 480 review, as demonstrated by three GeForce cards running on an X99 testbed:

The spikiness caused by what turned out to be high deferred procedure call (or DPC) latency didn't seem to affect average framerates much (save one major exception), but it did worsen our 99th-percentile frame time numbers considerably. Given how much we use those 99th-percentile numbers in formulating other parts of our conclusions, especially value plots, the error introduced this way had considerable negative effects on the accuracy of several key parts of our review. The net effect of this error led us to wrongly conclude that the Radeon RX 480 8GB and the Radeon RX 470 were closely matched in performance, when in fact they're quite different.

Upon reflection, we should have stopped the RX 470 review at that point to try and figure out exactly what was going on, but the pressure of deadlines got the better of us. When these weird frame-time plots appeared once more in the preliminary testing work for our review of the Radeon RX 460, however, we had to acknowlege that something unusual was going on. Of course, that also meant that our published RX 470 review had problems that we had to deal with. We believe that in the interest of full transparency, it's important to explain exactly what happened, be clear about how we messed up, and resolve not to make the same mistakes in the future.

The issue

While I was testing the Radeon RX 460 and tearing my hair out over the wild frame time plots our cards were generating, TR code wizard Bruno "morphine" Ferreira brought the possibility of high DPC latency to my attention. DPC latency is usually of interest to musicians running digital audio workstations, where consistently minimal input lag is critical. Bruno pointed me to the LatencyMon app, which keeps an eye on DPC performance and warns of any issues, as a way of figuring out whether DPC latency was the root cause of this problem.

LatencyMon thinks something is up with my main desktop. I'll have to look into it soon.

I didn't capture any screenshots during my frenzied troubleshooting, but LatencyMon did show that our test rig wasn't servicing DPC requests promptly. Wireless networking drivers are generally considered the first place to look when troubleshooting DPC issues, and I use an Intel Wireless-N 6205 card in our test system. Oops. Even after disabling that wireless card, however, the issue persisted. After killing every potential bit of software that might have been causing the problem without getting any improvements, I took Bruno's suggestion of updating our motherboard's firmware. "The BIOS can't possibly be the cause!" I thought to myself smugly.

Pride goeth before a fall, of course, and the DPC latency issue vanished with the new ASRock firmware installed. The frame-time plots for GTA V began to resemble the flat, tight lines we've come to expect with modern hardware. I had to quash the urge to drive over the motherboard a few times and burn the remains before coming to grips with the fact that I would have to throw out large amounts of testing data.

So what happened? You see, ASRock sent us its Z170 Extreme7+ board during a brief period in which the company was promoting its ability to overclock locked Intel CPUs with a beta BIOS. I had hoped to explore that possibility with some ASRock motherboards and cheap CPUs, but Intel swiftly put the kibosh on the concept. We got busy with other work, and the beta firmware remained on the motherboard through our first attempts to test graphics cards with it. I don't know precisely what was wrong with this beta firmware that was causing it to wreak havoc on DPC latency, but updating the firmware did fix it, so Occam's razor suggests something weird was going on.

The fallout

Having solved the underlying problem, I now had to contend with the fact that I had published a very public and widely-read review that contained what seemed like reams of contaminated data. To see just how wrong I had been in my conclusions, I retested every title we had slated for our RX 470 and RX 460 reviews on our ASRock test rig, using the same settings we had initially chosen for our reviews.

As it turns out, high DPC latency doesn't affect every game equally, or at least not in a way that shows up in our frame-time numbers. While GTA V, Hitman, and Rise of the Tomb Raider all showed significant changes in average FPS and 99th-percentile frame times after a retest on the updated hardware,  Doom, Crysis 3, and The Witcher 3 did not. That second trio of games certainly felt more responsive to input after the critical firmware update, but the data they generated wasn't meaningfully different. We're talking fractions of milliseconds of difference in before-and-after testing, and those deltas are almost certainly imperceptible in real-life gaming. Given that behavior, we're confident that the numbers we generated for Doom, Crysis 3, and The Witcher 3 are representative of the performance of the Radeon RX 460, the Radeon RX 470, and the other cards we tested in those reviews. 

The resolution

Given the large differences in performance we saw with GTA V, Hitman, and RoTR, the only acceptable way to fix our mistake was to retest all of the cards in our Radeon RX 470 review from the ground up with those games. We've done that now, and as a bonus, we did that retesting with the same data-collection methods we just premiered in our RX 460 review.

As a result, we now have Doom Vulkan and OpenGL numbers for the RX 470 and RX 480, plus DirectX 12 numbers for Rise of the Tomb Raider and Hitman. We've also extensively re-written the conclusion of our Radeon RX 470 review to account for this new data, much in the same way that we crunched our results for the Radeon RX 460 and friends. We've accounted for the differences in our results there, so I'd encourage you to go read up on what changed.

If you read our original Radeon RX 470 review, we're deeply sorry to have misinformed you. We also extend our sincerest apologies to everybody at AMD and Nvidia for presenting incorrect information and misguided conclusions about their products. In the future, we'll strive to be both correct and swift with our reviews, but we also won't hesitate to delay a piece when clear warning flags are evident. We hope this clarification reinforces your trust in The Tech Report's reporting. If you have any questions or concerns, please leave a comment below or email me directly.

Comments closed
    • richardjhonson
    • 3 years ago
    • ronch
    • 3 years ago

    Unusual frame time results on an AMD graphics card?? You don’t say! 🙂

    • iq100
    • 3 years ago

    Should your test procedure ALWAYS include testing on two systems that use different motherboards, form different manufacturers, using different BIOSs? That would have shown your results were due to a property (in this case a property of the ASRock BIOS) that did NOT belong exclusively to the card under test. Would it be too costly for TR to have hardware for two such differing test beds? If I can own two computers, why can’t TR??

    1. What other hardware was tested using beta BIOS firmware ASRock motherboard?
    2. Do you test the test bed, with a off the shelf or custom test suite, designed to see if anything is degrading or broken, before using and relying on the test bed results?
    3. It might be as valuable, now that you claim it was the beta BIOS anomaly, to drill down and see why this effected just some tests. Can this behavior be understood?

      • Freon
      • 3 years ago

      Probably has more to do with time to repeat testing. There is a lot of wiping/restoring they do between runs, and they repeat runs to take averages IIRC. It’s a lot of hours of test running procedure.

    • gigafinger
    • 3 years ago

    This makes me curious if many people’s systems are suffering from performance robbing issues like this. Would TechReport be interested in writing a gaming PC optimization article?

      • djayjp
      • 3 years ago

      My highest DPC latency is 530 microseconds, thanks to “Network Driver Interface Specification” (NDIS), an MS API under ndis.sys. :/ I don’t think there’s anything I can do about it….

      *Edit: now I’m getting Wdf01000.sys Kernel Mode Driver Framework Runtime giving me 390 microseconds ugh.

        • morphine
        • 3 years ago

        Do note that that DPC latency spikes are a normal thing. Simplifying, you get DPC-induced latency when “something” happens in the computer.

        What is an abnormal situation is they’re too large and too numerous. If your PC just overall feels sluggish (particularly to input), if you’re listening to music / videos and the sound breaks, etc, it may be worth investigation.

          • djayjp
          • 3 years ago

          Hmm interesting, thx for the reply. I do actually get fairly common yet intermittent skipping/stuttering in, e.g., YouTube videos, and also while gaming, but not sure if that’s the app or it’s an issue of online lag. As kn00tcn above suggested, it would be great if you guys could do a bit of a deep dive into diagnosing this and general optimization and troubleshooting, so that one might be able to quantify at what point something causes significant performance loss, which say fps averages mask.

    • Nictron
    • 3 years ago

    Thank you for the report back and honesty in explaining the issue.

    The TechReport is always my last port of call before making a decision on a purchase.

    Continue with quality over quantity, it is appreciated!

    • Hattig
    • 3 years ago

    Good work on redoing all the benches once the problem was discovered. Other sites would have whistled away into the sunset.

    Clearly that beta bios was doing something with some aspect of the system timings to trick a locked Intel CPU into thinking it can run faster. I’m guessing that Intel’s kibosh of that at least saved a lot of consumers from a serious previously undetected latency issue.

    And lastly, what are AMD thinking with the prices on those 470 boards?

      • kn00tcn
      • 3 years ago

      other sites wouldnt have had the issue since they wouldnt be running a beta bios from months ago? or they would at least ask amd why the card feels stuttery

        • Jeff Kampman
        • 3 years ago

        Other sites wouldn’t have noticed the issue since all they report is average FPS 🙂

          • djayjp
          • 3 years ago

          Actually even the very few that show frametimes (digital foundry) I don’t think noticed it since, according to their numbers, the 470 and 480 are practically identical (within at most 2fps). It’s maybe because they don’t graph the frametimes.

          [url<]http://www.eurogamer.net/articles/digitalfoundry-2016-amd-radeon-rx-470-review[/url<]

    • Klimax
    • 3 years ago

    [quote<]"The BIOS can't possibly be the cause!" I thought to myself smugly.[/quote<] He. Had already enough fun with BIOS/UEFI that I wouldn't have such thought. [quote<]That second trio of games certainly felt more responsive to input after the critical firmware update, but the data they generated wasn't meaningfully different. [/quote<] Different input loops. And high interrupt latency will cause various delays including processing keyboard and mouse (including their interrupts themselves). (Sufficiently bad situation can stutter mouse even in desktop) [quote<] I don't know precisely what was wrong with this beta firmware that was causing it to wreak havoc on DPC latency, but updating the firmware did fix it, so Occam's razor suggests something weird was going on.[/quote<] Missing fixes and workarounds for CPU/Chipset errata (or some other chip...), some problems with interrupt routing, something about ACPI tables,... damn too many causes.

    • dikowexeyu
    • 3 years ago

    You are absolutely right: recognizing and reporting a mistake is what makes me trust you.

    Congratulations, and thanks for the sincerity and attention to detail that you have towards us, the readers.

    • ColdMist
    • 3 years ago

    So I installed LatencyMon and my ‘floor’ is around 2500us. (Your pic shows 91us.)

    Nothing pops out as a problem. I have always had weird latency in games. I wish I knew how to fix it.

      • ColdMist
      • 3 years ago

      If you have a 1060/70/80, nVidia put out a beta driver update 2 weeks ago that fixes this.

      Now it sites around 100us.

    • PopcornMachine
    • 3 years ago

    Good job finding the problem. All this makes me realize the ton of work you guys do.

    So many things can go wrong, and it’s sometimes hard to keep track of everything when under pressure.

    Thanks.

    • Wonders
    • 3 years ago

    TR caught the issue and fixed it – and what’s more, now we UNDERSTAND a bit of the complexity behind graphics card reviews that sometimes causes delays. Clearly, there’s nothing easy about this business, a fact which makes me more fully appreciate solid progress such as the DPC revelation made here. It all adds up and goes in a good direction. Thanks to Jeff for candor and integrity. Feel like I’m getting to know his personality better because of this most recent harrowing little twist in the road, and I like it! I love seeing in color, and I’m certainly seeing some colorful facets here, which is excellent.

    • DPete27
    • 3 years ago

    Did you by chance capture a pre-fix screenshot of the LatencyMon results?

      • Jeff Kampman
      • 3 years ago

      Nope, I was so laser-focused on getting the RX 460 review done at the time that it didn’t even occur to me that I would be writing a follow-up piece.

    • djayjp
    • 3 years ago

    Strange, ~1000 microseconds of latency is only one millisecond. If 60fps is 16.6ms, why would this be significant? *Jeff* please tell me what the latency reading is now on your system (which produces normal frametimes) as I have similarly measured latency using that very software.

      • Jeff Kampman
      • 3 years ago

      Milliseconds are [i<]everything[/i<] in these latency-sensitive tests, because every other part of our analysis flows from frame times for each and every frame we track in our benchmarks. If a card is delivering frames every 17.7 vs 16.7 ms, our data would show that card running at 56.5 FPS instead of 60 FPS (1000/frame time). In a close race between cards, that kind of delta could throw the contest to one card or another. Just one extra millisecond of latency is a problem, but even worse, that error is being introduced into [i<]thousands of frames'[/i<] worth of data that's already got a lot of variance in it. I wouldn't have spent something like 40 hours retesting graphics cards this week if it wasn't a big deal. Take a look at the before and after data for GTA V in the RX 470 review. When the 99th-percentile frame times are four to five milliseconds higher, and we use that information to draw other conclusions, we are significantly misrepresenting the performance of the graphics cards in question.

        • djayjp
        • 3 years ago

        Yes, you’re right of course and that makes a lot of sense to me now since it’s at the hardware level and that’s exactly what you’re comparing. I was just thinking in terms of input latency but of course that’s something else entirely. Thank you for the explanation, though my system really is suffering from similar readings and I was wondering what “normal” DPC latency looks like now on your fixed system (?).

          • Jeff Kampman
          • 3 years ago

          Ah, I understand now. This is my main system after applying Nvidia’s Pascal hotfix (running a GTX 1080 in it right now): [url<]https://techreport.com/r.x/2016_8_12_Reexamining_the_unusual_frame_time_results_in_our_Radeon_RX_470_review/latencymon2.png[/url<]

            • djayjp
            • 3 years ago

            Wow, a factor of ten improvement! Thank you for the reference! I’ll use that to aim for (~100 microseconds–I still have a ways to go before I hit that figure…).

      • Klimax
      • 3 years ago

      Very simple. Every time interrupt or DPC id serviced by a core no user thread (or low priority system thread) can run. (Both run in “borrowed” context) Interrupts are most problematic as they have very high priority and cannot be obviously scheduled, thus code servicing them (usually part of vendor drivers) has to spend as little time as possible there and should schedule most of work to DPC. DPC aka deferred procedure call is scheduled by kernel to be run as soon as possible either at suitable core. Long execution of interrupt or problems around DPC mean one thing: Too many cycles spent away from user applications (too many context switches,…) and not quick enough processing of queued work.

      That’s why even 1000 microseconds is big deal.

      More info:
      [url<]https://msdn.microsoft.com/en-us/library/windows/hardware/ff548057.aspx[/url<] [url<]https://msdn.microsoft.com/en-us/library/windows/hardware/ff548024.aspx[/url<]

    • taisserroots
    • 3 years ago

    Notice how the 480 is better against the 970 with a higher IPC higher clocked processor, almost as if that’s dx11 with GCN. I don’t know but it’s funny seeing anandtech’s core I3 shoot out and seeing the i3 pushing AMD cards close to their max potential with the L3 starved 845 coming close with the i3 sometimes beating an i5 and then seeing this review kind of confirming that those holding on to full AMD builds are probably doing so irrationaly

    • smilingcrow
    • 3 years ago

    Considering that the recent Steam survey showed that the majority of gamers aren’t using Windows 10 even though it had been a free upgrade for about 11 months at the time of the survey the “Best API” option in the scatter plots is invalid for the majority.
    You’d need to have Best API options for Windows 10 and for older versions.
    In practice if that’s one option too many just having two options for DX11 v DX12 with Vulcan always included would make more sense maybe!

      • ET3D
      • 3 years ago

      Don’t jump to conclusions based on that survey. First of all, while 48% is technically not the majority of gamers, it’s very close to half. More importantly, many Steam players are there mostly for DOTA or CSGO, and don’t care much about DX12 games, and there are a lot of others who are casual. The top 10 graphics cards on the survey include Intel HD Graphics 4000, Intel Haswell, NVIDIA GeForce GT 720M, Intel HD Graphics 3000 and Intel Valleyview Baytrail.

      I think it would be a reasonable safe assumption to make that people who care about AAA games have a DX12 system, and in particular that most people who buy mid range to high end cards have Windows 10.

        • smilingcrow
        • 3 years ago

        The most common card are the GTX 960/970 which are fairly close to the RX 470.
        It goes to show how irrelevant the expensive cards are in the marketplace and how much disproportionate coverage they get.

          • ET3D
          • 3 years ago

          That’s the reason AMD said it’s concentrating on the price range it did.

          The enthusiasts are what drives tech sites, so it’s natural for these sites to concentrate on the high end.

            • djayjp
            • 3 years ago

            That’s how it should be! Performance/$ should be king.

    • TravelMug
    • 3 years ago

    Your 380X results for DOOM seem off as well. It shows almost no difference in average FPS between OGL and VLK and based on the frametime graphs the VLK performance seems a bit worse. That is not what I see with my 380X, the VLK performance is substantially better, it’s over 100FPS compared to the aropund 60 with OGL.

      • Jeff Kampman
      • 3 years ago

      Now that you mention it, I’m not sure why our results didn’t scale as they should have with that card. The Radeon Software 16.8.1 driver has been nothing but trouble for me from start to finish over the course of the past week, so I just retested the 380X with 16.8.2 and verified that it’s getting the expected performance boost with Doom under Vulkan. I’ll retest the Radeons this weekend and update the results.

        • TravelMug
        • 3 years ago

        I’m on 16.7.3 still, worked fine with those. Decided to sit tight for a couple of weeks and disabled both the automatic Windows Updates to avoid the Anniversary update and have some usable XBone controller support for all the games. Also didn’t see the need for an update to 16.8.1 based on the release notes. Will wait for a while again and update when forced to due to some issues 🙂

          • Jeff Kampman
          • 3 years ago

          Updated the RX 470 Doom Vulkan results.

            • TravelMug
            • 3 years ago

            Looks better, thanks! Hope there will be some more games with performance like this giving a bit more life to my 380X 🙂

    • Firestarter
    • 3 years ago

    I’ve read about DPC and tested my computer on it before, but it just seemed one of those things that you just had to [i<]hope[/i<] was okay because if it isn't and you want to fix it, you'll be pulling your hair out and cursing the day you heard about how this is a thing

    • obarthelemy
    • 3 years ago

    I’m impressed by your thoroughness and honesty. Thank you, and kudos.

    • Meadows
    • 3 years ago

    I wonder if this LatencyMon program can be used to verify other reviews in the future. Most notably, if the “Drivers” tab in the screenshot does what I think it does, you may be able to use it to find a root cause for bad USB or storage drive throughput in future motherboard reviews or otherwise.

    In particular, AMD’s storage drivers have had a bad rap for quite a while and I’m interested in whether their AM4 platform will fare any better when it comes out.

    • meerkt
    • 3 years ago

    Oddly, some Nvidia frame time graphs were better with the bad BIOS:
    [url<]https://techreport.com/review/30473/amd-radeon-rx-470-graphics-card-reviewed/5[/url<]

    • flip-mode
    • 3 years ago

    You may think this is a bad thing Jeff, but your reaction just shows that TR is the best tech site on the web. I do suppose it could be a big deal for anyone that rushed out and bought an RX 470, but if it is THAT big of a deal there is still time to initiate a return.

    * Damn, the RX 480 is now looking quite good. The big caveat to that is having to wait probably 8 to 12 weeks for product supply to stabilize and prices as well.

    I kinda think the RX 480 4GB is the golden child; 8GB seems over the top for the RX 480.

      • RAGEPRO
      • 3 years ago

      I dunno, man. That 8GB seems to have been a big benefit for the RX 480 in GTA V. I suspect it helps more than people realize.

      You know, a lot of people say things like “my game’s only using 3.4GB VRAM, so I don’t need 4GB.” But you wouldn’t want to run your PC with 85% of its memory full, would you? Memory managers always leave some extra space. I think having the extra VRAM can only be helpful.

        • synthtel2
        • 3 years ago

        A game nominally using 3.4 GB VRAM though is most likely using <2.5 GB for stuff that actually matters and the rest for cached textures (which could be evicted quickly if needed). Most games will run better if tuned to fill up as much VRAM as they can, but there’s no way in memory usage stats to distinguish essential stuff from cache, so well-tuned games look like they’re always straining VRAM.

          • RAGEPRO
          • 3 years ago

          Right? Isn’t that an argument in support of my point? I can’t tell. Haha.

            • synthtel2
            • 3 years ago

            Sorry, some pro and mostly con. While games will make some use of extra VRAM, the performance difference beyond what they need is very slight. My main point was that games don’t need anywhere near as much VRAM as people think they do, since the VRAM use readings are far higher than what’s actually needed.

    • chuckula
    • 3 years ago

    [quote<]The net effect of this error led us to wrongly conclude that the Radeon RX 480 8GB and the Radeon RX 470 were closely matched in performance, when in fact they're quite different.[/quote<] Wait, I R confuzzled here. The Rx 480 was not reviewed on the bad motherboard but on the Asus X99 that never had these DPC issues. [read it here: [url<]https://techreport.com/review/30328/amd-radeon-rx-480-graphics-card-reviewed/4[/url<] ] So... if the original Rx 470 review put it in a bad light compared to the Rx 480 that wasn't reviewed on the bad motherboard, why do the re-tested Rx 470 results indicate that there is a [b<]wider[/b<] gap between the cards based on that statement? Shouldn't the gap be narrower since the platform for the Rx 470 was originally hurting its performance?

      • Jeff Kampman
      • 3 years ago

      I just retested the RX 480 with different games, at different settings, with a different resolution, and on a different test platform. Our original review is not relevant here 😉

        • chuckula
        • 3 years ago

        Oh OK. That point might need some clarification since the article stressed the issue with the Rx 470 but didn’t specify that the Rx 480 numbers might have been affected as well.

    • Waco
    • 3 years ago

    This is why I continue to read and support Tech Report.

    Please, continue to strive for this level of transparency and accuracy. There’s no fault in being wrong as long as you learn from it and admit it!

    • xeridea
    • 3 years ago

    Looking at the games affected, the 480 not only distances itself from the 470, but looks considerably better than it did vs the original results. In Hitman and RoTR the gap was reduced or reversed, and GTA V had a major affect of making the 480 27% faster rather than 17% slower in 99th percentile. I wonder why the Polaris cards were affected more than the 970?

    • codedivine
    • 3 years ago

    Appreciate the hard work and honesty here. Thanks for the update, keep up the good work folks!

    • tootercomputer
    • 3 years ago

    Essentials of the scientific method include replication and verification, and consideration of alternative hypotheses (among other elements). IMHO, you lived up to the traditional high standards of TR by considering an alternative hypothesis and challenging your own results. And then immediately releasing those new results and owning up to an error. You cannot do it any better than that.

      • derFunkenstein
      • 3 years ago

      I agree. We’re all humans who make mistakes. The good ones can learn from them and own up to them.

      • AnotherReader
      • 3 years ago

      Hear, hear.

      • BurntMyBacon
      • 3 years ago

      [quote<]Essentials of the scientific method include replication and verification, and consideration of alternative hypotheses (among other elements).[/quote<] Essentials of the marketing method include obfuscation, repetition, redirection, and repetition. IMHO they lived up to TR's traditionally low standards of marketing competency by failing to either obfuscate the error, redirect criticism at other websites, or republish the same results until people believe them. [i<][b<]Thanks for sticking to what you are good at TR![/b<][/i<]

        • the
        • 3 years ago

        You forgot the classic fear, uncertainty and doubt.

    • maxxcool
    • 3 years ago

    “”but the pressure of deadlines got the better of us.””

    I 100% blame every single gerbil that bitched and moaned and posted negative comment after negative comment (some of then quite uncalled for and juvenile) on the delay of getting the review(s) out since the staff change.

    @Jeff. Keep it up. Doing great.

      • flip-mode
      • 3 years ago

      Crap, I don’t want to write this. But, you’ve started the blame game and I have to respond to that. JK has done a wonderful thing here by publishing a correction, but even JK will tell you that the responsibility to publish accurate articles rests with him. You can’t point fingers at the readers when something inaccurate gets published. Frankly, I wish you had just resisted the temptation to find a scapegoat. It was completely unnecessary. But at least you got some internet points from it.

        • maxxcool
        • 3 years ago

        Hey no worries man, it’s your opinion and I welcome it! Don’t say crap and feel bad 😛 .. It was just my opinion is all.

          • flip-mode
          • 3 years ago

          Ah! Well met, sir, well met.

        • thedosbox
        • 3 years ago

        “You can’t point fingers at the readers when something inaccurate gets published. ”

        That’s fair. However, the reality is that deadline pressure is real, especially for sites where publishing “first” generates more views and therefore money. Writers are human, and it clearly didn’t help that many of TR’s regulars were complaining about TR taking “too long” to get their reviews published.

        Hopefully this will remind those folks that quality takes time.

        Kudos to Jeff for recognizing his error and correcting it.

          • maxxcool
          • 3 years ago

          Also a fair statement, well said.

    • Anovoca
    • 3 years ago

    While unfortunate, it is highly probable that there are others out there who are reading this that have a similar experience with a recently purchased RX400 series card. In the end, you may have saved many other readers headaches of their own by publishing these findings.

    I for one never heard of DPC latency issues and will be downloading something to scan for it (on all of my computers) as soon as I get home.

      • morphine
      • 3 years ago

      Essentially, if your PC feels smooth all the time, you should be fine.

      • maxxcool
      • 3 years ago

      Yep me too! sounds like a fun experiment … and may explain why my older rig (1100t) ran some games so poorly despite running 3995mhz rock solid.

      • meerkt
      • 3 years ago

      If only there was a BIOS update to fix my laptop that sometimes crackles even playing the Windows beep sounds… Though, I think it’s actually related to network something in this case.

    • chuckula
    • 3 years ago

    Very interesting. It just goes to show how complex the hardware/software interactions can be.

    A few questions: Did this DPC business have any effect upon the results from Nvidia cards that have been reviewed recently?

    You appear to have fixed the DPC issue at the firmware level. Is this issue solely firmware driven or is it a combination of the OS & higher level software and the firmware together?

      • hansmuff
      • 3 years ago

      It’s software and firmware together. Some drivers can cause high DPC, usual suspects are wireless networking and audio but really any misbehaving driver can do it. Also, software that issues commands to drivers can indirectly cause it. For instance, some ASUS Xonar drivers are OK by themselves, but when you use the control panel software and/or sound filters, DPC can shoot up.

      Regarding NVIDIA, they recently issued a driver fix for high DPC on (at least) the Pascal line of graphics cards. I’m sure some of that had an impact on test results, but to what extend is not clear to me. I speculate it wasn’t all that bad, because the reviews have shown very good frame times on those cards.

      • Jeff Kampman
      • 3 years ago

      There was a separate Nvidia DPC bug floating around that I believe has been fixed now. Given the signature I’ve seen from DPC-related latency in our frame time graphs now, I can confidently say that none of our data in our Nvidia reviews was affected.

      I can’t claim to be an expert about the interactions between firmware and OS that appear to have caused this issue to begin with. However, my understanding is that DPC performance is a full-stack concern and bad firmware can throw everything above it off. Our tests suggest as much, at least.

Pin It on Pinterest

Share This