My Own Broker Arbitrage | Page 8 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

Arbitrage with no-interest broker 147 replies

eur/usd arbitrage broker? 4 replies

does you broker ban arbitrage on manipulated price quotes? 2 replies

My idea for broker arbitrage 13 replies

Broker arbitrage BIG TIME 4 replies

Attachments: My Own Broker Arbitrage
Exit Attachments

My Own Broker Arbitrage

  • #141
  • Dec 29, 2011 11:07am Dec 29, 2011 11:07am
How long would it take to send a ~1500 character string? That's what I'm sending from the slaves to the master.
  • #142
  • Edited 11:58am Dec 29, 2011 11:26am | Edited 11:58am
still run at demo, sometimes master script must be reloaded or drag to chart again, because stopped/hangs
today start
Attached Image (click to enlarge)
Click to Enlarge Name: Clip_6.jpg Size: 187 KB
  • #143
  • Dec 29, 2011 4:53pm Dec 29, 2011 4:53pm
I was thinking a bunch of VM's, w/ a dual nic interface. One to get out on the internet to get the data and the other nic dedicated to a private network (which w/ all being on the same physical machine would just be in memory).

Quoting ianj1
Sockets are not a problem - Most C based sockets can work in around 300ns (nano). I have myself managed a round trip (a message from java to MT4 and a response back) in about 1-1.5ms (millisecond) - thats not a problem on MT4 timescales.

The advantage of sockets is the simpler server implementation and the potential for access from other machines (maybe an additional 0.5ms within the same LAN)
  • #144
  • Dec 29, 2011 4:58pm Dec 29, 2011 4:58pm
Quoting Ronald Raygun
How long would it take to send a ~1500 character string? That's what I'm sending from the slaves to the master.
It depends on the speed of the connection and how you read/write - to be honest i never timed it as the messages i sent from mt4 and server tended to have an implied context - ie i had a logon phase where details were exchanged which lasted the whole of the session.

The theoretical calculation depends on the intervening network speed - 100Mbit (typical cat 5e) lets you transfer 10Mbyte or so of data a second - but only if the packets are sent end to end without requiring acknowledgements - if you get an interactive conversation you are unlikely to improve upon 1-2Mbyte per second. Gigabit will go faster but then application design will play a far larger part in determining effective speed. Additionally, timing over a WAN connection are notoriously difficult to do properly as you have to consider numerous things including tcp window sizes, nagles, packet sizes etc. Then again, at least remoting is possible - local IPC mechanisms dont allow that at all

All i needed to send in EACH message was a timestamp, (in theory you don't need that if you can forward the updates in a timely fashion), symbol, price (or a pair if you ship bid/ask at the same time - you might consider sending just the bid/add when one changes - would have to test which one was better)

Orders would, of course, need more data - but mostly a reference (sent), price, type, symbol, sl, tp, magic, comment - and receive a ticket,reference(sent), status and opening price back

Are you bundling a number of messages together to get to 1600 or are you using fixed width formatting instead of using a delimiter between fields

If you are sending along the same network segment 1600 should not be too detrimental - it is 2 network packets - If you were linked over a WAN the time addition might be significant - keeping it below 1400 or so would help (1492 is a common magic packet length), though its likely the Mt4 instances would be running from the same location - your mileage might vary.

I think the more interesting challenge is how to respond to messages in a timely manner - polling will slow you right down - using sockets i was able to stop mt4 in a blocking read - waiting for an order request - it was able to receive the message, process the command and respond immediately. The compromise is that it consumes the EA thread and you need to use another EA to send price updates (you get 1 thread per EA) - or you could use a script as they also have a thread, although that might be shared with the GUI - i am not sure as i have not tested - so you might lose responsiveness

You don't need this stuff to start with - but its worth having to hand in case you run into threading/co-ordination issues - I appreciate you are working on the logic to start with.

Sorry for the long winded answer - but i guess too much is better than too little
  • #145
  • Dec 29, 2011 6:21pm Dec 29, 2011 6:21pm
All EA's, in the same terminal instance, share the same thread. This is for MT4. Metaquotes says in MT5, that's changed. Haven't tested to find out yet.

Quoting ianj1
(you get 1 thread per EA)
  • #146
  • Dec 29, 2011 6:22pm Dec 29, 2011 6:22pm
I myself have a program written in C# and C++ (see attached), the project was started about 3 months ago and so far has been tested in demo for more than 1 month. Everything is fine on demo, but when I moved to the live trading. The game is turned over by the slippage from the retail brokers. The FXDD keeps complaining about the off-quotes and re-quotes. same thing happened with the forex.com. BTW, the average order execution time from my program is less than 1 second on most of brokers. The program is also installed on a vps. With all the data (execution time, slippage, vary brokers) I collected, my sense is that the slippage is the most dangerous threat to the system. Unfortunately, I have not been able to make it profitable on the live trading. any thoughts, guys? Thanks,
Attached Image (click to enlarge)
Click to Enlarge Name: Arb.png Size: 22 KB
  • #147
  • Dec 29, 2011 6:24pm Dec 29, 2011 6:24pm
Slippage being #1. I found Freezelevel being #2.

Quoting Iceworld79
I myself have a program written in C# and C++ (see attached), the project was started about 3 months ago and so far has been tested in demo for more than 1 month. Everything is fine on demo, but when I moved to the live trading. The game is turned over by the slippage from the retail brokers. The FXDD keeps complaining about the off-quotes and re-quotes. same thing happened with the forex.com. BTW, the average order execution time from my program is less than 1 second on most of brokers. The program is also installed on a vps. With all the data...
  • #148
  • Dec 29, 2011 6:28pm Dec 29, 2011 6:28pm
nondisclosure00,
Thanks for your quick reply... The #3 is broker personality. I tested 6 brokers on demo. One of them is really really bad. basically it tried to screw you up for every single chance. Do you have any thoughts of how to deal with it?
  • #149
  • Dec 29, 2011 6:34pm Dec 29, 2011 6:34pm
Quoting Iceworld79
nondisclosure00,
Thanks for your quick reply... The #3 is broker personality. I tested 6 brokers on demo. One of them is really really bad. basically it tried to screw you up for every single chance. Do you have any thoughts of how to deal with it?
Are your difficulties in demo or in live?
  • #150
  • Dec 29, 2011 6:36pm Dec 29, 2011 6:36pm
In live. The system works like a champion in demo. grows everyday. But in live, the slippage is much more serious than I expected (I just tested for a few days on live, though).
  • #151
  • Dec 29, 2011 7:14pm Dec 29, 2011 7:14pm
Quoting Iceworld79
In live. The system works like a champion in demo. grows everyday. But in live, the slippage is much more serious than I expected (I just tested for a few days on live, though).
Presumably you're using market orders? I found that #3 (broker personality) was quite a wild card and spent a lot of time on that one - tuning for the live server. I don't want to turn RR's thread into a help desk but just a couple of comments and some homework.

You probably already are but make sure to refresh rates before transmitting. If the rate in your order doesn't match the rate in the broker you get rejected, particularly when using small slippage #s. I've found that this is ESPECIALLY true on live servers and with OrderClose(). Ironically, you may need to reduce the slippage # to a smaller factor and just accept the fact that you're not going to get all those fills on the slow broker, or just keep refreshing rates and attempting to get a fill while the price is attractive for the slow side of the arb.

There are a number of issues with order transmission on MT4 brokers. I cover some of those in this article: How to write a close all script (particularly RefreshRates / IsTradeContextBusy / IsTradeAllowed / Slippage) and also see the Notes under OrderSend as well as the NormalizeDouble function in MT4 help if your'e injecting your own prices to get a specific fill on a specific broker.

The difficulty comes when trying to actually put on the arb on the 2nd broker. You don't want to put on the offsetting position before you know the slow quote has gotten a fill, and you may consider just executing on the slow quote though that will take some system development if the signals are infrequent. The edge in this arb strategy is getting the fill on the slow broker. The 2nd fill hedges and locks in profit but doesn't add alpha (unless both broker prices are out of whack).
  • #152
  • Dec 29, 2011 7:36pm Dec 29, 2011 7:36pm
Quoting FXEZ
Presumably you're using market orders? I found that #3 (broker personality) was quite a wild card and spent a lot of time on that one - tuning for the live server. I don't want to turn RR's thread into a help desk but just a couple of comments and some homework.
Thanks, FXEZ. I don't intend to hijack RR's excellent thread, either. I believed that my problem is also the difficulties for many others who have the same interest in the Arb. system. Our discussion may do some good to the system.

Yes, I am using market orders, for sure. You want to grab the opportunity ASAP, right?

Quote
You probably already are but make sure to refresh rates before transmitting. If the rate in your order doesn't match the rate in the broker you get rejected, particularly when using small slippage #s. I've found that this is ESPECIALLY true on live servers and with OrderClose(). Ironically, you may need to reduce the slippage # to a smaller factor and just accept the fact that you're not going to get all those fills on the slow broker, or just keep refreshing rates and attempting to get a fill while the price is attractive for the slow side of the...

Yes, I do refresh the rates before sending the orders. But I use a large tolerance on the slippage. Otherwise, the system will get many rejections. especially during the fast movement.

Quote
There are a number of issues with order transmission on MT4 brokers. I cover some of those in this article: How to write a close all script (particularly RefreshRates / IsTradeContextBusy / IsTradeAllowed / Slippage) and also see the Notes under OrderSend as well as the NormalizeDouble function...

Yes, all these has been considered. I also check the order history to ensure the order is actually executed.

Quote
The difficulty comes when trying to actually put on the arb on the 2nd broker. You don't want to put on the offsetting position before you know the slow quote has gotten a fill, and you may consider just executing on the slow quote though that will take some system development if the signals are infrequent. The edge in this arb strategy is getting the fill on the slow broker. The 2nd fill hedges and locks in profit but doesn't add alpha (unless both broker prices are out of whack).

It is very true that the 2nd broker is hard to control. it is not unusual that only one leg gets filled.

As to the offsetting position, if you put another order after one leg is established, is it still the arb system? To me, it is more like to hedge the previous position. I will try to modified accordingly and see how it goes.

Thank you very much
  • #153
  • Dec 29, 2011 9:54pm Dec 29, 2011 9:54pm
Quoting nondisclosure00
All EA's, in the same terminal instance, share the same thread. This is for MT4. Metaquotes says in MT5, that's changed. Haven't tested to find out yet.
Oh ! Thats odd coz my home written copier in MT4 has a number of ea's - one per 'signal' it sends - it uses a blocking socket read to ensure a quick response on order processing. I can and do run 5+ of these in a single Mt4 instance (no polling) , and each has the same response characteristics, around 1ms - which says to me that they are each running in a separate thread (I am running the standard WSA socket stuff) The only ill effect is that the same thread is used to show the EA Properties dialog - so you cannot edit the EA properties without first stopping the EA !

I believe there is a single shared trading context - and this stops parallel trading operations, but it is still one thread per EA (to be more precise evidence merely indicates more than one thread concurrently as i have not confirmed that the SAME thread is used for each EA invocation, but it would be an easy way to serialise thread start() method calls if it was a single thread for each EA, instead of some thread pooling/queuing mechanism)

This is hinted at in this discussion:
http://forum.mql4.com/22585

I do believe the threading model for chart indicators and scripts is different to EA's - I am GUESSING that all indicators run on a single thread, and each script runs on a separate thread, although i have no experience to corroborate this

I know the strategy tester is single threaded - are you sure your are not picking your information up from that fact

I am a little mystified if i got it wrong, as i have no other way to explain the behaviour i see!
  • #154
  • Dec 29, 2011 10:08pm Dec 29, 2011 10:08pm
Quoting FXEZ
The edge in this arb strategy is getting the fill on the slow broker. The 2nd fill hedges and locks in profit but doesn't add alpha (unless both broker prices are out of whack).
FYI on an institutional broker you can trade flat with a limit order and hopefully get a better fill as passive orders rarely get the price improvement - that usually goes to the aggressive leg
  • #155
  • Dec 29, 2011 10:19pm Dec 29, 2011 10:19pm
Quoting Iceworld79
As to the offsetting position, if you put another order after one leg is established, is it still the arb system? To me, it is more like to hedge the previous position. I will try to modified accordingly and see how it goes.
I have mentioned before that my BELIEF is that, for MARKET orders, concurrent execution is worthwhile as the cost of delay is likely to outweigh the cost of slippage. The slippage limit could help (but is it universally implemented ?) but i bet its not gonna reduce the delay. I promise not to say this again - honest !

If MT4 had LIMIT orders then it would be equally viable to execute concurrently or asynchronously, depending on your opinion at the time

I'll add that am also not trying to hijack the thread (but not succeeding very well :-), but hope the shared experience might help RR navigate the pre-trodden minefield that awaits
  • #156
  • Dec 29, 2011 10:49pm Dec 29, 2011 10:49pm
can you be a little more specific w/out giving out names?

Quoting Iceworld79
nondisclosure00,
Thanks for your quick reply... The #3 is broker personality. I tested 6 brokers on demo. One of them is really really bad. basically it tried to screw you up for every single chance. Do you have any thoughts of how to deal with it?
  • #157
  • Dec 29, 2011 10:56pm Dec 29, 2011 10:56pm
Quoting nondisclosure00
can you be a little more specific w/out giving out names?
I did some statistics analysis on the trading history of 6 brokers. The average slippage from the bad boy (~3 pips) is way worse than the other 5 brokers (0~1.5pips). Although they claim they are ECN-type, I refused to believe. Also, the average execution time is more than the others. Basically, I guess they tried to give you the worst price within a given execution time window.
  • #158
  • Dec 29, 2011 11:00pm Dec 29, 2011 11:00pm
Now I'm confused. You can send orders concurrently as long as they are in different MT4 instances.

Quoting ianj1
I have mentioned before that my BELIEF is that, for MARKET orders, concurrent execution is worthwhile as the cost of delay is likely to outweigh the cost of slippage. The slippage limit could help (but is it universally implemented ?) but i bet its not gonna reduce the delay. I promise not to say this again - honest !

If MT4 had LIMIT orders then it would be equally viable to execute concurrently or asynchronously, depending on your opinion at the time

I'll add that am also not trying to hijack the thread (but not succeeding very well :-), but...
  • #159
  • Dec 29, 2011 11:01pm Dec 29, 2011 11:01pm
Now this throws a monkey wrench into what metaquotes told me.

Quoting ianj1
Oh ! Thats odd coz my home written copier in MT4 has a number of ea's - one per 'signal' it sends - it uses a blocking socket read to ensure a quick response on order processing. I can and do run 5+ of these in a single Mt4 instance (no polling) , and each has the same response characteristics, around 1ms - which says to me that they are each running in a separate thread (I am running the standard WSA socket stuff) The only ill effect is that the same thread is used to show the EA Properties dialog - so you cannot edit the EA properties without...
  • #160
  • Dec 29, 2011 11:03pm Dec 29, 2011 11:03pm
Quoting nondisclosure00
Now I'm confused. You can send orders concurrently as long as they are in different MT4 instances.
I sum the slippage of all trades within the forward testing period (one month) for each individual broker and do the average over the total number of trades. Then you know some are good, some are natural and some are bad.
0 traders viewing now