[Solved]What is wrong with NV drivers? DPC Latency

Well then, then just don't come up and reply with "nonsense" and "beliefs" when someone tries to link stuff so you can see their point of view and why they sustain this or that argument. You have given me zero sources or videos so I can say "oh snap, he is right about this particular thing". The only ones who say you should disable HPET on the BIOS are "guides" made by random people who guess its ok to disable it. That's it. I showed you a segment of a video where an user actually explains why disabling HPET on the BIOS isn't a good idea. And what do you do? Saying that I should be banned. Just lol. And as if you haven't offended me indirectly, because of course saying what I posted its a "superstitious belief in magic numbers" is so very nice of you. Yet disabling HPET on BIOS isn't. And without explaining any of the two.

 

It disappears from device manager and Linux doesn't list it as available clock source anymore. Simple.
Other simple thing: I have a flat frame time graph in lots of demanding games like BFV or Hitman 2. What else to prove? Do you also expect somebody to fly you into space so you can start accepting that earth isn't flat?

 

You have a severe attitude problem. And your frametime with v-sync off wasn't flat whatsoever; it had fluctuations. Use RTSS Framerate limiter, try it for once if you never have and you'll see a real flat frametime line graph. Also, turn on v-sync and disable any framerate limiter and go to Exclusive Fullscreen mode. Look at the frametime disaster of never being 16.6 ms. This is why you actually need RTSS, nVidia Framerate limiter or FSO at games that work properly with them active.

 

What you need to prove isn't that turning it off doesn't hurt anything. Relax.
You need to prove turning it off does anything at all. Other than cure your OCD. Otherwise, you're also doing things for no reason.

 

As you can see, it's not there:
https://abload.de/img/hpetmissingm9kon.png
Running without it for probably almost two years now. No weird crashes, no weird stutter etc.

 

I'm not sure how i can be more clear.

Ok, turn hpet back on and tell me if you notice any difference.

If there is no difference, then you're changing something for no reason, right? Potentially, just like Smough and his cmd commands.

 

Wrong. hwinfo uses HPET by default. It likely can do so via kernel driver, despite of not being the kernel's default clock source. If hwinfo driver can do it, other drivers can do it too.
Just because there are no problems, it doesn't mean there will never be any. It has been proven (even the anandtech link mentions it) that HPET causes harm these days. And I've already pointed out several times that there are no advantages over TSC in reality (or someone proves otherwise with a real example than can be reproduced, lengthy YT channels of "gamers" talking clever are not my source for education), so it's perfectly rational to turn HPET off in bios.

Edit: The alternative would be that you are smarter than Linux kernel devs, which I doubt.

 

Lol no offense. There's no reason to have a horse in this race.
It's just, neither you or @aufkrawall2 have proven taking any action is beneficial.
Your evidence is anecdotal (it feels so much smoother), his is paranoia (just because there are no problems, it doesn't mean there will never be any).

Oh, and hwinfo using hpet is useful. Doesn't hurt anything. In fact, BenchMate uses hwinfo's hpet implementation to verify overclocks. Which, like aufkrawall pointed out, isn't a mainstream thing to use, but it certainly doesn't hurt anything when it does it.

 

While I haven't investigated it, I really don't think that's the case. I'm pretty sure Windows does set this on demand, -and- applications can request a higher rate as well. There is no way every developer for every program would even know about setting a higher resolution timer, and even then they cannot know what else is running on your system and what impact this would have. That would likely go against recommended guidelines. Windows itself would have a much better of idea based on types of processes and load, even if it can be forced on an individual basis.

 

Its all good, I get what you are saying. Maybe I shouldn't even disable them, but I keep doing it. I will re-enable them and I will do some tests at some point.

 

@Martigen That's what dynamic tick is for but even fully dynticks / no_hz_full systems have a tickratre (I think). Something like a "base" rate or a maximum rate...

 

Guys could you offer some insight on this, ie:

- no latency spikes when idle, notable spikes when gaming, acceptable or not and indeed can some other "stall" like loading assets be visible in latencymon?

EDIT: happpens when eg. running Media Player and browsing (Firefox) as well. Frack...

(high DPC latency pointing to NVIDIA Windows Kernel Mode driver).

Are NV drivers again having latency issues? Using 436.30 now but I had this with 442.01 as well and worse.
I tried disabling interrupt moderation completely now for network adapter. As of typing this:

Spoiler

so ISR/DPC atm somewhat fine but high interrupt to process latency recorded.

 

You can ignore it. Do not forget that Latencymon is aimed at audio processing/recording people where almost real-time efficiency is needed.

 

Really? Thanks.

As it happens, since posting that image, I wasn't able to reproduce that spike even when doing exact same things (Media Player, Firefox, UPlay, Task Manager open).

I'm not one to be obsessed with Latencymon but like said lately I've had clear stalling in Division 2 that I thought was remediated by tweaking interrupt moderation for network adapter (it's a constantly online game so makes sense in that regard).

However for curiosity left Latencymon running while playing RAGE 2 and there were again notable "drop-outs" in places, not nearly as severe as in Division 2 but notable.
I wasnt sure if that was just asset streaming or something else, hence these questions here.

I suppose any glitch or stall anywhere can cause a high reading in Latencymon? Meaning even if the said stall does not originate from ISR/DPC execution time or interrupt to process latency?

(Example: UAC prompts create a reproducible spike in Latencymon. Guess it again makes sense as the system is waiting for user input).

 

Follow up post:

running Ryzen High Performance power plan (of course), installed latest chipset drivers and using latest BIOS (w/ AGESA 1004b).

I just reinstalled chipset drivers and that seems to have properly disabled core parking now w/ High perf. power plan according to Ryzen Master.
Previously, even with High perf. power plan, unused cores went to "Sleep". Which was kind of strange to me anyway.

I'm not sure if 1909 update (applied yesterday) + reinstalling chipset drivers fixed this or what happened exactly. Perhaps this was the source of the issues (doubt it a bit but who knows).

If I still get lag / stalls in games I'll clean install Windows, been too long anyway.

 

If you check latencyMon site it says to test with nothing running, not with a load.

 

I once benchmarked Crysis 3 (already on Windows 10) when CPU bound and if I recall correctly, it really stayed at 15ms without Origin running and CPU performance becoming very crippled. I might try again at some point so we can know for sure about whether it really stays at 15 or just something slightly better.

 

Yeah, should have checked that site... RTFM

thanks a lot!

EDIT: correction about Ryzen Master / core Sleep: still happens when just idling at desktop.
(Prior I had at least Media Player running which apparently created enough load to keep all cores active).

Surely by design it's like that, but to avoid spreading misinformation wanted to clarify this.

 

I learned that the computer time is drifting and also windows somehow checking your timing and timer support every time you reboot the computer and system load up.
We are talking about the Newest CPU's with TSC-Invariant

We need to fix 3 issues.

CPU time Drift - If you don't restart your computer every day you are going to have drifted, I saw computers at work drifting 59 Seconds after a month or so! - The fix is installing NTP software to keep timing - Works fine I tested it
https://time.is/
https://www.meinbergglobal.com/english/sw/ntp.htm

The program will use its own service instead of windows time, upkeeping the time all the time, fixing the drift at any giving moment or not letting it to happen.

RTC is important timer that needs to be sync with the OS because the CPU doesn't know what is real until it is SYNC, as we know power adjustments and drifting will occur no matter what.
1 second in real life needs to be 1 second in the CPU, or else weird things will happen. TSC does a good job but can't do it 100% long enough.

Windows Power Saving/Bios Power Saving - Only use specific C State, for example, AMD it's called Global State State, for me it's automatic, it doesn't interrupt performance or cause issue. Disable EIST and Cool & Quiet though. and use Maximum power Management profile with minimum CPU 100% and disable Use suspend

Making sure we are using the best for a specific CPU. what I mean it's not performance, it's about precision. for example, I can't be sure if for AMD 1950x because it has NUMA or UMA which has 2 separate CPU's inside 1 means they need to SYNC. now Tscsyncpolicy /Enhanced /Legacy /Default I want to know what it is actually using. because I can't be sure if windows really really know which one to choose. maybe bug? maybe something else... we know that sometimes something doesn't work. And we already know that we do need to add BCDEDIT command no matter what, DisabledynamicTick Yes
On gigabyte motherboard, I do have SpreadSpecturm on CPU that I can't disable. look as follow V V

https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt

Spoiler

3.3) TSC and multi-socket / NUMA

Multi-socket systems, especially large multi-socket systems are likely to have
individual clocksources rather than a single, universally distributed clock.
Since these clocks are driven by different crystals, they will not have
perfectly matched frequency, and temperature and electrical variations will
cause the CPU clocks, and thus the TSCs to drift over time. Depending on the
exact clock and bus design, the drift may or may not be fixed in absolute
error, and may accumulate over time.

In addition, very large systems may deliberately slew the clocks of individual
cores. This technique, known as spread-spectrum clocking, reduces EMI at the
clock frequency and harmonics of it, which may be required to pass FCC
standards for telecommunications and computer equipment.

It is recommended not to trust the TSCs to remain synchronized on NUMA or
multiple socket systems for these reasons.

I fixed many weird issues I had. including a weird randomly stuttering lag in COD MW 2019 which randomly means if I ran the game it could work fine, but then if I exit and ran again it would start stuttering Heavy, like HDD 5400 rpm run 100% and CPU 100% usage for 5 seconds which what actually happened. investigating with RTSS I saw that when the freeze happens I saw that CPU usage from NODE0 1-15 with SMT goes to 100% between all cores, not all, like 5-6 cores, happens on intervals of 10-20 and sometimes minutes. and randomly when I ran it the second time it would run on NODE1 which is 16-31 and didn't have any stuttering at all!. After checking again on NODE0 and disabling SMT, the game worked perfectly.

Another issue is Latency NVIDIA when using Power Save or Adaptive, whenever the GPU doesn't use more than 139mhz or ram there will be heavy latency on the computer because windows use WDDM and need to refresh what you see on screen, 139mhz is not enough. Fixing it is using Maximum performance globally, though it's not really needed, but if you use Desktop heavily then do so. could also follow F33RT'y using the MSI Burner to set Voltage/Core Maximum Limit with CTRL + F and it should fix may be other issues, but will run 100% all the time.

Somehow after Firmware update in LatencyMon, my devices decided to use other core for ISR 23,24. don't know why but Core0 is not used for ISR. don't see any real issues with that, but it interesting why it make so on the firmware, bug or intentionally?