My approach. The core is the engine. - page 147
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
In general, the problem is almost solved.
I'm confused by the fact that, let's say 5 EAs will be transmitting the full amount of work packages if the engine is running with a sixth. The other five should be banned from transmitting work information for the time being. Let them just "listen to the airwaves".
I agree. This makes sense.
So they will work normally, but they will not write messages to the resource. Only to a copy of the parameter kernel. And when connected, will write the parameter kernel to the resource and the Engine will load it. Once connected, the Expert Advisor will start writing messages for the Engine to the message resource.
The question is about the connection.
The engine exposes a small string address to all EAs. The kernel in the EA with the same recognition address is recalled and the standard engine-advisor operation starts automatically. When the engine switches to another EA, the engine switches the kernel of the EA it was working with to the address waiting state, just like the other EAs at that moment. At this point, all of the EAs are disconnected and the engine is waiting for the other address of the EA the engine needs.
The kernel of the new EA responds and enters the state of standard operation. The next time the engine continues to send the finish line and the state of waiting is not changed. In addition to the standard exchange, the Expert Advisor has to analyze a flow to check if the end of work line appears in it. At the beginning of exchange packets there must be a string, indicating to whom a packet is addressed from the engine. That kernel receives control packet and starts to send packets of its state with specified frequency.
The others wait for them to be addressed through a unique identification string for each EA. When switching, the engine sends the current EA an end-of-life string. The EA stops sending anything and enters the state of recognising its own recognition string which is at the same time the start of the standard work of exchange with the engine.
The question is about the connection.
The engine exposes a small string address to all EAs. The kernel in the EA with the same recognition address is recalled and the standard engine-advisor operation starts automatically. When the engine switches to another EA, the engine switches the kernel of the EA it was working with to the address waiting state, just like the other EAs at that moment. At this point, all of the EAs are disconnected and the engine is waiting for the other address of the EA the engine needs.
The kernel of the new EA responds and enters the state of standard operation. The next time the engine continues to send the finish line and the state of waiting is not changed. In addition to the standard exchange, the Expert Advisor has to analyze a flow to check if the end of work line appears in it. At the beginning of exchange packets there must be a string, indicating to whom a packet is addressed from the engine. That kernel receives control packet and starts to send packets of its state with specified frequency.
The others wait for them to be addressed through a unique identification string for each EA. When switching, the engine sends the current EA an end-of-life string. The EA stops sending anything and enters the state of recognising its own recognition string which is at the same time the start of the standard work of exchange with the engine.
The resources are somewhat simpler. You don't need an address, just a resource name. You have a more complicated model. It's simpler.
The core is simply an array of values. Each Expert Advisor will write in it the values of parameters of its GUI elements. When necessary, EAs will save a copy of the kernel parameters to the resource and the engine will read it and redraw the GUI.
In principle, this is a simple task, but there are many little nuances. For example, messages about starting and stopping communication with the EA. We just need to think of the format.
By the way, I have managed to speed up the communication and decrease the slowness. However, I have not yet figured out the reason. It occurs during redrawing, but the strange thing is that the redrawing itself is not braking. But redrawing when communicating with the resource is slowing down. The reason for this is not yet clear.
Put in some kind of time-cost monitoring. So you can see where it's slowing down. And how to get around it.
Maybe I made it a little complicated. I don't know how it's organized inside your engine. I was just using logic.
Put in some kind of time-cost monitoring. So you can see where it's slowing down. And how to get around it.
Maybe I made it a little complicated. I don't know how it's organized inside your engine. I was just using logic.
Logic got you closer to the point, and in general, you understand correctly.
Today I will try to get to the bottom of the causes of braking. The following is clear - redrawing itself is not slowing down. Writing and reading of the resource is not slow either. But together we get slowness.
There is monitoring, which operation takes how long? They should be performed sequentially. The Expert Advisor performs them, capturing data and sending it to the engine at a frequency of, say, 30 ms. When a thread is sent to the engine, is it ready to receive? Or what does it do?
Checking everything now.
The engine at 30ms reads the message resource from the EA, and the EA, at the same frequency, reads the message resource from the engine. On the same frequency, they both write their messages to each other (if there is anything to write). All this does not cause any slowdowns. Also, redrawing itself, does not cause braking.
However, the slowdown appears if there is a combination of redrawing and writing/reading the resource on the Engine side. Cause for this is not yet clear. Figuring it out.
Checking everything now.
The engine at 30ms reads the message resource from the EA, and the EA, at the same frequency, reads the message resource from the engine. On the same frequency, they both write their messages to each other (if there is anything to write). All this does not cause any slowdowns. Also, redrawing itself, does not cause braking.
However, the slowdown appears if there is a combination of redrawing and writing/reading the resource on the Engine side. Cause for this is not yet clear. Checking it out.
Maybe a mismatch: EA and engine, 1 - both send to each other, 2 - both receive, their OnTimer cycles are not synchronized. Waiting for the moment of random synchronization to work normally. Could this be the reason?