NexusFi: Find Your Edge


Home Menu

 





MultiCharts lag time?


Discussion in MultiCharts

Updated
      Top Posters
    1. looks_one bobbakerr with 63 posts (24 thanks)
    2. looks_two Big Mike with 19 posts (19 thanks)
    3. looks_3 Jura with 11 posts (8 thanks)
    4. looks_4 Bimi with 10 posts (7 thanks)
      Best Posters
    1. looks_one bretter with 4 thanks per post
    2. looks_two RM99 with 2.3 thanks per post
    3. looks_3 Big Mike with 1 thanks per post
    4. looks_4 bobbakerr with 0.4 thanks per post
    1. trending_up 57,176 views
    2. thumb_up 144 thanks given
    3. group 23 followers
    1. forum 171 posts
    2. attach_file 2 attachments




 
Search this Thread

MultiCharts lag time?

  #71 (permalink)
 
bobbakerr's Avatar
 bobbakerr 
Riverdale, Idaho, USA
 
Experience: Intermediate
Platform: Optimus Futures + MultiCharts + TradeStation
Broker: Optimus Futures, Rithmic Data, TradeStation
Trading: CL, ES
Posts: 115 since Aug 2010
Thanks Given: 241
Thanks Received: 51

I'm waiting a little while longer, bomberone1. I really would like to see what MultiCharts can do here.

Started this thread Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Trade idea based off three indicators.
Traders Hideout
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
Better Renko Gaps
The Elite Circle
NexusFi Journal Challenge - May 2024
Feedback and Announcements
Cheap historycal L1 data for stocks
Stocks and ETFs
 
  #72 (permalink)
 JackR 
Washington, DC
 
Experience: Intermediate
Platform: Multicharts
Broker: InteractiveBrokers/IB
Trading: CL\EUR
Posts: 15 since Jan 2011
Thanks Given: 10
Thanks Received: 8

Caveat - I am a discretionary trader so what follows may be worthless:

I'm not familiar with the internal working of Multicharts and perhaps the detailed flow of the back-test engine is explained in the Help file but I couldn't find it.

So - Let's assume Multicharts runs back-testing serially, that is, it processes the data received from disk, halts the data, builds a bar or not, runs your "black-box" process, resumes retrieving data from the disk, and repeats until an order is generated.

Further assume I'm running on a slow machine and it takes Multcharts (MC) a full minute to process whatever I do, but the decision to buy or sell is based on the close being at the high of the three minute bar generated by MC. I'm making the assumption that when back-testing, MC serially processes the on-disk "tick" data, produces a 3 minute bar, stops the data stream, runs through the my holy grail process, and makes a buy "at-the-market" decision. So a buy decision exists. Then the MC back-test engine allows the next stored tick(s) to be obtained from the historic back-test file, builds a new 3 minute bar, and then buys on the first available tick which is the open of the newly-built three minute bar. So I always buy on the first tick after processing is complete. There is no latency between the signal to buy and the buy.

In the real world the decision is made some time after the "decision" bar has been generated, no matter how fast the machine or how elegant the code. I don't care how quickly or slowly MC runs, the execution of the buy in real time will always be some finite, but variable time after the open of the next 3 minute bar, because the close-of-bar to open-of-next-bar is just one trade away and in a fast market that is milliseconds. As others have pointed out there is a great deal of latency involved starting with the exchange data source to the the broker, to your computer, the computer process, back to your broker and to the exchange order processing engine. Thus, back-testing results will always be different than any real time results because no matter what I do I cannot consistently get the opening tick of the next bar, but I always get the opening tick in back-testing. (An end-of-day trading signal to buy-on-the open is an exception to this deficiency).

So, in your back-testing code, you must include a mechanism to delay your buy or sell signal some (variable) period of time to more accurately simulate your system's results. You'd then disable the delay when running real time against a broker's live simulator or live account.

Obviously, when dealing with the futures market, limit orders outside the market would be placed in a queue, further complicating back-testing.

Jack

Reply With Quote
  #73 (permalink)
 
bobbakerr's Avatar
 bobbakerr 
Riverdale, Idaho, USA
 
Experience: Intermediate
Platform: Optimus Futures + MultiCharts + TradeStation
Broker: Optimus Futures, Rithmic Data, TradeStation
Trading: CL, ES
Posts: 115 since Aug 2010
Thanks Given: 241
Thanks Received: 51


Thanks for your comments, Jack. You're basically agreeing with what Khalaad said in Post#58. And you're both right.

But I still want the basic problem of different backtesting results with the SAME code, one period of time being done 'live', and then the same period of time done historically, with the same code merely being re-compiled, to be fixed. The results from each should agree.

This is a MultiCharts (/TradeStation) problem -- not mine. I don't promote Bar Magnification, etc. MultiCharts does. This problem needs to be fixed so that their platforms are indeed credible.

I realize I'm coming down hard on MultiCharts. I am doing so only to try to force them to see this problem. I'm sure they already know it. Perhaps it's not correctable. But I would think that if data is received tick by tick, then that same data can be sent tick by tick so that programs can work in an exactly sequential manner. That's all I want. And if programs work in an exactly sequential manner, then I think that the historical backtesting results should be exactly equal to the 'live' testing results. (Note: I'm NOT saying Live Trading results.)

If the two periods can then exactly agree, then 'workarounds' for Real Live Trading can then be programmed into the code. This is what I'm after.

Started this thread Reply With Quote
  #74 (permalink)
 JackR 
Washington, DC
 
Experience: Intermediate
Platform: Multicharts
Broker: InteractiveBrokers/IB
Trading: CL\EUR
Posts: 15 since Jan 2011
Thanks Given: 10
Thanks Received: 8


bobbakerr View Post
But I still want the basic problem of different backtesting results with the SAME code, one period of time being done 'live', and then the same period of time done historically, with the same code merely being re-compiled, to be fixed. The results from each should agree.

Bob:
I think I understand what you want (above). What does "live" mean to you? How would Multicharts(MC) "know" the delay caused by your connection latency, where your order would be in a queue, and whether you could be filled based on the bid/offer size at the time of your orders arrival at the exchange.

As I posted, I don't know how the MC back-testing engine works. However, and once again I probably don't know what I'm saying - MC needs three processes (threads?) running simultaneously, one that reads the time-stamped tick data stored on your disk and feeds it to another thread running your "holy grail" process. Thus the signal produced by your "system" would be traded against a constantly running data stream, making it more realistic. Further, the back-testing engine would need a "latency" input feature so that after your grail processed the data, the third thread, the "broker/exchange execution" process would have its execution delayed by the time it would take for your order to be transmitted to your broker, processed by your broker, and then forwarded to the exchange. That latency factor would be unique (and probably jitter a bit) for each user and broker. For a reversal system, MC would need to have a user adjustable order acknowledged/completed latency factor available so that your system could not reverse "illegally."

Once MC worked out that process, they'd need to scale everything appropriately, so that back-testing could run at a high speed, rather than in the actual elapsed time of the stored tick stream.

Jack

Reply With Quote
  #75 (permalink)
 
bobbakerr's Avatar
 bobbakerr 
Riverdale, Idaho, USA
 
Experience: Intermediate
Platform: Optimus Futures + MultiCharts + TradeStation
Broker: Optimus Futures, Rithmic Data, TradeStation
Trading: CL, ES
Posts: 115 since Aug 2010
Thanks Given: 241
Thanks Received: 51


JackR View Post
Bob:
I think I understand what you want (above). What does "live" mean to you? How would Multicharts(MC) "know" the delay caused by your connection latency, where your order would be in a queue, and whether you could be filled based on the bid/offer size at the time of your orders arrival at the exchange...


Thanks for your input, Jack. But MultiCharts doesn't have to simulate anything "live". Just take the data, tick by tick, and send it to me, tick by tick. With that, * I * can do the experimenting to convert the data to Real Time Live conditions. That operation is a big guess. The tick-by-tick stuff is real. And that is NOT what I am getting. The different results that I get between the so-called 'live' quotes I receive when watching the program work in a simulated mode, and then closing and reloading (or re-compiling) the same program with supposedly the same data is what tells me that I'm NOT getting tick-by-tick data as it occurs throughout the day and for the historical backtesting.

I guess I'm having a difficult time making myself clear on this. I can't seem to put it in a more understandable way (yet). Maybe tomorrow I'll be able to. I'm off to bed.

Started this thread Reply With Quote
  #76 (permalink)
 
Jura's Avatar
 Jura   is a Vendor
 
Posts: 775 since Apr 2010
Thanks Given: 2,352
Thanks Received: 690


bobbakerr View Post
I'm waiting a little while longer, bomberone1. I really would like to see what MultiCharts can do here.

I understand that you don't want to share your strategy and I feel for your backtesting problems, I can't imagine how frustrating these have to be. That being said, can you perhaps post an 'cleaned out' example of your strategy (with order logic) and Data1 and Data2 references?

If SPTrading's suggestion is right, and there is some lookahead bias, we can help you find a way around this, and I also suppose that that also helps to get your point stronger across to MultiCharts. This would also open the possibility to further investigate this issue, because, if you experience wildly different backtest results when changing a semicolon and have a big gap between backtest results and real-time results, this is a hugely serious issue, which I think also the community should know about, and should be put forth as concrete as possible, so that MultiCharts can fix this as soon as possible.

I'm not saying you're wrong in your criticism, but the discussion in this topic is getting somewhat abstract with our assumptions about MultiCharts' backtest assumptions (also see page 199 and beyond of the MultiCharts manual for their take on this) - not that that shouldn't be discussed, but that won't allow for much concrete help or problem analysis.

Just thinking aloud.

Regards,

Reply With Quote
Thanked by:
  #77 (permalink)
 tradersheldon 
Western Maryland
 
Experience: Intermediate
Platform: Multicharts
Broker: Vision Financial (Direct)/ CQG, Rithmic
Trading: Gold, Euro, ES
Posts: 39 since Sep 2010
Thanks Given: 20
Thanks Received: 50

One possible reason for differences between live trading results and historical results (or just reloading the data in the same day) is that your tick data is no longer accurate or kept in exact sequential order. Open up the quotemanager and examine (edit data) for yesterdays trading. There should be a tickid for every tick within one second and the number should be in consecutive order. CME only timestamps the tick data down to the second and NOT millisecond or microsecond. So data providers assign a number to every tick that happens in the same second, that way it is kept in exact sequence. Examine a time period that is off hours and activity is slow. The tickid should be in exact sequential order with no skips in numbers (starts over every new second). Now examine the first second of market open action (8:30 exchange time), there will probably be skips in the tick id, but the main thing is that they are in sequential order. Do a free trial to DTN IQFeed. and compare your tick data to theirs. I know their data is recorded almost perfectly and then kept in the exact sequence. If your stored data is much different then what they are showing, then you have one huge problem for backtesting.
Sheldon

Reply With Quote
Thanked by:
  #78 (permalink)
 
MultiCharts's Avatar
 MultiCharts 
Columbus, Ohio, US
 
Experience: Intermediate
Platform: MultiCharts
Broker: Multiple/Multiple
Trading: ES, EUR/USD
Posts: 168 since Oct 2010
Thanks Given: 74
Thanks Received: 172


bobbakerr View Post
I'm waiting a little while longer, bomberone1. I really would like to see what MultiCharts can do here.

I'll try to analyze this topic over the weekend and respond appropriately. Things have been very busy around here.

MultiCharts - Raising the Trading Standard.
Please send me a private message if you have any further questions about MultiCharts
Follow me on Twitter Reply With Quote
Thanked by:
  #79 (permalink)
 
bobbakerr's Avatar
 bobbakerr 
Riverdale, Idaho, USA
 
Experience: Intermediate
Platform: Optimus Futures + MultiCharts + TradeStation
Broker: Optimus Futures, Rithmic Data, TradeStation
Trading: CL, ES
Posts: 115 since Aug 2010
Thanks Given: 241
Thanks Received: 51


Jura View Post
I understand that you don't want to share your strategy and I feel for your backtesting problems, I can't imagine how frustrating these have to be. That being said, can you perhaps post an 'cleaned out' example of your strategy (with order logic) and Data1 and Data2 references?

If SPTrading's suggestion is right, and there is some lookahead bias, we can help you find a way around this, and I also suppose that that also helps to get your point stronger across to MultiCharts. This would also open the possibility to further investigate this issue, because, if you experience wildly different backtest results when changing a semicolon and have a big gap between backtest results and real-time results, this is a hugely serious issue, which I think also the community should know about, and should be put forth as concrete as possible, so that MultiCharts can fix this as soon as possible.

I'm not saying you're wrong in your criticism, but the discussion in this topic is getting somewhat abstract with our assumptions about MultiCharts' backtest assumptions (also see page 199 and beyond of the MultiCharts manual for their take on this) - not that that shouldn't be discussed, but that won't allow for much concrete help or problem analysis.

Just thinking aloud.

Regards,


OK, Jura. Your post convinced me to post the basics of my code. I'll change a few things, but keep the logic the same. It's really very simple. It has 2 data series (and 2 graphs). Both graphs use 2-cent range bars. (It also works well with 40-second bars and 12-Tick bars [for CL here] The upper graph is the current month contract of CL or ES. The lower graph is a contract that is farther out. The signals are derived from the lower graph and all trading is done off of the upper graph, where the Bid/Ask spread is minimal.

I've gone through 2 expiration dates with this program. I change the contracts a set number of days before the actual expiration day. MultiCharts is also set for Bar Magnifier On with 1 Tick as the minimum move. IntraBar Order Generation is also set to On.

Here's an example of the code:

 
Code
inputs:  worse(.02);
variables:  IntraBarPersist BuySig(0),IntraBarPersist SSSig(0),
            IntraBarPersist Min(9999),IntraBarPersist Max(0),
            IntraBarPersist LongEntry(0),IntraBarPersist SSEntry(9999);

Condition1=Time<1500;  // Mountain Time

If Time>1511 and Time<1600 then begin
  BuySig=0; SSSig=0; Min=9999; Max=0;
end;



If H of data2>L[5] of data2 and C of data2>C[5] of data2 and H of data2>L of   data2 and V of data2>0 then begin  // *** This line has been changed drastically to 'protect' the actual signal
   BuySig=1; LongEntry=Close+worse;
end;
If L of data2<H[5] of data2 and C of data2<C[5] of data2 and L of data2<H of data2 and V of data2>0 then begin  // *** This line has been changed drastically to 'protect' the actual signal
   SSSig=-1; SSEntry=Close-worse;
end;

If MarketPosition<>1 and BuySig=1 then begin
  If Condition1=True then
     Buy next bar at LongEntry{InsideAsk} Limit;
end;
If MarketPosition<>-1 and SSSig=-1 then begin
  If Condition1=True then
     SellShort next bar at SSEntry{InsideBid} Limit;
end;

{The Following is a 'Safeguard' for if not Bot or SS due to 2 bars in SAME TIME:}
If MarketPosition=-1 and C of data2<Min then begin
   Min=C of data2; Max=0;
end;
If MarketPosition=1 and C of data2>Max then begin
   Max=C of data2; Min=9999;
end;
If MarketPosition=-1 and C of data2>=Min+.08 then begin
   Buy next bar at LongEntry{InsideAsk} Limit;
end;
If MarketPosition=1 and C of data2<=Max-.08 then begin 
   SellShort next bar at SSEntry{InsideBid} Limit;
end;

If MarketPosition=1 then LongEntry=0; BuySig=0; Max=0;
If MarketPosition=-1 then SSEntry=9999; SSSig=0; Min=9999;


If MarketPosition>=1 and Time>1510 then Sell next bar at market;
If MarketPosition<=-1 and Time>1510 then BuyToCover next bar at market;
As of 9:40 AM Mountain Time, the CL results since Midnight is + 8718 Net on 367 R.T.'s. The ES results is + 2660 Net on 19 R.T.'s. I have not reloaded, reset, or re-compiled anything.

Started this thread Reply With Quote
Thanked by:
  #80 (permalink)
 
bobbakerr's Avatar
 bobbakerr 
Riverdale, Idaho, USA
 
Experience: Intermediate
Platform: Optimus Futures + MultiCharts + TradeStation
Broker: Optimus Futures, Rithmic Data, TradeStation
Trading: CL, ES
Posts: 115 since Aug 2010
Thanks Given: 241
Thanks Received: 51



tradersheldon View Post
One possible reason for differences between live trading results and historical results (or just reloading the data in the same day) is that your tick data is no longer accurate or kept in exact sequential order. Open up the quotemanager and examine (edit data) for yesterdays trading. There should be a tickid for every tick within one second and the number should be in consecutive order. CME only timestamps the tick data down to the second and NOT millisecond or microsecond. So data providers assign a number to every tick that happens in the same second, that way it is kept in exact sequence. Examine a time period that is off hours and activity is slow. The tickid should be in exact sequential order with no skips in numbers (starts over every new second). Now examine the first second of market open action (8:30 exchange time), there will probably be skips in the tick id, but the main thing is that they are in sequential order. Do a free trial to DTN IQFeed. and compare your tick data to theirs. I know their data is recorded almost perfectly and then kept in the exact sequence. If your stored data is much different then what they are showing, then you have one huge problem for backtesting.
Sheldon


Thanks, Sheldon. I'll do this when I get some more time. I didn't even know this stuff existed.

Started this thread Reply With Quote




Last Updated on April 4, 2012


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts