Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Market spikes Vs. Bracket Orders - how does your platform handle that?
Can you provide the millisecond timestamps of each event?
About
1/ the algorithm that handles orders can be written more or less efficiently
2/ the language with which the platform is built with can have an impact on the speed of execution
3/ the infrastructure routing your order could have preferential routes to the Exchange
unless very special cases (algos coded with winter gloves, or, more seriously, no simple computing stuff but database/network access before sending orders) the 1 and 2 are done few magnitudes than the 3 and their impact is limited or undetectable.
That's the most common case but of course if your algo puts your CPU to 100% for 5 seconds it's a problem.
So the bracket buy limit on Monday:
15:02:19.973 - In Transit
15:02:19.975 - Working 15:03:24.839 - Fill
The stop which should have been triggered but was rejected 15:03:25.629 - In Transit
15:03:25.632 - RejectFCM - Stop price is already in market ExchangeRejectCode = 5
Just now I have just tested another bracket order to see if there was a difference in performance
Okay so 5 seconds (5000 ms) between "working" and "fill" is a problem .
You didn't mention the timezone so I can't check by myself but you can take a look by yourself if the activity was so insane during this period to produce such crazy lag (using a 1 second bar type or a 1 tick/1 range bar).
No, unless I misunderstand what you're saying, "working" means: I placed the limit order, now the limit order is active in the queue ('working'). It was a limit order so it was just sitting there waiting to be filled. It was filled 1 mins and 5 seconds later. Again, this is unless I misunderstand what you were saying there.
I tend to use limit orders for entry, so I can place them even 5 mins in advance, they will sit there waiting to be filled.
Normally bracket limit orders, when filled, trigger a stop and a target order. In this case the stop was not triggered.
Timezone was UK time and, yes, there was a significant spike down, so it could be defined as a odd event. However this is the 3rd event in recent times experienced by me or someone else (see DavidHP prior in the thread)
What I wonder is: the Limit order was sitting on the Exchange. Presumably, once the limit order is filled, it will communicate to the CQG infrastructure that now a stop order must be triggered. So any lags would have been either
1) the burst of orders coming from the Exchange caused delays on the CQG infrastructure
2) some lag within the CQG infrastructure itself
3) a combination of 1) and 2)
I don't know if this will have any value for you or not, but based on the information below it looks like you are researching Monday 7-9 during the 3:00 PM eastern time US hour.... Or it might be a different time frame. I might have the conversion wrong based on the the time zone. Let me know if it is a different time frame.
Either way I ran the raw level 1 price level sequence for you for that hour, in case it helps to see something.
Not sure if this will shed any light on anything or not.
Ian
In the analytical world there is no such thing as art, there is only the science you know and the science you don't know. Characterizing the science you don't know as "art" is a fools game.
Thanks Ian, it wasn't 3:00 PM EST, it was 3:00 PM UK time (I provided Sam the timezone in my previous post).
Actually I do have a video of my trade, so I know exactly what took place and when. This was a 'spike', i.e. a sudden acceleration of momentum in one direction which was so fast that even bracket orders couldn't keep up.
My question is more about what Sam was hinting about both in terms of infrastructure and when he asked me to look at millisecond timestamps, which I had not thought about.
That really helped as it clearly shows that, while normally a bracket is triggered within < 200ms of being filled, in this case it took almost 800ms to be triggered.
In my analysis, I found that the CL spike was a HFT that took out several levels in the same second timestamp. I know that NT will not place a stop order until the order is 'filled' and in this case the market had moved beyond my stop before the fill was recognized.
I am revising my code to initialize a larger stop at "FILL" and then immediately move it after it is placed.
This will be a larger stop than normal just to prevent HFT or lag to prevent a stop from being placed. After the stop is placed it should be easy to move the stop and allow the ATM to take over and manage the trail/exit.
(Another option would be to trap the error if the stop is not filled and immediately execute a market stop but that makes me feel 'out of control'.)
p.s. my lag is usually very small so this lag is unusual and it may take a while for it to occur again so I can test the success of my new codes efficiency.
Rejoice in the Thunderstorms of Life . . .
Knowing it's not about Clouds or Wind. . .
But Learning to Dance in the Rain ! ! !
Yes, that would be how a bracket order works, at least that's also how CQG interprets it.
The code would have to account to where the market is, though, because when you place the stop further away and then attempt to move it back to its original place, in the scenario we are looking at, you would invariably get a rejection given market is already past it, wouldn't you?
This sounds the best way to go in these cases. If I had had any such code in CQG I would be looking at a much more palatable loss of ~15 ticks as opposed to 37.
Do you have the timestamps of the rejection? Would be useful to compare the time from fill to when NT attempts to place the stop. Would also be useful to understand the fill-time-to-stop-place-time in normal circumstances in NT.
Yes I have timestamps but they are not to MS since I was not recording them on this trade.
The only ones I have were in the log/trace files in NT7 so they are not great but the problem can be seen.
The larger stop I was speaking of was 20 tick stop which seldom is taken out in less than a second. But it could be any number I want since I will set it up. My strategy knows where the market price is so it could be checked before move.
I think the error trap is the best method so that is the way I will proceed. Should be an easy fix but just need to stop long enough to write the code.
Rejoice in the Thunderstorms of Life . . .
Knowing it's not about Clouds or Wind. . .
But Learning to Dance in the Rain ! ! !
By the way, there's another quick step that I took to ensure any potential delay from my platform's point of view is minimized, and that's change the priority of the platform in Window's Task Manager
Most normal applications tend to have the 'Normal' priority, so I set it to 'High'.
I've read it's not advised to set it to 'Realtime' as doing so may interfere with keyboard and mouse operation which of course we want to keep ready, unless it's a case of systematic trading.
.
