OS/2, eCS & ArcaOS - Technical > Hardware
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: ---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
--- End code ---
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):
--- Quote ---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.
--- End quote ---
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,
--- Quote from: Jochen Schäfer on April 30, 2026, 09:14:28 am ---@Doug: How do you turn off processors?
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
Go to full version