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)
I am hoping to get back to trading soon, but in the meantime here is a thread covering some of the technical issues I ran into recently. This is only something that I have ever seen in V 8.11. Prior to this I never had this issue.
For anyone else out there on the new 8.11 version. If you are running a memory intensive strategy and you go to refresh the trade performance, it might crash, or freeze and become unresponsive.
I have been in contact with NinjaTrader support and they are working on addressing the bug. Hopefully they will have a fix sometime soon, but in the meantime I am going to be working off of an older version < 8.11 where I do not experience this particular issue.
Here is the thread for anyone interested in learning more.
Sorry to hear about the ninjatrader. It has happened to me as well. What I have done was break strategies into pieces. Fist I had two buy signals and one sell signal in one strategy. After freezing and not firing orders, I broke it into separate strategy. So I am now running three different strategies and so far, not a single problem.
I don't know if it helps but my work around was to just not use the newest version. 8.11. I am currently running 8.6 and have not had any issues with it. I know that 8.10 is still on their site, that one may be more stable. I am not sure what version you are on, but in my case the issue was only with 8.11.
Going into 2018, I just wanted to throw out a few ideas that really helped me connect the dots in 2017. This may help others find their own edge, or look at things a different way.
I used to always look at price changes as a very binary very simple view. Price goes up 1 tick, Price goes down 2 ticks, Price goes up 4 ticks, Price goes down 6 ticks, etc. I characterized each of these events evenly and treated all changes in price as the same. Even though I have been aware of the exchange mechanics for sometime now, I didn't really start to bifurcate price changes in tandem with the way the exchange clears levels until recently. Here is an example.
The Bid and Ask both change levels up from lets say a whole number ending on .25 and now it moves to .5. So the whole level moves up 1 tick. A number of things will occur next.
1. Since the price level that cleared moved up, the first side to get served will typically be the bid volumes, when this occurs the last price will = the bid price.
2. Once the bid volumes get fed, then the guys in the ask line are next. So the last price will tick the other way to the ask price.
3. This game will continue until one side wins and one side loses. As the last price oscillates between the bid and ask, you will see the price tick up .25 and down .25. Eventually the volume from one side will drop to 0 and then the level will clear and the entire Bid / Ask price will change up or down.
So with this simple example in mind, it is important to differentiate between a price change that occurred as a function of a level change vs. a price change that occurred as a function of ticking between serving the bid / ask volumes on the same level.
* The level change is a significant event
* The ticking between bid and ask volumes within the same level is noise.
* If looking at a chart, or just price history, or anything liner, all you will see is just (Price ticked up, price ticked down) It is not obvious that these mechanics are even in place, But if you adapt your strategy (in my case code) to look for the level change events, it makes all the difference in the world in terms of truly seeing what is going on in the market.
I don't concern myself with speculative volumes (level 2) at all. I only use actual transaction data (level 1). This area of research has been on modeling the sequencing of how a level actually clears. I think most traders miss this or don't have a deep enough knowledge of the mechanics here, because they may be spending too much time looking at the level 2 speculative volumes while they are missing the most important part. Truth be told, you will never be able to see this type of action on a tool like the DOM because it occurs insanely fast, and there is no running visual history. I had to build a script to output a few hundred thousand rows of data just to get one days worth of data to analyze, and only then did I find the patterns, but they are there!
In the past 3-4 months I have developed at least 5 different solid entry systems that get me into trades flat or better in most cases based on doing some nano-structure work in the field of research concerning the level changes, bid / ask volume oscillations, sequencing events, and millisecond precision timing using the fabulous on market data event handler.
While I can't give too much away, I will say that this area of research has been quite fruitful for me in 2017, and hopefully others will research it as well and find their own edge with it.
Just want to say thank you for all that you share. I went through the thread from the beginning and the information that you share is absolutely awesome!
Has Ninjatrader been able to resolve your live trading issue?
Thanks for reaching out and thanks for the kind words. I have been working with NinjaTrader on the technical issues. They are aware of the bug I found in 8.11 and will likely have a fix in 8.12. In the meantime I am testing different past versions to try to find one that is stable. Unfortunately most of last week I was experiencing different but equally as serious bugs with 8.6. Page 2 on this thread outlines what occurred:
So after my issues with 8.11 and 8.6, Thursday I put 8.10 on the VM and ran SIM and it has not crashed yet, so I am very optimistic that this version might be stable for me. I plan to test in SIM for most of next week and if I don't hit any more technical issues then I will likely go back to my real trading account either late next week or the following week.
I don't typically give too much away about my personal system, but in this case I will share because this method is widely known and widely used by all HFT systems. I am punting this out there also because I have a few questions, and I am hoping that someone out there has an answer to my question at the end, we will see...
But here is the concept in a Nutshell.
When flat, you submit both buy and sell limit orders 4 levels above and 4 levels below the current level, so you have 8 orders resting at one time. My goal is simple, I just want to get one of these 8 orders filled within the first two sequences of action when the market moves to that level. A typical sequence once the price moves up looks like this:
Seq 1. Resting Bids gets served first. Usually 50% to 75% of the resting amounts get served.
Seq 2. Resting Asks get served next. Usually 50% to 75% of the resting amounts get served.
Seq 3. Resting Bids get served again, the remaining 25% to 50% are worked on here, but not completely exhausted.
Seq 4. Resting Asks get served again, the remaining 25% to 50% are worked on here, but not completely exhausted.
Seq 5. The final Bids that were resting that did not yet get filled + any new bids that entered are being served
Seq 6. The final Asks that were resting that did not yet get filled + any new bids that entered are being served
Etc.....
With the ES, 55% to 65% of all sequences that start with price up level change, and start by serving the Bid queue first, will end up depleting the bids before the asks are depleted, so the next level will be down. Vice Versa for levels that move down and start with the asks first. This is due to the fact that by sequence 3 you will have 2 attempts to clear the side that went first and only one attempt on the side that went second. By level 5 this will be 3 to 2 and by level 7 this will be 5 to 4. So this is why there seems to be so much noise in price movement in the ES, but typically one level that clears is the signal, and the next opposite level that clears is the noise. Determining which level is noise and which level is the signal can come as a function the count of levels cleared prior to the change, or duration of time on a level, but this is beyond the scope of this topic. (I may cover this in depth in later posts if there is adequate interest). Now in my example I show 6 sequences with the possibility of more behind it, and on average I see 5-9, but no one really knows when the shoe is going to drop and the level will suddenly change. So for any entry system to work optimally the primary goal above anything else is to get filled on the current level and to not get filled on one of the last sequences only to have your order be the very last shoe to drop before the level change goes against you and you lose 1 tick.
So if you have size and you are resting a few levels out you have a good shot at getting filled in sequence 2 or sequence 4, if you are not filled by sequence 2 then you have a 50% / 50% shot of having your fill come at the expense of losing 1 tick. If you are not filled by sequence 4 then your odds increase to 75%, and anyone getting filled on sequence 6 or later should expect 90% of the time to lose the spread and be down 1 tick for getting filled. I have studied this part enough to just free ball the stats, but generally this is what I have observed over hundreds of thousands of simulations.
Obviously no one really has a good shot at being in the front 50% of the queue coming in just one tick off of the current level, but when you put 8 resting orders (4 per level) your odds increase. The logic is fairly obvious from here, but I will just lay it out there for everyone on how this works.
1. The market finally reaches the level of your first resting order which you put 1 tick away from the current action. After filling sequence 2 and moving to sequence 3 (which is now serving the opposite side) you find you did not get filled, so you cancel your order, and resubmit a new order 4 ticks away using the same long or short position as the one you just canceled.
2. From here the market either continues moving the same direction and meets your next resting order that was for the same direction, or it moves backwards and finds your first resting order for the opposite direction which was as far away resting as 2 levels. Now we just repeat the process. If you don't get filled by sequence 2 cancel and resubmit 4 levels away.
Now this is just covering the basic mechanics, but in addition to this method I also have other things I look at to determine strength in direction, (Alpha Signal), and if I am not satisfied when my number is called, I can cancel for lack of a coherent alpha signal as well. But for obvious reasons I will not cover this part.
But generally speaking the idea is to only accept fills that have a very high probability of getting filled on the current level. Using 8 resting orders 4 levels out on both sides will increase the likely-hood of achieving the time priority, but it will sill suffer from orders that cut in line because they hold larger sizes. So to gain advantage here, and because there is a prevailing opinion that HFT algos are doing this... Is it possible to gain advancement in the queue by holding larger sizes and ultimately canceling down to a smaller size and not just lose the queue positioned gained immediately?
Does anyone have any insight on if or how often the matching engines sort based on size / time priority? This could be one of two scenarios.
1. The Matching Engine sorts and shuffles orders ever X interval to account for changes in size. This would ultimately move people up and down in priority, but not instantly, as the sorting only occurs ever X intervals. In this scenario one could gain advantage by faking larger sizes than they intent to trade then canceling at a point prior to the matching engine resorting and demoting them.
2. There is no sorting in place at all, every order's status is virtually instantly updated in real time. In which case the idea of holding 5 contracts to gain priority if there is only intent to trade 1 won't work because as soon as you cancel 4 you are instantly in the place in the queue you belong just holding 1. I am guess it is most likely this scenario, but there is definitely a prevailing opinion that algorithmic traders show size then cancel to both trick order flow traders and to try to gain advantage in the queues but I do not know to what extent their attempts to gain advantages in the queues are successful.
For anyone that can give me some insight into these mechanics I would be glad to share some of my code for this system, or potentially help in other ways as a reward.
Thanks for the quick reply. That pretty much confirms what I thought. I thought ES was FIFO, but I know others are size / time priority and I just wondered about the general concept and how it may apply. I would guess that any half decent exchange would synchronize their books in real time thus preventing any possible manipulation to gain rank. But with all the smoke out there about HFT systems gaming the exchanges in every possible way, I just figured I would punt this out there.
