ACPI daemon, PowerMan, WinSendMsg

[Eugene Gorbunoff]

Question: did anybody verified this in ArcaOS 5.1.2 ? Does the behaviour change?

TITLE: WinSendMsg performance degradation in a multitasking environment?

When using WinSendMsg from one thread to another, sporadic random delays occurs. Steps To Reproduce Start any (?) application (I try Firefox, Thunderbird, PM123, PM Backup Manager) and leave it running in the background. Then start msgtest.exe attached to this issues. msgtest.exe sends a series of messages from one thread to a window created on another thread and measures the resulting time.

In my computer (I7-3930K), if ACPI is disabled (PSD=ACPI.PSD is removed from CONFIG.SYS) the test is stable completed in 0-1 seconds. If ACPI is active, test varies from 3 to 10 seconds (I have seen 17 seconds!). Adding /NOHLT improves result up to 2-3 seconds. But it is still slower than without using ACPI. Additional Information This is not a synthetic problem, I have seen it for a long time while testing Zippy with large archives. Without /NOHLT, the degradation becomes visible to the naked eye.

Related:
* Stopping CPUs -- https://forum.os2world.com/index.php?topic=3849.0  // 2025/02

[Dariusz Piatkowski]

Hello Eugene,

I am always very interested in system responsiveness...so I gave your test a quick "go":

2
5
5
5
2

Not sure if this is indicative of a problem or not, and I haven't tested with the '/NOHLT' parameter yet, however I will say the following:

1) ACPI power management is completely disabled on my system, both in terms of BIOS as well as our OS/2 implementation of the power daemon, my software revision is:

Code: [Select]

The version of ACPI.PSD that is installed is 3.23.18
The system is operating in Symmetric mode (Mode 2)
The kernel is 14.203_SMP

2) A while back I noticed that screen responses became slow, what I mean by that is the following:
- I use lSwitcher here, both taskbar and the popup, normally the popup is very quick, nearly instant, and yet at other times it feels like it takes a couple of seconds to just respond to the ALT-TAB keystroke

- further on, I have two physical displays here (SNAP) and use the XWP virtual desktop as well, plenty of real-estate but that does require me to shift around various windows...and again, similar to the lSwitcher experience, I have encountered this slow-down here as well

Previously I simply looked at all my settings to see if I had inadvertently changed something. I looked at various OS component elements as well, but wasn't able to identify the root cause...but maybe what you point out is it???

EDIT
====
'/NOHLT' test completed, man, am I a happy camper now or what!!! I am back to the instantenous response I was used to for such a long time before (presumably) our ACPI PSD must have switched to default use of the HLT instruction.

All the msgtest runs are coming back now with either a 1 or 2, but more imporantly each XWP virtual desktop switch is immediate, as is the lSwitcher popup.

So here is my conclusion: that /NOHLT switch tells our ACPI driver to never (?) send a HLT instruction to any secondary CPU/COREs, subsequently the hardware is up and running at all times and there are no delays in bringing a CPU out of any C or P states. There are some complexities at play here when you attempt to balance these things out, some great reading can be found:

https://metebalci.com/blog/a-minimum-complete-tutorial-of-cpu-power-management-c-states-and-p-states/

https://man.netbsd.org/acpicpu.4

https://grokipedia.com/page/HLT_%28x86_instruction%29

Now, one more thing I'm going to try is to go back to no '/NOHLT' option but despite the ACPI power daemon being disabled on my system, I am going to set the 'PreferredMode=None', whereas previously I had this commented out. The purpose in this is to understand whether our daemon is perhaps throttling the CPUs despite it being told that it is NOT enabled?

The documentation does in fact state (see 'Power Manager Settings' in the INF file):

The Power Manager supports three types of power management:

1.Processor Throttle control
2.Processor Performance State control
3.Halting some of the CPUs.

The Power Manager will automatically select which one of types 1 or 2 to use in addition to type 3 (see below) based on what is reported by ACPI. In order for the types 1 or 2 to function, one or both of these methods must by defined by ACPI and must specify a method implemented in the PSD. Processor Throttle control is generic and is implemented in the PSD so this method is preferred by the Power Manger if available. Processor Performance State control is processor specific and is implemented in the PSD if ACPI specifies a standard address space. If ACPI specifies a custom address space, then Processor Performance State control will not work. Custom address space handlers may be added to the PSD for certain processors in the future. Power management types 1 and 2 can be influenced or disabled by the PreferredMode setting.   

If the system has more than one CPU, then the Power Manager will also use type 3 power management. Power management type 3 enables and disables secondary CPUs depending on system load and temperature. The primary CPU (CPU 0) is never disabled. The secondary CPUs consume a lot of power and disabling them is very effective at reducing power consumption and heat. Power management type 3 is done in addition to power management types 1 or 2, if enabled. So, for example, both type 1 and type 3 could be operational at the same time.   

[Doug Clark]

Eugene,

Is your system "pure" UEFI boot, or do you have legacy support "turned on?"

1) I have also noticed situations where the system seems to pause - almost like it is catching its breath - before resuming as normal.  For example when watching a video on VLC the video will just stop, for up to 15 - 20 seconds - and then resume operating.

2) I have issues with certain Win16 / Win32s programs causing my system to lock up.  For some apps it happens almost immediately, others will work OK for a long time before my system falls into a tar pit.  Other apps never experience this issue.

I accidentally discovered the "solution" to #2  is to turn off all the additional processors.  Once they have been turned off they can be turned back on immediately and that will almost always fix the Win16/Win32s app issues.  I only have to turn them off once after a boot and then I am good to go for the rest of the session.

However even after turning off and then turning back on the processors I still see issue #1 - the occasional pause.

I should note that I am also running SNAP and two monitors - however I have seen issue #2 on non-SNAP systems.  And I have a Lenovo T530 laptop running AOS 5.1 that does not experience either issue - it is running without legacy support enabled.

I mention #2  because I suspect it is ACPI - while you suspect #1 is also ACPI related

[Jochen Schäfer]

@Doug: How do you turn off processors?

[Dariusz Piatkowski]

Hello Jochen,

@Doug: How do you turn off processors?

There are a couple of options:

1) OS/2 has a SMP Monitor utility (MPCPUMON.EXE) that is a GUI interface (see screenshot below) where under the 'Status' selection in the main menu you will get a pop-up window listing all the CPU/COREs, double click will flip from ON-line to OFF-line, and vice versa

2) At command line there are various utilities, I use Yuri Dario's SETPROC (see attached b/c it's small enough) which you can probably find at Hobbes, etc.
- this one is very convenient: 'setproc 8 off' shuts off the 8th core on my system, 'setproc 8 on' turns it back on

[Lars]

It would be interesting to manipulate these config.sys parameters:

MAXWAIT=3 (note: time value given in seconds)
TIMESLICE=1,2 (note: time values given in milliseconds)

and see if that has an (strong) impact when ACPI is active. It shouldn't matter (that much) if ACPI is not active.

[Doug Clark]

@jochem,

You can turn off the additional processors by

1) modifying your CONFIG.SYS to add /MAXCPU=1 on the APCI.PSD line  as so

PSD=AXPI.PSD  /MAXCPU=1

and rebooting.  You will run with only one CPU until you modify CONFIG.SYS to remove the /MAXPU=1 and reboot

or

2) switch off the additional processors using either CPU Monitor  - located in your Utilities folder, or with SETPROC.EXE, which Dariusz attached.

If you are using with SETPROC or the CPU Monitor the trick is keeping the processors off.  If you don't disable the ACPI power manager before you use CPU Monitor or SETPROC when the ACPI  will immediately turn the processors back on.

To prevent that from happening you have to disable the power manager feature in ACPI.  Doing that is explained in the ACPI documentation located in C:\SYS\DOC\ACPI
The short version is you edit (or create) the file ACPID.CFG which is located in your %ETC% directory - on my machine it is in C:\MPTN\ETC

The simplest version of ACPID.CFG  file that I have found that will work to turn off the power manager is

-----------------------------------------------
[PowerMan]
Enable = 0
-----------------------------------------------

Once you change the file ACPID.CFG you have to wait a bit to allow ACPI a chance to read the file and implement the change.  I have found that 15 - 30 seconds is usually sufficient.  Dariusz is the one that actually posted this a while back.

When you want to switch the processors back on you can simply delete the ACPID.CFG file that you created, if you created one, or return the file ACPID.CFG to the state is was before you modified it.

If ACPID.CFG does not exist ACPI will use default values for its settings, which is usually what you want.  You only need the ACPID.CFG file if you want to change the default settings used by ACPI, or if you want to turn off the power manager so you can turn off the CPUs.

I believe Dave and Lars have customized their ACPI settings, and Lars suggested an interesting experiment with TIMESLICE and MAXWAIT settings in CONFIG.SYS.  For me using the default settings works pretty well - except when I need to turn off processors.

I also believe that when Lars says "when ACPI is active" what he means is when the power manager feature of ACPI is enabled.  The power manager is the thing that automatically turns off and turns on processors based on demand.  The point of automatically turning off processors is to conserve power/battery, and to manage thermals.

I should also note that a new version of ACPI was released with AOS v 5.1.1 and I believe part of the changes are to improve the switching on/off of processors.  I have not installed that version yet, so all my observations are for AOS v 5.1 and earlier.

Lastly, I am working on a WPS WPProgram object that can be used to turn on/off processors, and I would love some people to volunteer to test it in a week or two.

[Dariusz Piatkowski]

Doug!!!

...Lastly, I am working on a WPS WPProgram object that can be used to turn on/off processors, and I would love some people to volunteer to test it in a week or two.

Ohhh...if I think it is what I hope it is (LOL) that would put you in the Olympus-God categeory in my books (umm, so that's I suppose just my $0.02 CAD), and I say this because:

...my SMP configuration has a nasty habit of soft-freezing my system when certain apps are started...as best as I can tell I've narrowed it down to VisualRexx or Dr.Rexx written apps (sort of reverse engineering here, so YMMV).

Case in point, the ANPM app, yup, soft-lock, the PMFMergeNX app, yup soft-lock BUT only when you open the FOC and try to select files. The strange part is that with some apps this is NOT consistent, sometimes it happens, sometimes it does not.

My solution: I create a 'SMP Safe' object to start these apps where I call SETPROC first and shut off all but the remaining single CPU, that works...gets the app up and running, gets me past the 'danger zone', at which point in time I turn all the remaining CPUs ON and live happily ever after.

By now I have a routine I follow, all setups are in place, etc, etc...but yeah, it still feels like a kludge at best.

Therefore, sing me up boss...I'm your #1 Tester!!!

[Remy]

====[/b]
'/NOHLT' test completed, man, am I a happy camper now or what!!! I am back to the instantenous response I was used to for such a long time before (presumably) our ACPI PSD must have switched to default use of the HLT instruction.

I tried the '/NOHLT' flag and I'm happy too for the same raison. Nice and well found !

[Doug Clark]

@Dariusz,

Your issues sound very much like my issues, although I have only seen this in WIN-OS/2 apps so far.

But your solution and mine are almost exactly the same: my WPProgram object will turn off all additional processors while the program is running and turn them back on when the program ends, or it will turn them off and turn them back on before the program starts.  I have found that "toggling off and on" to fix my issues with Win-OS/2 apps, although some Win16 installers really need to have only one processor running during the install.

[Dariusz Piatkowski]

Hey Doug!

...Your issues sound very much like my issues, although I have only seen this in WIN-OS/2 apps so far.

But your solution and mine are almost exactly the same: my WPProgram object will turn off all additional processors while the program is running and turn them back on when the program ends, or it will turn them off and turn them back on before the program starts.  I have found that "toggling off and on" to fix my issues with Win-OS/2 apps, although some Win16 installers really need to have only one processor running during the install.

Listen, this is why I got so giddy over what you suggested!

In fact, on my TO-DO list was a program wrapper that would allow me to set certain options (such as what you highlighted above) so that I can deal with this in a more systemic way. Basically: replacement for that REXX script I'm using today...but creating a WPS Object /Template is far beyond my mere mortal skills!!!

So look, not that you are looking for 'feature requests', but if I may, can I suggest the following:

1) processor affinity
Not sure if this is possible, I have not found any reference to such a function, but I'm wondering if some of the ails we see could be addressed by forcing processor affinity? i.e., making the code execute on a single CPU/CORE only, while at the same time allowing all the other CPU/COREs to run as-is?

2) timing controls
What you mention above, that being: start with 1 CPU/CORE, then following the start-up transition to true SMP, could you provide for a user-adjustable setting that allows you to define the durtion of time for which that single CPU/CORE configuration must be mainted before it transitions to using all others?

You know, I thought that using MARKEXE and setting the MP-unsafe bit would work, as that is precisely what it's supposed to do (force the code to run on a single CPU/CORE), but this has not worked for me on the programs that always cause me the problem, so I suspect there is something else going on here.

[Lars]

Hey Doug!

So look, not that you are looking for 'feature requests', but if I may, can I suggest the following:

1) processor affinity
Not sure if this is possible, I have not found any reference to such a function, but I'm wondering if some of the ails we see could be addressed by forcing processor affinity? i.e., making the code execute on a single CPU/CORE only, while at the same time allowing all the other CPU/COREs to run as-is?

There is: DosSetThreadAffinity. However, it does not help in this situation: It allows you to set Affinity for the currently executing thread. Therefore, it cannot be invoked before a process is started. It has to be used by the application itself.

[Alfredo Fernández Díaz]

[...]
Lastly, I am working on a WPS WPProgram object that can be used to turn on/off processors, and I would love some people to volunteer to test it in a week or two.

I was about to start a thread asking about having individual applications run on one CPU or core while SMP is enabled system-wide, so count me in.

[Dariusz Piatkowski]

Thank you Lars!

There is: DosSetThreadAffinity. However, it does not help in this situation: It allows you to set Affinity for the currently executing thread. Therefore, it cannot be invoked before a process is started. It has to be used by the application itself.

I thought I saw something with "...affinity..." in the API name before but in my searches I couldn't find it, but indeed this is what I had in mind.

FYI - details for this API sit in the 'Programming Guide and Reference Addendum' INF book included in the Toolkit.

[Dariusz Piatkowski]

...
EDIT
====
'/NOHLT' test completed, man, am I a happy camper now or what!!! I am back to the instantenous response I was used to for such a long time before (presumably) our ACPI PSD must have switched to default use of the HLT instruction.

All the msgtest runs are coming back now with either a 1 or 2, but more imporantly each XWP virtual desktop switch is immediate, as is the lSwitcher popup.

So here is my conclusion: that /NOHLT switch tells our ACPI driver to never (?) send a HLT instruction to any secondary CPU/COREs, subsequently the hardware is up and running at all times and there are no delays in bringing a CPU out of any C or P states.
...
Now, one more thing I'm going to try is to go back to no '/NOHLT' option but despite the ACPI power daemon being disabled on my system, I am going to set the 'PreferredMode=None', whereas previously I had this commented out. The purpose in this is to understand whether our daemon is perhaps throttling the CPUs despite it being told that it is NOT enabled?...

So given all these different options at play I figured I needed to document what I was testing as I saw some conflicting results.

Take a look at the attached test results matrix: the benefits of using '/NOHLT' are hard to dispute, at least on my system here.

Now, couple of comments re: a few suggestions made so far in this thread:

1) TIMESLICE

It would be interesting to manipulate these config.sys parameters:

MAXWAIT=3 (note: time value given in seconds)
TIMESLICE=1,2 (note: time values given in milliseconds)

and see if that has an (strong) impact when ACPI is active. It shouldn't matter (that much) if ACPI is not active.

This is (or appear to be) not possible: the lowest timeslice is 32ms, and the only option we have is to override the default dynamic timeslice computation that the kernel does with a user supplied MIN & MAX values. But doing so does not allow you to re-define the lower bounds of the MIN value, i.e., the shortest it can be is 32 ms.

2) PM_ASYNC_FOCUS_CHANGE
The default setting is 2000ms, which essentially means if an app is detected to not relinquish the control, the system will take over. Looking further into this setting however seems to indicate that you can in fact override this with your own preferred value.

Subsequently, given the multiple CPU/CORE availability on MY system I had lowered this to 640 ms, rationale being: that gives an app some 20 standard 32 ms TIMESLICE cycles to work on stuff before I deem it to have "overstayed it's welcome":

SET PM_ASYNC_FOCUS_CHANGE=640

Does that work?

Well, system boots, I can't tell that much has changed, albeit in these testing cycles I went through a bunch of reboots and very little actual runtime in-between.

OK, so how did I test this:

1) My FF shows heavy CPU spikes (see attachment) in certain cases, that being:
- posting a message on our very own forum here
- visiting one of my car hobby sites, such as this one here => https://www.forabodiesonly.com/mopar/

I am curious if anyone else seems the same bahaviour? I believe the most likely cause is JS and/or some specific embedded page elements. Overall it doesn't seem to impact me as there appear to be plenty of spare CPU-cycles to deal with this.

I focsed in on this because Eugene's supplied msgtest always showed delays when this was the case, while normally no delays otherwise.

2) The attached test results matrix shows a mix of both FF and TB usage (applications both open and FF showing the above described CPU spikes)