2

Intro

Our team has an application that performed fine with Windows 10, but has now started suffering from compute throttling of some kind in Windows 11 when it is not shown on the desktop.

In broad terms, the architecture of the solution is that this application communicates over USB (through our own proprietary DLL) with a hardware device (also our own design) to fascilitate serial and CAN/J1939 communication from a PC.

Symptoms

The specific symptoms we observe is that the rate at which the function gets called to pop messages from the DLL queue is reduced to about a third of the rate we are used to be adequate for keeping up. The approximate rates we're talking about is 1000 function calls per second get reduced to about 300 function calls per second. This happens when the application is not visible on the desktop.

When the application is minimized, the "throttling" occurs as well as when the application itself is maximized, but then another maximized "over" it.

The specific test we did was:

  1. Run the application and observe ~1000 function calls per second
  2. Minimize the application and observe ~300 function calls per second (and the queue not keeping up)
  3. Maximize the application and still observe ~1000 function calls per second
  4. Run calc.exe "on top" of our application's window while focus remains on Calculator (doing some simple maths) - we still observe ~1000 function calls per second
  5. Maximize Calculator to completely cover our application's window - observe ~300 function calls per second

The same tests reveal no change in the rate of function calls when it is done on Windows 10.

Tried This...

We have tried to optimize the infrastructure around the function call itself and reduced sleep(1) calls to sleep(0) calls. We have also tried Windows' Gaming Mode as well as High Performance power modes.

The expectation was that these may allow the application not to fall behind on the message queue when other applications are using all the Desktop real-estate or when the application gets minimized. This is the normal way of using our application, and was adequate for many years.

In reality, none of those changes prevented the reduction in function call rate which in turn prevents us from keeping up with the communication on the bus. When the application then comes to the foreground, the queue first has to be cleared before real time messages are being processed and presented.

Questions

  1. We thought this was caused by Windows' Power Throttling feature that was introduced in versions of Windows 8, but the fact that we don't have the problem in Windows 10 says otherwise. What is the Windows 11 feature called that could cause this type of behaviour?
  2. Could this feature be controlled in some way for an application with our architecture and requirements? Are there manifest settings or specific Windows API methods that could be used to address our problem?

Other Technical Info

  • The application is developed in Embarcadero C++ Builder XE7
  • The DLL is developed in Codegear C++ Builder RAD Studio 2007
  • We use the RP1210a/b standard for CAN communication
  • We use FTDI's Driver Package Version 2.12.18
  • The version of Windows 10 on which the test did not show the reduction in function call rate was 21H2 build 19044.2846
  • The version of Windows 11 on which the test showed the reduction of function call rate was 21H2 build 22000.1817

Windows 11 About

Windows 10 About

Spastika
  • 364
  • 3
  • 10
  • 1
    Just a shot in the dark, are you sure that the only difference is the windows version and not also the computer hardware on which windows is running? (CPU, motherboard, power features, USB controller, USB drivers, everything) – Mike Nakis May 02 '23 at 07:59
  • All OSs will de-prioritise a backgrounded app to give the priority to what the user normally wants - better performance for foreground apps. That is sensible thing to do. Mobile phones even outright suspend background apps to save battery. If you want stable performance of background service then implement it as service not part of GUI app. – Öö Tiib May 02 '23 at 08:08
  • Thanks @MikeNakis, good point - I guess I could have included it. The WIndows 10 PC is an old Lenovo T560 with an i7-6600U and 16 GB of RAM vs. the Windows 11 PC is a Lenovo E15 with an i7-1255U also with 16 GB of RAM. I'll include the Windows **About** screenshots for completeness. – Spastika May 02 '23 at 08:09
  • What part of the question involves C++?? – Red.Wave May 02 '23 at 08:13
  • @ÖöTiib, that deprioritization is understandable, but is not something that bothered us before. If a service is used, the dequeuing from the service for the sake of presentation to the user will also suffer from a similar problem when the application that needs the messages in "real time" is in the foreground again and needs to cath up. – Spastika May 02 '23 at 08:13
  • You can try [configuring the foreground boost to favor services](https://answers.microsoft.com/en-us/windows/forum/all/disabling-under-prioritization-of-background-tasks/c4749a47-76f0-4c5c-bb30-b9d319f610fc). Or, as the CPU has 2 performance (core) and 8 efficiency (atom) cores, explore processor affinity settings to pin your application to one of the performance cores. – teapot418 May 02 '23 at 08:18
  • Have you looked at search -> "appearance and performance" -> Performance Options -> Advanced -> Processor scheduling -> Adjust for best performance of: (o) Programs (o) Background services ? Do you have the same setting on both machines? – Mike Nakis May 02 '23 at 08:23
  • 1
    @Red.Wave, you're right - nothing really significant related to C++, apart from the fact that the applications and DLL was developed in C++. Sorry. I'll remove the tag. – Spastika May 02 '23 at 08:23
  • @teapot418, that is worth a try - we'll give it a go – Spastika May 02 '23 at 08:25
  • 1
    Related? https://superuser.com/q/1763751 – Captain Giraffe May 02 '23 at 09:08
  • We've tried the "Adjust for best performance of: **Background Services**" and it had no effect. – Spastika May 02 '23 at 13:12
  • @CaptainGiraffe, that was the key - thank you very much. It also allows us to configure our application(s) to have Power Throttling disabled! – Spastika May 02 '23 at 13:44
  • Cool, I was expecting it to be a swing and a miss. =) – Captain Giraffe May 02 '23 at 20:03
  • 1
    @MikeNakis was on the money with his very first comment that he called a "shot in the dark" too. – Spastika May 03 '23 at 09:21

1 Answers1

1

The cause of this behaviour is indeed Windows' Power Throttling which allows Windows to unload non-foreground tasks to so-called e-cores only.

The following command (with Administrator privileges) disables the behaviour for a specific application:
powercfg /powerthrottling disable /path "c:\myprogram\myprogram.exe"

For further detail, see https://superuser.com/a/1764829/386174

Spastika
  • 364
  • 3
  • 10