LMAX = revolution?!? | Page 22 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

LMAX and Fastbrokers 20 replies

Anyone with Darwinex or LMAX? I had a little issue with AUDJPY 27 replies

LMAX? Anyone Trade With Them Here? 12 replies

Dukascopy vs LMAX - Has anyone tried either or both? 7 replies

Information about LMAX? 2 replies

Attachments: LMAX = revolution?!?
Exit Attachments

LMAX = revolution?!?

  • #421
  • Nov 22, 2011 4:31am Nov 22, 2011 4:31am
Morning Bleek,

Quoting Bleek
I trade regardless of the news so naturally the news interacts with my trades but aside from NFP I do not consider it, and even NFP doesn't stop me trading.
And you have fewer problems with the "the usual spread widing/ low liquidity" that havaiana refers to at LMAX than at the other brokers you've tried?

Quote
I trade manually, always have, always will. I trade with naked/plain charts, sometimes completely without and therefore API and automated trading is of no interest to me.

I suspected as much, which is why I asked the question. Thanks for answering it.

Quote
Not wishing to sound arrogant but we appear to be coming from two very different directions here, I'm not concerned about patterns, automation and statistics, I'm concerned with my bottom line because it's the only thing that matters!

We are coming from two different directions here. Manual versus automated. However beyond that you do seem to be making quite a few invalid assumptions. Lots of factors feed into both your and my bottom line, "slippage" on "stops" being one of them.

Cheers,

Jim
  • #422
  • Nov 22, 2011 4:46am Nov 22, 2011 4:46am
Quoting TradingGurus
And you have fewer problems with the "the usual spread widing/ low liquidity" that havaiana refers to at LMAX than at the other brokers you've tried?

We are coming from two different directions here. Manual versus automated. However beyond that you do seem to be making quite a few invalid assumptions. Lots of factors feed into both your and my bottom line, "slippage" on "stops" being one of them.
Invalid in relation to LMAX directly or trading in general, are you suggesting that no other broker has liquidity issues filling all Stops?

Trust me I know how much that costs me, I traded many mil on Currenex so even fractal slips cost me $100's and in some cases $1,000's.

I don't have any specific examples for LMAX but I have obviously been in trades during some rather volatile moves and I had very minimal slippage on my Stop, my worst ever LMAX 'slip' on a Stop was 0.5.

In relation to Stops in general I have noticed regular fractional slips, in fact checking my spreadsheet the past ten Stops hit slipped as follows:

0, 0.2, 0.3, 0.2, 0, 0.2, 0, 0.2, 0.2 and 0.

As you can see there is a small amount of slippage.
"I made all my money by selling too soon"
  • #423
  • Nov 22, 2011 4:48am Nov 22, 2011 4:48am
Hi Jeff,

Quoting jeff_b
I'm writing an experimental java chart client at the moment because I'm bored, if you need help, gimme a holler, I may be able to help.
Thanks for the offer, but I now realise that I'm forgetting where I am and I therefore phrased my point 4 rather badly. I'll restate it if I may, in 3 parts.

4a) Obviously not everyone here is looking to automate their trading at LMAX! Of those that do, are you using the FIX, REST, Java or .NET APIs?

4b) Of those interested in FIX (if any!) which FIX engine do you plan on using?

4c) I can provide examples of working code written in Java that utilise the LMAX FIX (+ QuickFIX/J) and Java APIs. Would anyone here be interested in examining and/or helping to improve either of them?

Cheers,

Jim
  • #424
  • Nov 22, 2011 4:51am Nov 22, 2011 4:51am
So you had slippage on a stop-order during economic figures? Is that what your problem with untrusted markets is? Because you are rather nebulous about the exact nature about your issues.

Not trying to be a fanboy here, if there are real problems i would like to know about it.
  • #425
  • Nov 22, 2011 6:21am Nov 22, 2011 6:21am
Hi Bleek,

Quoting Bleek
Invalid in relation to LMAX directly or trading in general
Trading in general, and automation in particular. You seem to be assuming that automation implies "patterns and/or statistics" for a start. That ain't necessarily so!

Quote
Are you suggesting that no other broker has liquidity issues filling all Stops?

I'm not suggesting anything of the sort!

Quote
I don't have any specific examples for LMAX but I have obviously been in trades during some rather volatile moves and I had very minimal slippage on my Stop, my worst ever LMAX 'slip' on a Stop was 0.5.

My "stress testing systems" have "obviously been in trades during some rather volatile moves" and their "worst ever LMAX 'slip' on a Stop" on FX was over two orders of magnitude worse than yours.

Cheers,

Jim
  • #426
  • Nov 22, 2011 6:27am Nov 22, 2011 6:27am
Hi Shrike,

Quoting shrike
If there are real problems i would like to know about it.
See above. The news is imminent. The "market makers" run for the hills. The spread widens. The MTF "circuit breaker" opens. Your stop isn't filled until the circuit breaker closes again, which my experience suggests can take quite a long time on occasions.

Cheers,

Jim
  • #427
  • Nov 22, 2011 8:42am Nov 22, 2011 8:42am
Anyone actually placing trades live with MC's yet? What order entry tools are you using? Using brackets or trailing stops? How are you finding it?
  • #428
  • Nov 22, 2011 10:29am Nov 22, 2011 10:29am
Quoting Jfk
Anyone actually placing trades live with MC's yet? What order entry tools are you using? Using brackets or trailing stops? How are you finding it?
for the moment it is impossible trust MC.......
  • #429
  • Nov 22, 2011 12:29pm Nov 22, 2011 12:29pm
Quoting TradingGurus
4c) I can provide examples of working code written in Java that utilise the LMAX FIX (+ QuickFIX/J) and Java APIs. Would anyone here be interested in examining and/or helping to improve either of them?
Well, I would like to ask if you have noticed significant differences in speed comparing fix vs the java-api. I am not interested in automated trading but, as I use my own software to manually trade, I always rely on some sort of api.
Naturally I would (and do) use the java-api since I need the backfill functionality (that currently does not work, at least not in demo mode—I do not trade live with lmax, but do so with dukascopy, they have an extensive api, too).
  • #430
  • Nov 22, 2011 2:19pm Nov 22, 2011 2:19pm
Quoting gioviforex
for the moment it is impossible trust MC.......
Understand people having probs with hist backfil but seems nobody is trading through MC. Wish I could could connect Sierra to LMAX
  • #431
  • Nov 22, 2011 5:04pm Nov 22, 2011 5:04pm
4a) I only know Java so that's what I'll go with. I'll move high performance part to C code and integrate it with my java App. I do this for a challenge, profit later.

4b) N/A

4c) I'll help if I can. I'm here to learn. By the way, I'm not familiar with FIX protocols, why aren't you using stock FIX software instead of making your own?

Cheers.

Quoting TradingGurus
Hi Jeff,

Thanks for the offer, but I now realise that I'm forgetting where I am and I therefore phrased my point 4 rather badly. I'll restate it if I may, in 3 parts.

4a) Obviously not everyone here is looking to automate their trading at LMAX! Of those that do, are you using the FIX, REST, Java or .NET APIs?

4b) Of those interested in FIX (if any!) which FIX engine do you plan on using?

4c) I can provide examples of working code written in Java that utilise the LMAX FIX (+ QuickFIX/J) and Java APIs. Would anyone here be interested in examining...
  • #432
  • Nov 23, 2011 3:42am Nov 23, 2011 3:42am
Morning Astro,

Quoting m.m.m.
Well, I would like to ask if you have noticed significant differences in speed comparing fix vs the java-api. I am not interested in automated trading but, as I use my own software to manually trade, I always rely on some sort of api.
There are two completely different "platforms", so I'm afraid it's comparing apples with oranges. The native Java API that I've "stress tested" certainly works pretty quickly (when the circuit breakers are closed at least). There's a bit more overhead in FIX, but I can't imagine that would slow things down sufficiently to impact a "manual trading" application. I haven't tried live trading over FIX@LMAX yet though, only demo.

Quote
Naturally I would (and do) use the java-api since I need the backfill functionality (that currently does not work, at least not in demo mode—I do not trade live with lmax, but do so with dukascopy, they have an extensive api, too).

I'm aware of that. Are you thinking of moving from the Duke to LMAX? Are you interested in Dukascopy example code, come to that?

Cheers,

Jim
  • #433
  • Nov 23, 2011 3:50am Nov 23, 2011 3:50am
Morning Jeff,

Quoting jeff_b
4a) I only know Java so that's what I'll go with. I'll move high performance part to C code and integrate it with my java App. I do this for a challenge, profit later.
Martin Thompson assured me (before his departure!) that the LMAX MTF is 100% Java. Particularly if you only know Java, why do you figure the client needs C, if the exchange doesn't?

Quote
4c) I'll help if I can. I'm here to learn. By the way, I'm not familiar with FIX protocols, why aren't you using stock FIX software instead of making your own?

We're using an open source FIX engine (QuickFIX/J) for the FIX broker interface. That's as near as you can get to "stock FIX software", if I've understood your question correctly. Or did you mean "Why not just use MultiCharts"?

Cheers,

Jim
  • #434
  • Nov 23, 2011 3:51am Nov 23, 2011 3:51am
The advantage API vs FIX vs Rest may have one over the other is unlikly to be relevant. Even if you can colocate latency is a few milliseconds(and in the tens of milliseconds if you dont) - several orders of magnitude greater than what you might gain on protocol/language efficiency.
  • #435
  • Nov 23, 2011 4:10am Nov 23, 2011 4:10am
The charting library I use right now is rather crap, it uses a lot of resources for drawing (JFreechart), I'm thinking of moving the charting software part out to a C library so it's faster but it may not be necessary if I can improve the code or just upgrade my PC.

I thought you deploy/make your own FIX solutions so I asked, that's all. So you want to make changes to QuickFIX/J? Are you looking for low latency high performance trading (don't need to answer if you don't want to)?

Cheers.


Quoting TradingGurus
Morning Jeff,



Martin Thompson assured me (before his departure!) that the LMAX MTF is 100% Java. Particularly if you only know Java, why do you figure the client needs C, if the exchange doesn't?



We're using an open source FIX engine (QuickFIX/J) for the FIX broker interface. That's as near as you can get to "stock FIX software", if I've understood your question correctly. Or did you mean "Why not just use MultiCharts"?

Cheers,

Jim
  • #436
  • Nov 23, 2011 5:10am Nov 23, 2011 5:10am
Hi Jeff,

Quoting jeff_b
The charting library I use right now is rather crap, it uses a lot of resources for drawing (JFreechart), I'm thinking of moving the charting software part out to a C library so it's faster but it may not be necessary if I can improve the code or just upgrade my PC.
JFreeChart does have its advantages too though, one of which is that it's open source. Might you have a potential interest in interfacing it to AlgoTrader?

http://code.google.com/p/algo-trader/

My speciality is the backend, but the frontend needs some work also. i.e. the GUI is currently non-existent!

Quote
I thought you deploy/make your own FIX solutions so I asked, that's all. So you want to make changes to QuickFIX/J? Are you looking for low latency high performance trading (don't need to answer if you don't want to)?

I wear lots of different hats. I'm not personally "looking for low latency high performance trading". In the context of AlgoTrader the solution to the "ultra low latency" issue is more likely to involve switching to a different FIX engine rather than doing lots of messing about with the internals of QuickFIX/J, which I guess has some similar issues to JFreeChart!

Cheers,

Jim
  • #437
  • Nov 23, 2011 6:30am Nov 23, 2011 6:30am
Quoting TradingGurus
Are you thinking of moving from the Duke to LMAX? Are you interested in Dukascopy example code, come to that?
There are things that interest me at Lmax (i.e. external clearing, mtf, safety of funds), but also things that do not quite appeal to me (netting vs hedging).
At the moment I'm satisfied with Dukas, but it's always good to have an alternative. If I ever decide to migrate, I would like to have an already working software at hand and therefore the effort.

Example code for Dukas? No, I already have a working client software for Dukas. Or did you mean LMAX? In fact, I've ported the same client for LMAX, only the integration of historical data I could not really test, because LMAX has this problem with it. However I appreciate your offer, but the thing is I do not really need.

Regards
  • #438
  • Nov 24, 2011 2:17am Nov 24, 2011 2:17am
Quoting m.m.m.
but also things that do not quite appeal to me (netting vs hedging).

Regards

What you mean exactly ?
  • #439
  • Nov 24, 2011 3:04am Nov 24, 2011 3:04am
Morning Astro,

Quoting m.m.m.
Example code for Dukas? No, I already have a working client software for Dukas. Or did you mean LMAX?
I meant both (+ FIX). i.e. source for an example strategy ported to a variety of different "trading platforms". For example, one of the things near the top of my TODO list at the moment is providing AlgoTrader with the equivalent of OnTick() and OnBar() events, to make porting code over from JForex easier.

Cheers,

Jim
  • #440
  • Nov 24, 2011 3:23am Nov 24, 2011 3:23am
Quoting Cocoflanel
What you mean exactly ?
Hedging means here that I can be long and short an instrument at the same time. I need this feature sometimes.
Another thing is that I am dependent on their API, I want to run my own software and am not interested in a web-frontend or third-party software, i.e. Multicharts.
As I can only refer to their API at current level, and I prefer to use the Java-API, it simply does not implement the functionality that I need. In example: The Java-API currently can handle only an aggregate position per instrument, but I need to have them separated, i.e. every trade should produce a discrete position that can be referred to, i.e. for closing.
Now, judging by the newest release of their XML-API, they seem to have addressed this problem, and I hope that this will be ported to the Java-API soon.

However, my biggest problem would be, I think, something quite different: they seem to be very picky in terms of choice of clients.
6 traders viewing now