Would it be possible to add a function TradeTime_s which returns Hours + Minutes + SECONDS additional to the already existing TradeTime which only returns Hours + Minutes?
I do need this for one of my strategies but don´t want to use currenttime_s since the computer-clock could run slightly different than the trade-time of the datafeed-provider. Hence a TradeTime_s function would be more reliable for my strategy. But such a function currently only exists for minutes, not seconds.
Thank you.
Function request: TradeTime_s additional to TradeTime
-
- Posts: 100
- Joined: 17 Jul 2009
- Location: Germany
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: Function request: TradeTime_s additional to TradeTime
It's a while ago that this feature request is made, it's almost 2012, the new internet speed record is recently broken (now 186 gigabits per second (Gbps)), trading latency is already measured in nanoseconds, so perhaps we can get the TradeTime including seconds. Any updates on this?Would it be possible to add a function TradeTime_s which returns Hours + Minutes + SECONDS additional to the already existing TradeTime which only returns Hours + Minutes?
Regards,
Josh
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
Re:
Session time always begin/end in minutes, there is no need for a seconds level keyword.Yes, plus......
SessionStartTime_s
SessionEndTime_s
Believe it or not, this line does not work in some cases:
If time >= SessionStartTime(1,2)... until 1 minute after the session starts.
Thanks!
If you insist on such a value,
you can do the following:
Code: Select all
var:
SessionStartTime_s( SessionStartTime(1,2)*100 ),
SessionEndTime_s( SessionEndTime(1,2)*100 );
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: Function request: TradeTime_s additional to TradeTime
If you agree, please vote for this feature request:Would it be possible to add a function TradeTime_s which returns Hours + Minutes + SECONDS additional to the already existing TradeTime which only returns Hours + Minutes?
Thanks!
Josh
- PatrickSocal
- Posts: 58
- Joined: 27 Apr 2013
- Location: San Diego, CA
- Has thanked: 23 times
- Been thanked: 30 times
Re: Function request: TradeTime_s additional to TradeTime
Hi guys,
q_Time_s gives you second resolution, and q_Time_Dt gives you millisecond resolution. In both cases, it takes the time from the datafeed, not from the bar or from the computer clock.
So a nice application is measuring data lag... you can write:
And unless I'm mistaken it will compute the clock offset (in seconds) between your computer and the datafeed (but only during real-time trading).
q_Time_s gives you second resolution, and q_Time_Dt gives you millisecond resolution. In both cases, it takes the time from the datafeed, not from the bar or from the computer clock.
So a nice application is measuring data lag... you can write:
Code: Select all
if GetAppInfo(aiRealTimeCalc) = 1 AND LastBarOnChart then begin
ClockDiffSec = (computerdatetime - q_time_dt) * 86400;
end;
Re: Function request: TradeTime_s additional to TradeTime
Have you any statistics how much latency for several exchanges exist with MC. Further it would be interesting how much latency to fight with MC in terms of last trade data (from exchg) delivery - signal generation - sending order - receiving trade/order confirmation in MC ... 1+second latency from the last trade on exchange to broker order confirmation would be my first bet. I'm not trading through MC, that's why I'm asking. Thank you for delivering this solution.
Regards.
Ben
Regards.
Ben
- PatrickSocal
- Posts: 58
- Joined: 27 Apr 2013
- Location: San Diego, CA
- Has thanked: 23 times
- Been thanked: 30 times
Re: Function request: TradeTime_s additional to TradeTime
Hi Ben,
Latency is an interesting and tricky question. Your best guess:
We connect to the exchanges through Rithmic, which hosts their order gateways near to the Globex matching engines in Aurora. Our RT ping latency to Rithmic is 1-2 ms. Rithmic claims to offer "tick to trade" latency of 250us for their Diamond API (which pre-screens trades for pre-trade risk), but MC does not use this API (and I don't know of any moderately priced platform that does). I have not gotten a tick-to-trade latency quote for Rithmic's standard API, nor for any of CQG's API's. But I have received estimates that pre-trade risk approvals add ~10ms to latency via CQG, and I'm guessing it's similar for Rithmic.
I also know that it's the norm to see trades appear on our charts multiple seconds after the entry signal has fired. I don't know what the source of that latency is, and we are just beginning to analyze it. I'm hoping it's post-execution back-office type latency, and not pre-trade latency. But I can also say we've seen painful slippage on some "fast" types of strategies that make them untradeable in MultiCharts. Some day we can have a DMA platform like the big boys
Just for fun, allow me to change the topic a little... here is an overnight plot of clock offset between the Rithmic data timestamp on ESZ4 and my computer's clock, using the code I posted yesterday:
Note how the clock drift changes... it can be temperature dependent, CPU/software load dependent, or dependent on something else. Interestingly, the sharp change from positive slope to negative slope occurred when I changed the bar spacing in MC. My computer clock was incrementing slightly faster than the data clock before I did that (thus the positive slope), and now it's incrementing slightly slower (thus the negative slope). That tells me there are software interactions to be aware of. In a past project, we measured latency at a Colo facility where there were radio-synced high-precision clocks that we queried directly, instead of using Windows system time. Then we correlated specific events so we could estimate the data transit times. You have to do stuff like that if you want to be really accurate. But my goals here are more modest... I just want to detect when there is a system failure so I can get out of bed and fix it...
Latency is an interesting and tricky question. Your best guess:
Seems consistent with what I've seen, but it's hard to know. Here are some of the things I do know:Further it would be interesting how much latency to fight with MC in terms of last trade data (from exchg) delivery - signal generation - sending order - receiving trade/order confirmation in MC ... 1+second latency from the last trade on exchange to broker order confirmation would be my first bet.
We connect to the exchanges through Rithmic, which hosts their order gateways near to the Globex matching engines in Aurora. Our RT ping latency to Rithmic is 1-2 ms. Rithmic claims to offer "tick to trade" latency of 250us for their Diamond API (which pre-screens trades for pre-trade risk), but MC does not use this API (and I don't know of any moderately priced platform that does). I have not gotten a tick-to-trade latency quote for Rithmic's standard API, nor for any of CQG's API's. But I have received estimates that pre-trade risk approvals add ~10ms to latency via CQG, and I'm guessing it's similar for Rithmic.
I also know that it's the norm to see trades appear on our charts multiple seconds after the entry signal has fired. I don't know what the source of that latency is, and we are just beginning to analyze it. I'm hoping it's post-execution back-office type latency, and not pre-trade latency. But I can also say we've seen painful slippage on some "fast" types of strategies that make them untradeable in MultiCharts. Some day we can have a DMA platform like the big boys
Just for fun, allow me to change the topic a little... here is an overnight plot of clock offset between the Rithmic data timestamp on ESZ4 and my computer's clock, using the code I posted yesterday:
Note how the clock drift changes... it can be temperature dependent, CPU/software load dependent, or dependent on something else. Interestingly, the sharp change from positive slope to negative slope occurred when I changed the bar spacing in MC. My computer clock was incrementing slightly faster than the data clock before I did that (thus the positive slope), and now it's incrementing slightly slower (thus the negative slope). That tells me there are software interactions to be aware of. In a past project, we measured latency at a Colo facility where there were radio-synced high-precision clocks that we queried directly, instead of using Windows system time. Then we correlated specific events so we could estimate the data transit times. You have to do stuff like that if you want to be really accurate. But my goals here are more modest... I just want to detect when there is a system failure so I can get out of bed and fix it...
- Attachments
-
- Rithmic_ESZ4_Clock_Offset.png
- (44.04 KiB) Downloaded 832 times