PRELIMINARY LMFX PERFORMANCE
Operations mediated by MT4 times from start to
finish of the Market Order submission.
C:\HyperScalper\apps\tt-live>cat tt.log | grep -i orderop
[20170718-07:14:42.197(GMT)] OrderOp elapsed: 157 (milliseconds)
[20170718-07:14:53.040(GMT)] OrderOp elapsed *: 249
[20170718-07:14:53.181(GMT)] OrderOp elapsed: 141
[20170718-16:41:57.872(GMT)] Sell Market OrderOp elapsed: 212
[20170718-16:43:38.372(GMT)] Sell Market OrderOp elapsed: 185
[20170718-16:50:04.387(GMT)] OrderOp elapsed *: 107
[20170718-16:50:28.590(GMT)] OrderOp elapsed *: 140
[20170718-16:52:12.559(GMT)] OrderOp elapsed *: 62
[20170718-16:59:33.965(GMT)] Sell Market OrderOp elapsed: 234
[20170718-16:59:59.669(GMT)] OrderOp elapsed: 208
[20170718-17:09:24.840(GMT)] OrderOp elapsed: 201
So these are “orderop times” I’m seeing initially with a “Zero Account”
variable spread plus commish account at LMFX. This server is
2.35 milliseconds from LMFX’s backend servers as reported by MT4.
What I like about this is consistency of Order response times. Although not the fastest turnaround times, they are good enough for our purposes.
The configuration uses a Java process, communicating with the NJ4X.com API framework into a “pool” of MT4 “terminal.exe” processes which are configured as 1 Market Data listener, and 4 Order Worker processes which are able to do concurrent processing into the same account. So it’s a bit complex.
It’s running on a seedvps.com 3 Xeon Core / 6 gb Windows Server 2008 tuned for best interprocess communication, etc… situated in Amsterdam. I’m using a “virtual limit order” mode where the system simulates a limit order, but strikes “counter trend” when the price “snaps” and stops running against us. It then strikes as quickly as possible with a Market order, on the “snap back” in price so that slippage works in our favor each time and so we get price advantage on nearly every entry.
hyperscalper
hyperscalper