Detection of MC mode
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
In other threads I have indicated I set a GV to 1 if running in replay mode and leave it at zero for normal real time mode or offline mode. I had to change any script that I want to mimic running live (2 of them so far) such that they picked up the lastbaronchart time as the current time. I also has to change both of these to execute some code if BarStatus = 2 rather than the normal test. Each script is unique this way. It depends on the script. Some do not need these changes of course.
That's exactly how I've been doing it for a long while. I also use it to sound an alarm if during on-line mode (flagged by receiving an update tick) the study (actually my own app communicating via a dll stub) fails to receive subsequent update ticks within a specified time to warn me of a possible break in the connection for the data feed.I also has to change both of these to execute some code if BarStatus = 2 rather than the normal test. Each script is unique this way. It depends on the script. Some do not need these changes of course.
Even so it would nicer if MC has a built-in feature to detect the various modes.
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
A more general capability that would permit a good data feed alert and that has been discussed somewhat elsewhere is simply timer operation. If the indicator gets a recalculation every X milliseconds, you can simply make note of how long it's been since you had a new trade tick, and if the data feed isn't giving you any new trade ticks for Y seconds, take an action as appropriate.
Yes the previously discussed timer feature would be a very useful feature for several reasons. However, I doubt I will see it in MC any time soon, which is why I developed my own method. In fact I may do everything outside of MC and use MC just for collecting and feeding the data to my dll's, and sending instructions back to place orders and draw objects and indicators. My code also runs about 3-4 times faster than EL code so that's another benefit. I'm seriously thinking of doing this for all my studies as I don't use any of the built-in indicators except occasionally for testing ideas.A more general capability that would permit a good data feed alert and that has been discussed somewhat elsewhere is simply timer operation. If the indicator gets a recalculation every X milliseconds, you can simply make note of how long it's been since you had a new trade tick, and if the data feed isn't giving you any new trade ticks for Y seconds, take an action as appropriate.
I would try to detect the divergence in time flow between ComputerTime and the (Date & Time of the current bar). The time difference when online will be consistent in the liquid market, subject to internet & data feed providers, and any bottlenecks in between.
If time difference is greater than (2 x AveragePingTimeToExchange) +/- Time ZoneOffset) then start the Watch dog timer. Reset watchdog every time the time difference falls within allowed limits. IF watchdog timer times out, switch into trouble mode ('mode 1'), latch the alarm. My guesstimate is that watchdog should not be set to less than 100ms (if on the same continent with the Exchange), and 500ms (if exchange is on the different continent). Unless in the Exchange's backyard on a T1.
This method will detect all three modes:
- 'mode 1' /data feed trouble
- 'mode 2' /playback mode
- 'mode 3' /offline mode (switched into automatically after 'mode 1' is acknowledged)
My 'imaginary' system will always start-up in 'mode 3' and ask for permission before going live. May be it's a good idea to collect some historical divergence data in the system...
any ideas?
If time difference is greater than (2 x AveragePingTimeToExchange) +/- Time ZoneOffset) then start the Watch dog timer. Reset watchdog every time the time difference falls within allowed limits. IF watchdog timer times out, switch into trouble mode ('mode 1'), latch the alarm. My guesstimate is that watchdog should not be set to less than 100ms (if on the same continent with the Exchange), and 500ms (if exchange is on the different continent). Unless in the Exchange's backyard on a T1.
This method will detect all three modes:
- 'mode 1' /data feed trouble
- 'mode 2' /playback mode
- 'mode 3' /offline mode (switched into automatically after 'mode 1' is acknowledged)
My 'imaginary' system will always start-up in 'mode 3' and ask for permission before going live. May be it's a good idea to collect some historical divergence data in the system...
any ideas?
Last edited by geizer on 28 Mar 2010, edited 1 time in total.
That's pretty much what I do already. I plot the "lag time" to see how it all behaves then work out a statistically average to compensate when the market goes very quiet. Of course I take into account the session start and stop times, and treat out of session times as "off-line", which may or may not be good depending on what one is trying to achieve, but usually it's OK.I would try to detect the divergence in time flow between ComputerTime and the (Date & Time of the current bar). The time difference when online will be consistent in the liquid market, subject to internet & data feed providers, and any bottlenecks in between.
The only major difference is I do all this outside of MC so if the market goes dead I don't have to rely on an update tick to trigger an alert. My standalone app will do it instead after it has decided an update tick should have arrived.
Oh, and yes I do have a general watcher app that start ups every time I log on to the PC, which makes sure the main app (and other apps that I desire to be active) is up and running! If not it sets of an alarm every so many minutes, which I can kill. However, I don't have a watcher for the watcher