I googled today and there are a lot of references from people claiming that Win10 1903 introduces DPC latencies in the area of up to 1300 microseconds = 1,3ms which is a lot ...

The best appears to be now to delay the upgrade to 1903 and to stay on 1809 for a while until the issues are fixed.

Thanks Timur, btw, you can see reports in the net that the 1.3 ms DPC spikes are caused by

ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

One of the platforms collecting informations: https://www.reddit.com/r/Windows10/comm … cy_issues/

This doesn't look to me like the usual driver problem that can happen
and many ppl seem to be impacted by this.

Highest DPC routine execution time (µs):              1907,661667
Driver with highest DPC routine execution time:       ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

The thing is: This does not happen all the time, but only sporadically. So there ought to be something that is triggering it.

Here it is only happens every once in a while, more like minutes rather than seconds. So the real cause would yet have to be found.

Kernel Timer Latency does not return useful numbers for me. I get numbers over 20000 us kernel times at default timer resolution. Changing the Windows timer resolution decreases the measurement, but also leads to some erratic jumps at specific resolution settings.

Currently I am checking HPET and DynamicTick settings.

Additionally I am checking how CPU load (Prime95 et al) affects this. I just had 1700 us for the NVidia driver and NDIS, but not NTFSKRNL, so there may be some connections. I have yet to check if the Windows process scheduler was finally fixed, which is partially broken since the very first Creators version (when game mode was introduced). Maybe it got worse and thus causes these high DPC measurement spikes for single threads.

bcdedit /set disabledynamictick yes

might do the trick. I am running LatencyMon for hours already and the highest NTOSKRNL execution time was 0.768 ms.

Both the Nvidia driver (2 ms) and DirectX (1 ms) cause high latencies during gaming, even with GPU power-saving being disabled. No idea how that would translate to productivity load yet.

Well, under 1000 us for NTOSKRNL is better than up to 2000 us at least. I still get over 1000 us, though. So testing is still in progress.

And for me it is still only a single thread/core, so depending on your CPU it may not be a real problem in practice. Keep in mind that the main ASIO driver thread only runs on a single (different) core anyway.

I will keep testing after I am finished updating all drivers for 1903. Curiously some Intel drivers from Gigabyte are more recent than Intel drivers from Intel (RST, Chipset), other are more recent from Intel (WIFI, BT, LAN). So it's a matter of matching and mixing them.

Well, things are a bit more complicated and I am not convinced that the measured latencies are "real". There are several different scenarios at play.

1. Device drivers seem to affect the measured latency of NTOSKRNL, on my system the NVidia driver seems to have the biggest impact, though. Turning off various devices via Device-Manager and in addition to some services decreased the *long term* measured latencies of NTOSKRNL.

2. There are times when the measured system latency is reported higher than any single process/driver latency, including NTOSKRNL's latency. This alone points to measuring issues.

3. Then there are times where small spikes of NTOSKRNL are *not* measured as general system latency. This is what I would expect on a multi-core system anyway.

4. Then again there are larger spikes of NTOSKRNL that *do* measure as general system latency, despite my system using 16 logical cores that are all just idle and free to service DPCs.

The latter is what other people report here, but there is more to it. Notice the latency spike measuring around 1390 us? I can reproduce this same number every time I restart LatencyMon, but this is only the *first* large spike being measured. If I let LatencyMon run for hours I get spikes well over 3000 us, but as soon as I restart the measurement it's back to those 1390ish spikes and over time it increases over 3000 us again.

This is rather unusual and again might point to a measuring error rather than a real problem. Furthermore I was not able to measure any increase in CPU load or CPU context switches of NTOSKRNL while these supposed spikes happen.

What's next is to test if any audio dropouts even happen at lowest audio buffer settings when these "measured" spikes occur.

And now it's at 8200 us. I will let the PC run over night to see how much more the value increases.

after the update my pc was always working harder due to a service called delivery optimazation..a was having a 12% cpu use in idle...which is insane for an 8th gen i7...i had to manually turn off this service and everything is back to normal

Microsoft are aware of the issue(s); are requesting reports via the feedback hub (gearslutz thread)

1903 is loaded with tweaks to background services, so I'd guess going to take a few months to iron out wringles

I am experiencing the same issue with my Babyface Pro and latency problems with the lowest setting however i did not notice them until after the Windows updates a few days ago. Since the Win10 1903 update been out a while I can't say for certain if it's caused by it but I do experiencing audio clicks which resulting in a lot of buffer size errors. It's caused by any program that uses the audio interface and there are no audio interfaces enabled beside the RME Babyface Pro.

I have never experienced this since i bought the BF Pro several years ago. Something is not right and i I am pretty sure it's not a hardware problem.

I have an issue with Kontakt that didn't happen before 1903. At 48k, 128 samples ASIO buffer, things are clicking in certain cases which never happened before. I have a FL Studio project using Spitfire Chamber Strings that showcases the issue. A friend of mine also reports the same thing happening with 1903, he's using UCX (also latest RME drivers). Didn't happen in 1809 at all.

If I send the same MIDI data to Kontakt standalone, it also happens, so it's not a DAW thing. It's also not a USB thing because I connect my UFX+ via Thunderbolt.

Most interesting thing: if I switch audio output to WASAPI or DirectSound, no clicks at all... Also clicks don't happen in rendered audio, it's "just" a realtime thing.

So I'm not sure if this is MSFT messing something up, or maybe RME drivers needing some sort of an update to make things work better with 1903.

A very happy RME UFX+ & ARC owner

FWIW, I had read not long ago about a kernel performance problem in 1903 for audio, which is not yet fixed. Just can't remember where...

Can't you simply restore an older disk image and simply deny upgrades for even longer by using O&O Win 10 shutup's options to avoid upgrades for even longer ?

Maybe it also helps to define ie the time window for working hours longer from 5 am to 4 am or something like this to prevent Microsoft to upgrade in case you do not want?

Get Macrium Reflect Home, this is an excellent backup software based on full, differential and incremental backups. Gives you a lot of reliable backup/restore possibilities.

I created ie different Golden Images for Win7 over the years.
For Win10 I am using the upgrade installation which runs very well.

By this I have a very good basement on a stable Win 7 and can change to Win 10 for comparison and benchmarking purposes.

Maybe you can use Win 7 in a similar way for your workflow to ie use it when Win 10 has issues.

At least I recommend to create a golden image that is known to work containing all required applications.

From time to time I restore a golden image to get rid of garbage in the registry from trying new software, then upgrade some applications to known working higher versions and create then a new golden Win7 image.

As newer HW doesn't support Win 7 anymore your golden image might be a proven Win10 installation with network being disabled,  so that Microsoft can not enforce any upgrade.

On a second SSD "for production" you can upgrade this installation to the latest Win10. If it runs well create a new golden image but still keep the previous for safety reasons.

Tip: put your user data to a different disk. The golden image only should contain OS, applications and sample libraries, so that everything matches with Windows registry.
By this those golden images do not become too big.

BTW... Macrium Reflect Home is very fast in restoring backup images because of it's Rapid Delta Restore mechanism. Only those blocks on disk are being changed that need to be changed.

This results in high speed and low wear on SSD  as you have very few write cycles to SSD by this.

I can restore my 1 TB Samsung EVO which is filled to approx   60% in around 10-12 Minutes to the status of last week or when restoring a golden image. Where boot time alone takes quite long because of the long lasting BIOS POST checks of my server board...

So for a normal mainboard with consumer components it will be even faster offering more than excellent turn around times to change to a proven image.

You only need to take care of few things manually. Save ie your Firefox bookmarks before restoring an older image and reload the backup of the bookmarks afterwards.

Some other software might require some additional manual tasks for yoUR backup and restore procedure. Like ie application defaults for Cubase and other applications.

Besides using Macrium for the boot ssd also containing all applications, I am mirroring my users profiles (c:\users) and my user data on k: and r: (dedicated ssd for recording) by using a mirroring called Freefilesync which is reliable and performant and even open source.
As automatic job I execute mirroring on a daily basis.

By this I can easily restore application defaults for certain applicatiobs as needed after a restore of a golden image.

These are the building blocks, I am sure that you can work out something similar to have more options in case of trouble with Windows to come back to work in less than 15 Minutes.

We can not reproduce these issues. I also see no chance in fixing this within the driver.

But you still have some options left to try - the old school stuff. Optimization for background processes or not, CPU priorities for audio/ASIO threads, MMCSS on/off in driver and application. One of these might make a difference.

Eventually try bitsum's process lasso.

BTW there are ways to make disk images smaller to make it better manageable.
It's a matter of organizIng your data.

I have only os programs and sample libs on a 1TB SSD.

All my recordings are on a separate dedicated ssd of 512 GB.

My bulk/user data is on a separate 3TB HD with 7200 U/Min.

Backups I perform to 1 internal 10 TB harddisk and to 1 external 10 TB harddisk.

Shall you have so many sample libs, move it to a separate disk and leave it out from disk image.

Shall you have so many recordings, put it on a separate disk as me.

By this you should be able to get a compact compressed disk image like me from the main boot ssd of under 500 GB in size which is easily manageable and quickly restore able by Macrium Reflect.

Networks could also be broken up into an internal and external one to internet if you have mainboard with 2 lan ports. Otherwise try to use perhaps smth like a proxy in front of Internet blocking access to ms upgrade services as good as possible although this might be challenging.

At least for so long as the issue persists once it's fixed you don't need this anymore.

But you need a second SSD as test installation not too loose too much time with rbackup restore.