|
|
Post by David Martin on Jul 31, 2020 16:12:18 GMT 1
It was mentioned to me that my program was using way more CPU under 64 bit than it did under 32 bit ... this is what I have found out.
My program is a FoxPro/DOS 2.5b app. It is running using the extended version of the FoxPro runtime.
I am using the March 2020 version of vDOS.
Under Windows 10 32 bit (using NTVDM) it is well behaved and settles down to 0% CPU in just a few seconds after you perform any action.
Under Windows 10 64 bit (using vDOS) it will stay at 30+% usage for well over a minute ... I have timed it at 80+ seconds on multiple occasions.
Once it settles down it also runs at basicly 0% CPU.
These are the same programs, using the same data files, running on the same basic hardware (i5 3470, 4 or 8 GB RAM, SSD), Windows 10 1909 on both machines ...
This is not using the FoxPro development environment but a compiled program running under the runtime.
I assume it has to do with detecting idle ... or not.
|
|
|
|
Post by Jos on Jul 31, 2020 19:03:52 GMT 1
If a program doesn’t signal it’s actually idle, idle detection is mostly based on the absence of user interaction or file access for a given time (number of CPU instructions). With keypresses and mouse actions this time should be around 6 seconds, for file access some 60 seconds. A low-end real CPU will result in more time, a high-end one in less.
This delay before going idle is to ensure a program isn’t doing some time-consuming calculations, vDos going to idle premature, the calculations taking forever.
Since the program quickly consumed less CPU time with NTVDM, I guess FoxProX will first establish if it’s running in Windows, and only if so signal Windows to go idle on the program. I’ll have a look at that.
Jos
|
|
|
|
Post by Jos on Jul 31, 2020 20:48:37 GMT 1
FoxPro indeed inquires if it is running under Windows/NTVDM, vDos reports just DOS.
It then seemingly doesn’t call INT 2F/1680 - MS Windows, DPMI, various - RELEASE CURRENT VIRTUAL MACHINE TIME-SLICE (supported by vDos). Doesn’t call functions to wait for keypresses, but checks one is eventually available. And doesn’t fall back itself to call DOS INT 28 - DOS IDLE INTERRUPT.
So you just have to live with vDos maxing at 100% of its designated core for some time. The alternative to go idle sooner is no practical option.
Jos
|
|
|
|
Post by Jos on Aug 1, 2020 21:07:07 GMT 1
I added an algorithm to account for programs not signaling being idle, while checking for keypresses way above an ongoing average/expectation.
That should for instance drop FoxProX CPU usage quickly.
Jos
|
|
|
|
Post by David Martin on Aug 1, 2020 21:41:53 GMT 1
That sounds promising! I will send you an email...
|
|
|
|
Post by sanjeev76 on Aug 25, 2020 16:49:35 GMT 1
CTRL+V ALSO NOT WORKING IN FOXPRO HOW TO ENABLE FIELD COPY/PASTE
|
|
|
|
Post by Jos on Aug 25, 2020 16:56:17 GMT 1
Ctrl+V would be disabled by a "CTRL+V = OFF" line in config.txt.
Put a rem in front, as in the original config.txt file.
Jos
|
|
|
|
Post by herman on Sept 14, 2020 22:39:33 GMT 1
With me in dBase 5 are the same things regarding high CPU usage.
When I have started my application and it is standing still in a selection menu,
then my cpu usage is around 33% constantly in vDos 01-03-2020
Do I understand that this will be improved in an upcoming version?
Herman
|
|
|
|
Post by Jos on Sept 15, 2020 7:05:54 GMT 1
The next version will trap frequent and continuous keyboard inquiries and then drop CPU usage sooner.
Jos
|
|
|
|
Post by ad on Mar 17, 2021 15:52:08 GMT 1
I added an algorithm to account for programs not signaling being idle, while checking for keypresses way above an ongoing average/expectation. That should for instance drop FoxProX CPU usage quickly. Jos The next version will trap frequent and continuous keyboard inquiries and then drop CPU usage sooner. Jos Hi, Do we have an estimated date for when the new program version will be available? We are looking to continue using some old Sage Line 100 instances via vDos but when opened vDos will just max a CPU core for 2 minutes through until the vDos unregistered pop up message appears, at which point CPU usage drops to very little (same behaviour on Server 2012 R2 VM and Server 2016 VM quick tests). Testing from a Win7 x64 machine vDos will max a CPU core for around 30 seconds or so then drop to very little without the vDos unregistered pop up message having appeared yet. The worry is without the vDos unregistered pop up message the program might just fully utilise a CPU core continuously on a Windows Server VM where we would need to use the program, I'm hoping these improvements mentioned will dramatically improve the situation. I'm putting together a Server 2019 VM for some real end user testing using vDos, I doubt the Server 2019 VM will behave any differently than the brief tests done from existing Server 2012 R2 VM and Server 2016 VM but if we're going to setup a new server for users to use vDos from it may as well be the newer version (unless there is a known reason why we should use an earlier version of Windows Server?) The vDos website still only has the 2020.03.01 version listed for download which was well before these improvements were discussed so will not be included. Thanks |
|
|
|
Post by Jos on Mar 17, 2021 16:26:35 GMT 1
vDos being registered or not doesn’t change anything to the vDos idle scheme. The unregistered pop up message just eventually appears when vDos is actually going to idle, so it doesn’t disturb any critical processes.
vDos 2020.03.01 going to idle sooner is mostly given by faster hardware/connections.
The next vDos version is planned for May 1st.
Jos
|
|
|
|
Post by David Martin on Mar 18, 2021 16:16:30 GMT 1
The one you sent me back on 08/01/2020 is working great with FoxPro 2.5b (X) and the idle stuff. It allows the running of multiple instances without bogging down the system. I have used a combination of vDOS and TSPlus to setup a couple of clients with multiuser remote access systems.
|
|
