Any way to programmatically detect/monitor cpu load or usage in MT4? - page 2

 
1005phillip:

My desire to be able to do this stems from the need to coordinate auto-optimizers that could be running concurrently with other terminals.

Ideally I'd be able to have a cpu load monitor that could prevent an auto-optimizer from launching if the cpu load was above some user-defined threshold.

Why not compare current auto-optimizers in progress vs. cores available. Don't launch if none available.

:loop wait
set termcount=-1& rem Don't count real chart terminal
for /f "usebackq" in (`tasklist^|find "terminal"`) set/a termcount+=1
if (%termcount% GEQ %NUMBER_OF_PROCESSORS%) (
   call sleep 60
   goto wait
)
Untested
 
WHRoeder:

Why not compare current auto-optimizers in progress vs. cores available. Don't launch if none available.

Untested
I apologize for my ignorance, I don't understand what I am look at in your post. Is that a code snippet I need to incorporate into a DLL or somesuch?

EADeveloper:

Hi,

if you have experience wiht writting a dll, you will find lot in google .. and call the dll from your ea.

example for calling CPU Usage: http://www.codeproject.com/KB/system/processescpuusage.aspx

Thanks for the suggestion and link but unfortunately I have no experience in writing dll's


jjc:

Hmmm. There are all sorts of potential problems with this, such as a calculation taking longer than normal because it indirectly involves some disk I/O at the same time as e.g. your anti-virus deciding that it would be a good idea to re-scan the whole disk. More generally, there are all sorts of occasional background processes which can cause a spike in the execution time of one in a series of identical tasks - but without having future implications.

You haven't provided much detail about the setup, but a simpler effective solution might be some sort of semaphore which prevents more than one (or two, or three) instances of MT4 running this auto-optimization at the same time.

If you are going to use GetTickCount() then you may need to watch for the fact that it must wrap round every 24 days, because it's a number of milliseconds being represented in a signed (31-bit) integer.


Right now I have no problems managing CPU and core resource utilization from within a single terminal instance. I can have Terminal Instance "A" set to auto-optimize 15 different currency pairs, 4 at a time (quad-core cpu) and it will iterate through all 15 currency pairs without generating resource contention.

The problem I have is how to have Terminal "A" manage auto-optimizations of 15 currency pairs while having Terminal "B" and Terminal "C" attempting the same. Terminal "A" is ignorant to the existance of Terminal "B", and vice versa. Terminal "A" is only aware of the auto-optimizers launched by Terminal "A" to perform backtesting for the purposes of the EA's in Terminal "A".

Maybe what I need is a general repository location...a common file folder like "C:\MT4_Core_Availability\" which all Terminals check for a file flag as a way of just assuming resources are available or not available. I'd need to construct some fail-over logic to handle fileopen/write collisions though.
 
1005phillip:
I apologize for my ignorance, I don't understand what I am look at in your post. Is that a code snippet I need to incorporate into a DLL or somesuch?

WHRoeder is proposing a batch (.bat) file which will not start more copies of terminal.exe than there are logical processors reported by the operating system.

1005phillip:
Thanks for the suggestion and link but unfortunately I have no experience in writing dll's

EADeveloper was citing some .NET code which would be painfully hard to translate for use with MT4. You'd not only have to write a DLL, but more specifically you'd have write a DLL bridge between MT4 and the .NET code. If you're going to have to write a DLL, there are easier ways of getting the processor usage without interfacing with .NET code.

 
jjc:

WHRoeder is proposing a batch (.bat) file which will not start more copies of terminal.exe than there are logical processors reported by the operating system.

EADeveloper was citing some .NET code which would be painfully hard to translate for use with MT4. You'd not only have to write a DLL, but more specifically you'd have write a DLL bridge between MT4 and the .NET code. If you're going to have to write a DLL, there are easier ways of getting the processor usage without interfacing with .NET code.




Ah, I completely understand now! Mostly. :P

The trouble I am going to have in relying on the batch file suggestion is that I can't safely assume that the number of instances of terminal.exe in taskmanager corresponds to a specific number of background instances (virtually no load) versus the number of instances that are going to be running strategy tester (and fully loaded).

Hence the need to either have a way to ascertain CPU utilization directly or a way to account for the number of terminal instances in a manner that can distinguish the cpu load they are likely commanding. My current implementation does the latter, but it is only robust provided it assumes no other terminals are active which could be spawning auto-optimizers in their own right.

My hobbled together system for dealing with this is that I block out timeslots for my terminals by broker and account. Terminal "A" can only launch auto-optimizers between midnight and 2 am, Terminal "B" can only launch auto-optimizers from 3am and 5am. Etc.

It works but it is not very elegant and is not very efficient in terms of maximizing the number of terminals I can have per rig.

 
jjc:

WHRoeder is proposing a batch (.bat) file which will not start more copies of terminal.exe than there are logical processors reported by the operating system.

EADeveloper was citing some .NET code which would be painfully hard to translate for use with MT4. You'd not only have to write a DLL, but more specifically you'd have write a DLL bridge between MT4 and the .NET code. If you're going to have to write a DLL, there are easier ways of getting the processor usage without interfacing with .NET code.



Yes, you are true, are some easiery ways, but depending on the stuff you can use.

Like a wrote .. some example

Reason: