100ms rate is a hell of a lot of polling. Since you are a fellow 5900X owner I trust you are well acquainted with the performance hit/adverse behaviour/stuttering associated with unoptimized or overly frequent monitoring on modern systems. HWInfo default is 2000ms, and that still *can* have a slight impact on performance in some benchmarks and games. I understand the need for a polling rate as fast as 100ms when testing or reviewing hardware, but personally I wouldn't feel confident drawing any kind of conclusions from occasional spikes that I see from results at that polling rate.
Just a reminder that the 100ms poll rate is just for your eyes. We can achieve the exact same results from a 10000ms (ten seconds) poll rate (or any other). The high poll rate is not required to reproduce the issue. You're right to mention it though, I'm just clearing it up.
Actually a thing, just sayin':
For the uninitiated, this big hole in the middle of our processing I'm showing in a few different tools is the PC waiting for the GPU monitoring to let go of the CPU. If you set up your graphics just right, that hole causes a spike, like in the graph. I really don't want to get into this, but for those who feel like there's no proof of this and no details given....you've not got even a tenth of it... and nor do you need it. You have all you need to see it and go 'yeh that's a thing.'. No need to make things overly complex.
All that I want to know is, what was the impetus that compelled you to look into this? Was it noticeable stuttering in games? Buggy driver behaviour elsewhere?
If games do not reflect the same behaviour, and it was just because you happened to be benching Heaven one day and saw what you perceived to be irregularities in Afterburner frametime, then I honestly don't know if I would blame Nvidia for handling it the way they have.
I would go through the testing procedure (and just might tonight out of curiosity), but I doubt we'll get anywhere since you've established that a 3090 + 1600x900 Heaven + 100ms polling + 300fps are apparently equal parts necessary to reproduce the symptoms.
I won't get into why those other aspects might be unrealistic/problematic, but 100ms rate is a hell of a lot of polling. Since you are a fellow 5900X owner I trust you are well acquainted with the performance hit/adverse behaviour/stuttering associated with unoptimized or overly frequent monitoring on modern systems. HWInfo default is 2000ms, and that still *can* have a slight impact on performance in some benchmarks and games. I understand the need for a polling rate as fast as 100ms when testing or reviewing hardware, but personally I wouldn't feel confident drawing any kind of conclusions from occasional spikes that I see from results at that polling rate.
Noticeable stutter in game....but that isn't really anything to worry about in the context of this. Just because it is an actual thing in a real-life situation, doesn't make it more critical, and just because you can only see it in a forced scenario in a measurement tool, doesn't mean it's not significant.
I have glossed over this but while we're waiting for people to go read the thread I'll tell you a story about how I came to notice this incredibly elusive thing. You may be aware of the monitor technoloy ULMB, which comes with G Sync monitors (the module ones). It's a backlight strobe, basically. Great for fast motion, but theres a catch, despite being on a VRR monitor, it works at a fixed refresh rate. So, to avoid tearing you'd have to use vsync and you'd lose any kind of competitive edge you'd have gained.... but, not long ago, I discovered scanline sync. This is a feature of RTSS which allows you to syncronise to the vsync signals in a manner that does not cause double-buffering and the input lag that come with it. buuuut there's a catch. In order to keep it in that state, you need a MINIMUM framerate of AT LEAST your refresh rate. So for 120Hz I need 120FPS minimum. And it's gotta be stable. Instability in frametimes causes the tearline to roll into view and things get super ugly super fast. TLDR it's mega demanding on the GPU and CPU. The old PC wasn't cutting it. And along rolls the new one praise the silicon gods and I can now hit that FPS and it is freakin. awesome. But it's better, because I'm pretty sure I can double it (which comes with all the usual benefits of doubling framerate but just drops half of the frames from displaying because refresh rate.) I always wanted to try this so off I went aiming for 240 FPS minimum. And this bloody thing raised its ugly head.
And yeh, I get it, that's a super edge case. But like I've said above, this edge case just exposed a problem that is always there. The real world problems for me did not start when I tried for 240FPS minimum. Framerates aren't even the bulk of the concern from real-world problems. The problems started long ago and have been covered up by the fact that the old card couldn't realistically hit the frametimes needed to see it. Trying for 240FPS didn't cause the problem, it just uncovered it.
@xcasxcursex I thought it only fair to follow your test procedure before I pass more judgment. This 5900X is bone stock again today because it turns out that my CO per-core settings still need work.
- Run #1 and #2 are with all sensors enabled. Run #3 is with GPU sensors disabled.
- Afterburner at 100ms polling rate. Heaven lowest settings, 1600x900.
- FPS during Heaven at these settings is about 400-600fps, but generally in the 400-500fps range.
- Priority cores on my 5900X are conveniently right at the top, Core 0 and Core 1.
View attachment 204665 View attachment 204664
Run #1 and #2 (all sensors):
View attachment 204666 View attachment 204667
Run #3 (no GPU sensors):
View attachment 204668
I'm sorry, but I just don't see much of a difference here to support any sort of conclusion. And no real patterns as to the frequency of the frametime spikes either - if you take some liberties with "patterns" you can kinda see a little bit of it in run #1, but run #2 was done right after at the exact same settings and does not confirm that phenomenon.
Also, Heaven is kind of a crappy benchmark, I only ever use it for preliminary vetting of a GPU undervolt curve (and even then it sucks because the real stress test for my 2060 Super undervolt is days/weeks of COD MW19). It's from 2009, for pete's sake, and we're artificially running it at 1600x900 low. I don't even use it to verify my Vega 7 iGPU OCs on my 4650G because of how much better of a benchmark Valley is, being less CPU-reliant than Heaven.
Trying to expect game-level FPS consistency and smoothness out of something like Heaven - and drawing immediate connections to actual game performance based on observations in Heaven - is a bit ambitious, don't you think?
----
So yeah, no dice. To put it politely, I feel like you might be making a mountain out of a molehill. If you aren't suffering actually any major adverse impacts in your in-game experiences, why bother with trying to get through to Nvidia based on something that you think you see in Heaven benchmark?
Like, I'm sure you bought that 3090 to game, not to run Heaven 2009, right?
Whichever way you decide to go with this, best of luck. I know it's not always easy to convey a less-than-obvious observation or issue to brain-dead customer service reps at any company, be it Nvidia or AMD, Ford or GM.
I appreciate your running the tests! Thanks!! Unfortunately I can't really see anything in those screenshots. They look like they're long enough for an entire run of the benchmark. which is some minutes long, we're looking for an event that last for milliseconds.... It's just lost at this resolution I'm afraid. That being said, it is possible to infer a lot from them because the constant spikes over a long period have the effect of raising the averages, and I don't see anything like that here.
Yes, heaven is a crappy tool for lots of things, but not for this. If you have issues with heaven's performance, try this: When you run it, click camera and then free or walk. It'll sit still and give you a solid frametime to use for testing. Remember, this is not a graphics test. We're just putting a load on the system in a convenient way to make a general performance problem stand out. We happen to be doing it with graphics tools, so we can see the result graphically, but it's not a graphics test.
Even if you don't know how to analyse kernel tracing as pictured above, I'm sure you can see that the computer is doing stuff, and then there's a big hole where it's doing nothing, and then it goes back to doing stuff. This is why it's not a molehill. That's not a hole in the graphics processing, that's a hole in
everything processing. You can't fake that and you can't get it from a problem with your PC. That's code-based. It's waiting for something because it is programmed to wait.
This is why a teensy stutter that people are keen to fob off as no biggie, is actually a biggie. The teensy stutter isn't the problem. The big hole is. It's just that if we make that big hole occur during graphics processing, we can see a spike. That spike, that stutter, is not the problem. It's just a visualisation of it.
I bought the 3090 to do all kinds of things, gaming being one, but that branches out to things like simulation and software development. This issue effects all of that.... as well as preventing me from using the GPU as intended for gaming. Again, this isn't a gaming thing and it's not a graphics thing. This is a bug impacting performance, that's all. It's not at all unreasonable to expect it to behave properly.... And even if it's entirely fiction, it's not unreasonable to have a competent engineer provide service to my new card....and let us remember THAT is the purpose of this thread. Not to even get it fixed. I'm just trying to get a competent staffer at nvidia to look at it, that's all. I think that's a fair ask. I did pay for it. I'm legit surprised the community doesn't agree....
