Login Page - Create Account

Support Board


Date/Time: Thu, 16 May 2024 08:13:34 +0000



Post From: IB FX

[2016-01-05 16:45:04]
User754985 - Posts: 109
1. Noticed that default min.move/tick for IB cash/fx instruments is still 0.5 pips. While IB has moved to a precision of 0.1pips since end Nov. Would be great to correct.
- 1. You can change this yourself here:
http://www.sierrachart.com/index.php?page=doc/doc_GlobalSymbolSettings.php

Yes, I can. But since this is now an explicit,selectable option in IB's TWS/Gateway, it would definitely make sense to reflect it correctly in SC as well. Forgetting to uncheck "download settings from server" would overwrite settings incorrectly, causing all sorts of mismatches, etc

2. SC-integrated forex feed seems to be the "most retail" version of FXCM's (spreads appr. 1.5-2pips on eurusd), quite different from the feed published on their web site and described as relevant for their "standard"-level accounts. This makes it unusable as a primary/back up data feed to trade from with IB for execution. - OK

So, would you change to the correct fxcm feed?
You plan for a full FXCM data and trading integration based on FIX on your servers from Feb. What feed will this service have?

3. How does IB's "download 5-sec historical bars" feature technically work? Specifically (assuming IB is the datafeed), -- 3. You really need to read the documentation about this here:
http://www.sierrachart.com/index.php?page=doc/InteractiveBrokers.php#TrueRealTimeData

And experiment with it.

When setting "Record True Real-time bars" to TRUE, the "5-sec" bars come with a 20-sec delay, subsequently delaying order submission on bar close. Makes them really not usable in RT.
There is another option - "Download 5-sec historical intraday data" - but I could not find any reference to how it works in the documentation. How does it work and Why is it "not recommended"? I have tried to set it on/off but did not notice any change.

Overall, my issue is as follows: I backtested my system on IB's data (1-min historical bars), but found that RT bars are different and produce different trading results. 3 solutions came to mind: 1)use another datafeed (correct feed from fxcm? :-() or 2)build bars from 5-sec true RT bars (20sec delay :-( ) or 3) reload last x bars of data with correct IB's "historical" 1min bars..

IS such reloading possible programmatically?
Your advice is greatly appreciated!

4. When does SC "closes" a time-based bar (e.g. 1min)?
Using sc.UpdateAlways=1 does not "close" the bar and so to work will require Autoloop=0 and identifying bar close by time. Correct?

6. When reversing positions automatically I can see that the orders are split into 2 parts (exit and new entry) - contrary to what's written in the documentation.
I am referring to: http://www.sierrachart.com/index.php?page=doc/doc_AutoTradeManagment.php#SupportReversals
and specifically to: "An example of SupportReversals is as follows: The current Trade Position quantity is +3 (long Position of quantity 3), there is a Sell Entry order action with a quantity of 1, the Auto Trade Management system will send a Sell order with a quantity that will create a resulting Position of -1. This will be a quantity of 4."

This does not seem to work. Splitting order into 2 parts results in higher commission (at least).

10. Timestamps I can see in the Trade Service log are typically showing :
Order 2015-12-28 09:31:00.000 Auto-trade: AUD.JPY-CASH-IDEALPRO 1 Min #1 | Trading CrossOver Example | Sell Entry | Flatten order during reverse | Last: 87.452003 8718 Market 50000 Sell Order Sent DU257241 Close 50000
Order 2015-12-28 09:31:00.001 Auto-trade: AUD.JPY-CASH-IDEALPRO 1 Min #1 | Trading CrossOver Example | SellEntry | Last: 87.452003 8719 Market 50000 Sell Order Sent DU257241 Close 50000
Fill 2015-12-28 09:31:00.006 IB order fill (execution)8719 4059 Market 50000 Sell Filled 87.455 50000 DU257241 Open -50000 0001f4e8.5680936c.01.01
It seems impossible that the turnaround from order generation to fill report back is only 4ms
The documentation says: The format is: YYYY-MM-DD HH:MM:SS.MS. MS equals milliseconds and is not the actual millisecond time. Rather it is used to create a unique entry when entries have the same time-stamp. It is incremented until a unique time is found.
2 questions:
- 1) in my example above , it seems like "entries" have the same timestamp. But how can order turnaround times can be even <4ms.
- 2) what would be the way to track timings in ms of order submission/execution?

Thanks!