XPS 15 9570 Owners Thread

Didnt you say, it was fixed for you? Isn't this the same problem we talked about the other days, that it doesn't properly boost up? It seems the logic is set somehow too low and it wants to save energy too much, even if the GPU usage says 90-99% it sometimes never boost up one step further and stays in a lower clock state, even all temps are fine, and that leads to bad FPS. Or do you mean something else with that?

I noticed the bug with the touch btw before too several times was already about to make a ticket about it. But if they dont give back S3 and fix the S3 state bug, this laptop just stays useless. The laptop just always keeps warm in modern standby, or the fans just never stop. And it would be way nicer if they maybe optimize the fan logic, but that wont ever happen I guess too.

Lenovo was so nice btw to give back S3 on the X1 carbon some weeks ago, after lots of people complained about bad modern standby.... and ALL PEOPLE were happy afterward:

https://forums.lenovo.com/t5/ThinkP...n-Battery-drain-in-sleep/td-p/4075415/page/30

I am totally not going for Linux, just to have a proper sleep on this laptop.

 

Sadly this is a different issue. The laptop boosts properly but when it hits 74C it cuts the clocks of the GPU dramatically. If I run 4 threads in Prime95 and Heaven the clocks go from 139MHz to as high as 800MHz. Running Far Cry 5 my clocks sit around 1GHz after 20 minutes of gaming. Something has changed since I spent days benchmarking my first 9570, the temp limit on the GPU seems to be ~4C lower and much more willing to cut the clocks.

 

Did you try to disable BD PROCHOT in ThrottleStop if it helps? It is actually for this scenario of throttling CPU or GPU and vice versa if one gets hot for systems with a dGPU. There is a chance the option is ignored by Dells bios though.

Also try how it behaves if you disable turbo, does the GPU boost up again after some short time maybe?

Tried to play around with the clocking curve in MSI AB maybe?

I actually learned something btw the other day: You can actually set the undervolt for the cores easily to some crazy number like -0.350V. You may now ask... how? Well... I actually learned, that you cant really undervolt these new Intel CPUs anymore, as you were able to before. It is more like an "outside" value, not a fixed forced one.

So something like this totally works with no issue at all:



The important value is just the Cache one, which shouldn't go higher than that. Going higher for the iGPU also got for me at least some glitches here and there, for example, black screens sometimes after waking up.

So how is this -0.350V to understand? Well. To me it seems, that it is just a guideline value for the CPU. It still decides on its own what voltage to use, so you cant really force it to use the value. This has some interesting side effect though. Because if you set it to something like -0.350V, that means, that the CPU wont boost anymore over the value, where a -0.350V offset would be stable (as to its intern voltage tables). So... the CPU mostly will boost to something like 3Ghz, not more. That is a sweet thing actually because you can force the CPU for gaming to a value like 3GHz, which is enough for most games, and still keep good temps. Instead of the turbo boost off, which just gives something like 2.2GHz which might be too low for some games.

What this also means is of course, that you are just limiting the CPU. You wont get the same performance anymore if you set it too high. So if you want max performance, you have to find the sweet spot actually. That is also the reason, why on prime you mostly just get a 3.3GHz anymore with something like 0.96V. Play around with the value. It might happen you get a 3.4 or even a 3.6 or even 3.8 and that means more performance. Like I said, you cant really force a vcore offfset anymore on these chips. The moment you understand this, it might help you understand how it works and how you can take advantage of it.

I also noticed that iff you deactivate turbo boost, and the CPU goes to a clock of 2.2GHz, the GPU mostly somehow isnt clocking up anymore too properly in some games. It seems their voltage is connected or the GPU thinks it is ok to not clock up, because of the CPU usnt boosted too high and there is no need to clock higher.

I also noticed a value of 128 for SST isnt good for some games, and setting it to 0 actually helps to stabalize the FPS. The CPU mostly will sit at 3.8GHz with a low drain which doesnt produce high temps, but helps for the GPU to clock down randomly.

 

The value actually used by the CPU is the maximum of the two: max(-350,-134)=-134

I don't have this problem and it seems unlikely that there is a connection between their voltages. It's more likely that that the 75c threshold kicks in for the GPU, or they have introduced a new threshold on some value and the GPU power limit is clamped when crossed.

 

Cache and core are not connected. They dont need to have the same value (thats a mythos said somewhere and people took it for granted). Just iGPU and system agent are. You can undervolt cache and core seperatly with different values.

It is like I tried to explain in that post. You just give the CPU a value to consider, it wont use it, because it wants to stay stable. It knows internally which values are stable.

Lets say you have something like this

3.9GHz 1.1V
3.8GHz 1.05V
3.6GHz 1.0V
3.3GHz 0.98V
3.0GHz 0.86V

Then if you set it to -0.350V, the CPU knows internally which value is still stable (for the core, not the cache), and wont boost over that clock anymore. It doesnt mean it is a flat -0.350 and just boost to 3.9GHz and POOF bluecreen. That wont happen.

A value of -0.125 might actually work as a flat undervolt, after that it gets critical. The CPU wont crash though, even if you set it to -0.350. It just wont boost anymore over the point, where -0.350 would still be stable, which is something like 3GHz and 0.86V (with an substracted offset of 125mV).

You can easily test this out and see it works how I said it does. You can also watch this video if you want:

 

I saw a video that was describing that phenomenon. Tried and didn't work. I tried again now, still doesn't work.
-350 on the core, still 3.9Ghz in stress test and VID the usual 0.95 (confirming that the actual undervolt is -130)

 

I just went into prime95:

core "undervolt": -350mV => CPU around 3.0GHz with 0.85V
core undervolt: -160mV => CPU around 3.4GHz with 0.98V

I dont get more than 3-3.3 in Prime95 though and it jumps around 3-3.3 with something like 0.83-0.96V. The CPU seems to try to work out internally and that is what I said. It isnt a flat value after some value, and the CPU decides on itself, if the voltage isnt high enough, how far it will clock.

 

I tried with prime95 28.7. For me, it works in the exact OPPOSITE way.
But it is still quite interesting because from my other stress tests I thought that core/cache were tied to their maximum.
core -137/ cache -140: 3.1Ghz/0.83V
core -350/ cache -140: 3.3Ghz/0.87V
The difference is 200mhz but it's there, I can observe it happen real-time as switch between profiles.
core -137/ cache -140: 2.2Ghz/0.75V
core -350/ cache -140: 2.2Ghz/0.71V

It seems that there is a further 40mv drop in the second case. I didn't expect that!
In sense, this is good news. I have more headroom than I thought.
I have to dig deeper into this, to see if it's stable.

This is essentially working as a regular undervolting for me. There is not "autoregulation" or "how far it will clock". It burns less power (W) so it can clock higher while staying within the 56W envelope.

Seems that my real limit undervolt is core -190/ cache -140 (it behaves the same as -350/-140)

@custom90gt @pressing This might be interesting for you too.

 

Undervolted core -250mv, ran TS bench. No change in 6300HQ speeds although laptop bricked after 30 seconds. 2 restarts and works again.

 

@pressing I saw no changes in TS bench, but in prime95 it did something.

 

@abujafar, I thought we had already discussed in the thermal thread that cache and cpu didn't have to be tied together? My CPU doesn't undervolt much more than the cache while maintaining full turbo speeds, luck of the draw I suppose. Trying things like -300mv on my previous 9570 and it never limited the speed, only BOSD. I believe it was an earlier @B0B youtube video where I first heard him talk about limiting the speed that way. Perhaps I'll play around with it again.

Still undecided if I will keep this laptop or not. In benchmarks it's quite a bit faster than my 9560, but in real life that remains to be seen.

 

"Brand new" Intel archecture & nVidia 2050 are right around the corner . . .

 

Something is always right around the corner. My guess is the 2050 won't be out for quite some time though.

 

@custom90gt I agree, and especially 10nm Intel chips won't be available until the end of next year (according to their current timetable)

 

Well, from my previous testing I got conviced that Vcore/Vcache were implicitely tied. Guess I was wrong.
I didn't observe any speed limit (like in the video), just a better undervolting!

 

For me, what’s more valuable is the 14nm Whiskey lake or whatever they call it revision for the 45w CPU’s. It will have an Integrated WiFi controller, so say goodbye to Killer WiFi cards, hello to faster internet speed, better battery life, goodbye to WiFi sleep/wake/hibernation issues.

The new ones have other good features too, including fixes to spectre/meltdown issues on the hardware itself.

 

New BIOS update cripples gpu performance by introducinga 74c throttle temp, according to reports

 

@Eason the 74c reduction was already present in the 1.3.1 for sure and maybe some other power clamping rules too.

This is the result of people (rightfully) complaining that the laptop overheats.

I hope people complain about the new threshold.

 

Just Updated my XPS15 9570 (i7/16gb/512gb ssd/4k touch) to the new BIOS 1.4.1 and now the touchscreen does not work after waking from sleep via closing/opening the screen lid. I have to restart the laptop to make the touchscreen work again.

Does anyone know how to downgrade back to BIOS 1.3.1 or earlier just to have this back to normal again? I tried flashing, emergency bios recovery (crtl+esc), and non of it works. I get a BIOS flash error when downgrading to a lower BIOS version but it accepts a reflash of the current one (BIOS 1.4.1).

 

There is a setting in the BIOS that will allow you to flash older versions.
I am at office so i have no access to look up where exactly you will find it.

 

I already checked that setting, it still does not want to downgrade the BIOS to the older. Also, the new BIOS fixes/enhancements mentions that it fixed a touchscreen behavior in BIOS,but instead i think it broke the touchscreen when in windows... Im just waiting for feedback from others if they have the same problem i have to confirm that its not my laptop that has this issue. Already called dell support and they will get back to me regarding this too.

 

Hi there, would you mind running LatencyMon for 2 minutes on your machine? I am curious to know whether the high DPC counts are related to the ssd in some way (I have a toshiba NVME, and I ACPI.sys averages around 1,3-1,7 ms). I've been back and forth with dell tech support, and they say they can't reproduce the high numbers from ACPI.sys on their 9570. It would be a big help if you could post your number here!

 

I'm having the 4K Version with Samsung 970 Pro after I replaced the hynix,
The results I have got after running 2 minutes the latencymon are -

Spoiler

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:02:36 (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: EDOLAPTOP
OS version: Windows 10 , 10.0, build: 17134 (x64)
Hardware: XPS 15 9570, Dell Inc., 02MJVY
CPU: GenuineIntel Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Logical processors: 12
Processor groups: 1
RAM: 16121 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2208 MHz
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 24241.148178
Average measured interrupt to process latency (µs): 23.092281
Highest measured interrupt to DPC latency (µs): 14483.007776
Average measured interrupt to DPC latency (µs): 12.842945

_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 229.545290
Driver with highest ISR routine execution time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation
Highest reported total ISR routine time (%): 0.013188
Driver with highest ISR total time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation
Total time spent in ISRs (%) 0.013464
ISR count (execution time <250 µs): 2336
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 117366.326993
Driver with highest DPC routine execution time: DDDriver64Dcsa.sys - DDDriver.sys, Dell Inc.
Highest reported total DPC routine time (%): 0.030194
Driver with highest DPC total execution time: DDDriver64Dcsa.sys - DDDriver.sys, Dell Inc.
Total time spent in DPCs (%) 0.083823
DPC count (execution time <250 µs): 29698
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 1699
DPC count (execution time 1000-1999 µs): 66
DPC count (execution time 2000-3999 µs): 28
DPC count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.
NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.
Process with highest pagefault count: supportassistagent.exe
Total number of hard pagefaults 4896
Hard pagefault count of hardest hit process: 1176
Number of processes hit: 35

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 6.387698
CPU 0 ISR highest execution time (µs): 229.545290
CPU 0 ISR total execution time (s): 0.251262
CPU 0 ISR count: 2254
CPU 0 DPC highest execution time (µs): 117366.326993
CPU 0 DPC total execution time (s): 1.378999
CPU 0 DPC count: 13741
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 1.080640
CPU 1 ISR highest execution time (µs): 29.0
CPU 1 ISR total execution time (s): 0.001291
CPU 1 ISR count: 82
CPU 1 DPC highest execution time (µs): 142.178442
CPU 1 DPC total execution time (s): 0.017512
CPU 1 DPC count: 909
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 0.853473
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 68.865036
CPU 2 DPC total execution time (s): 0.004312
CPU 2 DPC count: 399
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 0.838143
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 106.260870
CPU 3 DPC total execution time (s): 0.019245
CPU 3 DPC count: 1486
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 1.329749
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 917.307971
CPU 4 DPC total execution time (s): 0.077591
CPU 4 DPC count: 10084
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 1.092501
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 108.011775
CPU 5 DPC total execution time (s): 0.005922
CPU 5 DPC count: 404
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 1.223317
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 193.223732
CPU 6 DPC total execution time (s): 0.027641
CPU 6 DPC count: 1720
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 1.401256
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 102.388587
CPU 7 DPC total execution time (s): 0.003713
CPU 7 DPC count: 284
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 1.069706
CPU 8 ISR highest execution time (µs): 0.0
CPU 8 ISR total execution time (s): 0.0
CPU 8 ISR count: 0
CPU 8 DPC highest execution time (µs): 164.665761
CPU 8 DPC total execution time (s): 0.016247
CPU 8 DPC count: 996
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 1.037894
CPU 9 ISR highest execution time (µs): 0.0
CPU 9 ISR total execution time (s): 0.0
CPU 9 ISR count: 0
CPU 9 DPC highest execution time (µs): 79.207428
CPU 9 DPC total execution time (s): 0.001636
CPU 9 DPC count: 141
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 0.903894
CPU 10 ISR highest execution time (µs): 0.0
CPU 10 ISR total execution time (s): 0.0
CPU 10 ISR count: 0
CPU 10 DPC highest execution time (µs): 168.896739
CPU 10 DPC total execution time (s): 0.013644
CPU 10 DPC count: 899
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 0.893047
CPU 11 ISR highest execution time (µs): 0.0
CPU 11 ISR total execution time (s): 0.0
CPU 11 ISR count: 0
CPU 11 DPC highest execution time (µs): 105.664855
CPU 11 DPC total execution time (s): 0.005848
CPU 11 DPC count: 465
_________________________________________________________________________________________________________

 

That is totally BS, every 9570 has the high latency spikes of ACPI.sys, if they have the same Windows version. Dell support is incompetent or lying to you. I am totally sure they have no idea what youre talking about and "and they say they can't reproduce the high numbers from ACPI.sys on their 9570" is just a sentence of them saying that. They obviously didn't do any DPC tests on their own.

https://www.dell.com/community/XPS/...0-ACPI-sys/m-p/6159137/highlight/false#M16118

https://answers.microsoft.com/en-us...s/e7fa0ab7-bf94-4aff-a7b4-54570cc37f31?auth=1

https://www.reddit.com/r/Dell/comments/8rco82/xps_15_9570_dpc_latency/

I doubt 2050 will be out for the refresh of XPS in Q1/Q2 of 2019. New Intel architecture wont come out before Christmas 2019. The next chips are no new architecture.

I am totally sure, that this will be delay too because of Intel having troubles with 14nm and had to outsource PCH to TSMC. Could be that the integrated Wifi maybe first wll come in the Y CPUs or ULV first, and then wont be ready too for the next XPS refresh.

I am really annoyed of my temps btw. Mine is at 97-98°C in prime or Cinebench even with a -160mV undervolt. I guess I have to do a repaste sooner or later. The funny thing is, the fans do literally nothing. If off or full speed the temps and clock dont really change and stay at 97°c. The fan build in this laptops are totally useless. It somehow seems, the fan logic is totally stupid build that it just checks every 10 seconds or so. That results in random fan kick-ins if youre unlucky and have just in the short time window a temp of 50°C+.

Update on the c state bug after S3 sleep: Someone I talked to claims, he found out, that if he connects and disconnects a TB or USB-C device to his 9570, the bugged c state is resolved afterwards. He actually wrote the following:

"
I've done a lot of experimenting with this to see if there was some way I could still use S3 sleep and not have the C State bug. I found that whenever I have a device plugged into the Thunderbolt 3 (USB-C) port, the computer will never go into a C State greater than C2. Just for reference, the USB-C devices I've tried are Dell DA300 dock and Dell D59GG ethernet dongle. Once I removed the device, from the port, my CPU would immediately go into deeper C States. I'm not sure if this is supposed to happen or not. This is true even if my computer had a fresh reboot and had not yet been put to S3 sleep.


With that new-found knowledge, I put my computer to S3 sleep and then brought it out. I noticed that it was stuck in C2. However, if I plug in either of my adapters and unplug them, the CPU would again work with C3, C8 and C10 (and sometimes C7). So, it appears that the hardware change forces the driver (I'm guessing) to snap out of its issue. This is not a long term workaround, but it may be enough information to help someone (Intel? or Dell?) to figure out where the issue lies.
"

Can someone here with a TB or USB-C device test this maybe? Because I neither have any, no TB, no USB-c. So maybe the whole c state bug is somehow connected to TB. I tried to deactivate TB in bios after this, but it had no effect on the bug.

Update:
Ok, this is getting weird... I actually found a USB3.1 to USB-C adapter I had around, tested this theory with it with a USB 3 stick + adapter in the TB slot of the 9570 after I S3, wake up, c2 stuck bug was triggered... and the result is the following:

- the moment I stuck in the USB-C adapter, C2 got unstuck and lowest energy state now was C3.

- removed the adapter, and C8 worked again normally.

So this theory is totally correct. This issue somehow has to do with TB, or it can resolve the stuck c state somehow.

I went into bios and deactivated TB and tried to see if this may be resolved the whole issue, nope, no luck.

BUT (how can it be different...) there is a weird issue now, AGAIN. Because this workaround doesn't help 100% in this issue. Look at these two pictures:


The above is AFTER the TB adapter plug in and plug out. You see C8 is still working again... BUT, package power is still broken and around 2-3 higher as it should be of 1.3-1.5W. I noticed an abnormal C0 behavior now AFTER TB plug out, look at C0 activity on core0. I went into task manager, and there was no process, all on idle. So the CPU is still bugged after plugging out the TB adapter, just not as much as without the workaround. Seems that some kind of driver bug maybe causes abnormal high activity on core0 which results in CPU doesnt go lower anymore as C2. Task manager of Windows doesnt show any process though.

This is how it should be (after a clean Windows boot, or with modern standby wakeup):


This will be really hard to explain to Dell customer support if they even bother to listen. Because the moment you say the word S3, they will mostly go on ignore mode and tell you, that this laptop doesnt support S3, which is totally BS of course.

Anyone maybe has ideas how this thing is related with TB? Because the normal USB 3 slots wont do anything for this, just TB.

I guess my theory is, that sticking anything into the TB slot triggers an event in the XPS bios and it maybe resets somehow something with energy state with the CPU, because TB can deliver power and can be used for charging.

Update2:
Ok it seems, the abnormal activity on core0 is already triggered the moment you come out of S3, and this is mostly the entire reason, why the CPU isnt going in lower energy state anymore. Why sticking in and out a TB adapter causes it to do it again is mostly anaother bug. So a bug out of a bug, which doesnt solve the first one.

Normal state (c0 0.x% activity) => S3 => broken state (12% c0 activity on core0, which mostly leads to stuck in c2) => TB stick in/out leads to CPU power logic ignore the 12% and go lower anymore, where it shouldnt actually => the 12% c0 activity stays though the entire time, causing a package power drain.

Does anyone know, if there is a way to debug, what is really using something on the CPU? Because neither task manager nor MS Process Explorer show anything. They claim a 99% idle, where TS says, there is a 12% c0 usage on core0 happening after S3 wake up.

 

Noooooooooooooooooo :-(

https://www.guru3d.com/news-story/ice-lake-for-mainstream-delayed-to-2020.html

 

https://www.ultrabookreview.com/23071-xps-15-9570-review-follow-up-3-months-later/

my follow-up review to my original 4/5 review after 3 months

 

Hi again, thanks a lot for doing this and for posting the report.

However, I can't tell the DPC executions times of APCI.sys due to DDDriver64Dcsa.sys having the highest execution time on your system.

I am only interested in APCI.sys as all other drivers causing too high DPC can be dealt with through uninstalling and disabling dell services and apps and disabling wifi.

So, if you would be so kind as to run LatencyMon again (10 seconds should be enough) and tell me the 'highest execution time in ms" of APCI.sys in the 'drivers' tab. Thanks again!

 

Yeah, I am also pretty sure that all the 9570 has the issue and that the dell rep lied to me when she said they tested it on their own 9570. At least there hasn't been anyone online - as far as I can dig - who have come forth with decent execution times. But what do you mean by "if they have the same version of windows"? Are you suggesting that other windows versions won't have DPC issues on the same machine?

 

Looks like Dell blocked the bios downgrade from 1.4.1 to anything lower. Spent around 30 minutes trying to go back to 1.3.0 to see if the GPU limitations would be changed back to normal. Sadly I can't find a way to force it, even by doing a bios recovery from a flash drive. I don't think there is going to be anyway around this.

 

Does anyone know the actual difference between restore settings "BIOS Default" and "Factory Settings"? Thinkpad P52 is here now so I will try to find time to see if that can offer a stabilty that the XPS15 can't. All these probles are driving me crazy...

 

For anyone having problems with the TB16, there seem to be a new USB driver released (which isnt a rebranding like Dell usually do but actually a new version)

https://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverid=jcdn0

 

This one I had missed, looks interesting:

https://www.notebookcheck.net/HP-El...4K-GTX-1050-Max-Q-Laptop-Review.333328.0.html

Not to sure about those extra buttons to the right of the return key though....

 

I don't use S3 sleep, however, sometimes I experience the stuck in C2 bug anyway.
This morning happened and when I unplugged the usbc-hdmi dongle, it got unstuck. The moment I plugged the dongle back in, the C2-struck reappeared.

I don't have much time to investigate this now. However, this C2 bug might not be directly related to S3 sleep but by some misconfiguration of the USB/Thunderbolt controller.

 

Agreed - with recent press leaks, another long Intel delay looks baked-in at this point.

Even thought the 9550-9560-9570 chassis is getting long in the tooth, I can't see Dell reworking XPS for Coffee Lake-R. And I not convinced nVidia's new GPUs will be a revolutionary upgrade for regular laptop users.

With current thermal and power limitations of the XPS platform, I'm not sure how compelling the 9580 will be.

 

Well, they might switch from a 2 heatpipes design to a vapor chamber design (a la balde 15), which seems to be a better solution.
NVidia also went for vapor chamber design for their 20xx founder's edition cards.

 

On the 9550 & 9560, DPC tests were terrible then after many months of ownership, my LatencyMon results improved significantly. Running basically stock with a clean Win10 Pro install. And no tweaks. So some changes in BIOS, Windows, drivers were made but I have no clue who was guilty.

For sure nVidia drivers are a real issue so full removal with DDU and minimal reinstall.

Look at this image to see excellent results on 9550 (fully uninstalled nvidia, disabled c-states in BIOS, runing ThrottleStop)

​

I had a lot of issues with c-states on the 9550 & 9560. I don't use sleep so don't think that was related. There are several posts in the "ThrottleStop Guide" that helped me get the deeper c-states unlocked (basically replaced IDE ATA/ATAPI driver with Intel RST 15.8.x.xxxx, although that broke 6 months later and is still a bit wonky)

http://forum.notebookreview.com/threads/the-throttlestop-guide.531329/page-690#post-10628950​

 

Maybe stealing the vapor chamber design could allow better cooling of the CPU and GPU. A full vrm redesign is limited by real estate and fact that CPU remains the same; but a modern vapor chamber design might let Dell run the vrm more aggressively before throttling.

On the other hand, I suspect the fans and radiators will need to be upgraded to dissipate the additional capacity of a modern vapor chamber. The intake and exhaust ports are rather blocked so core design is a limiting factor also.

 

Excellent article Eason. Short and right to the point.

Didn't know you moved to HK!

 

Read my post again... it saied C2-C3 is the lowest state when you have anything connected to TB ("I found that whenever I have a device plugged into the Thunderbolt 3 (USB-C) port, the computer will never go into a C State greater than C2."). That has nothing to do with the stuck issue after S3, because there is a condition race or regression happening after S3, you can see that with the 12% C0 activity on core0. And this prevents the CPU going lower I guess, so it is mostly not a bug with the CPU, but something causing a stuck 12% cpu activity. I tried to deactivate TB in bios, which didnt help.

Tests have to be done under same conditions (Bios, drivers, Windows version). I saw reddit posts, that someone claimed the latency was worse with 1803 for example than older Windows 10 builds.

---

Does anyone have btw issues, that sometimes the XPS doesnt boot and show a yellow yellow white blink on the front LED? Googling about it says the code means "CPU failure" but I found other people having this issue too on their XPS (Reddit)... a workaround was suggested to reset the RTC I tried, which didnt help and the problem still happens sometimes. I love this laptop.

 

@Eason I solved the sound crackling from the headphone jack by removing/disabling MaxAudioPro. Dell said a driver update is on the way. This should not be related to DPC issues.

 

Nvidia increased TDP for the 20xx cards. But the notebooks will continue having same graphics cards TDP. Of course Nvidia needed to implement better cooling for the desktop cards. Not the same as this will happen for notebooks. Vapor chambers for notebooks won’t help so much if the notebook chassis being slimmer with following thinner fans and heatsink grills.

 

And this is under load, if so what kind? Especially Wifi seems to be a real killer, do a performance test like SpeedTest and whole h-ll brakes lose.

 

This is on idle. The LatencyMon test should be run on idle for troubleshooting purposes.

 

Thank you! Keep an eye out, I may be going full-time tech media in December

 

Thank you - I don't consider DPC times of 381 µs to be 'excellent', but it is definitely a lot better than today's times of the 9570, and likely just fine. This gives me hope for the future.

 

Yes, I've experienced this once, a couple of days ago. It took the machine longer than usual to boot (like 3 minutes or so) and the blink sequence you mention did appear and continued until I shut down the machine. After that, I haven't had it come back. Made me worried, though.

 

Just to be clear, is there any solution for the fact that the CPU idles at extremely high wattages until the device is put into standby and awakened?

 

Well, if you want to see if background services etc are causing problems, thats a good way to start. But if DPC problems occur when you starting using the computer, that is still a problem (although perhaps you can't do too much about it). I just want to be able to run a compile in VIsual Studio without Spotify stuttering and perhaps some light browsing while waiting. If I recall correctly, you had more "professional needs" regarding DPC?

 

Is it just me that has noticed increased fan behaviour after upgrading to the latest BIOS? Seems to be running constantly now...

 

No, having the exact same problems. My i9 is howering around 4 Ghz in idle even with "Optimized" selected in Dell Power manager and Balanced power plan in Windows.

On that topic, how does the Dell Power Manager work? Does not seem like it creates an unique powerplan and then change values on that? Does it just change the currently active one?