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)
Given ASK is at price value A0 (original price value) and price values above are at A1, A2, A3.... and BID is at price value B0 and price values are below at B1, B2, B3... At some time t, some typical point in time, what happens to the DOM volume at A0 if the ASK price value goes to A1 (next higher price value)? I would think the booked orders that were not filled are still "there" unless pulled. And in this typical example, just moments later, when price movement causes the ASK to drop back to the original price value, how is the DOM volume reported at the re-established ASK price value? It would seem if one was slow in reacting, their missed DOM orders would still be on the book, and/or perhaps if the trader was quick these orders may have been pulled (ie ASK DOM volume change at a lower-than-the-current-ask price value) . In this typical market movement, does the volume get reported just as it was when the ASK changed (which i don't think is the case) or does it come back updated (due to changes that occurred when the ASK was at the higher value)? And if it comes back updated (which I think is the case), what process is updating these orders (ie the actions taken by traders who pull a missed limit order ) below the ASK? I am certain orders can be pulled in this case(done this myself), but does that imply orders can also be added? If this is how the system works, it would seem this should also apply to A-1, A-2, A-3... to support requests in the case of a price spike that blasts past limit orders and leaves them hanging around. If my thinking is correct, then it would seem that the auction system is continually keeping track of limit orders to sell or buy at all prices, irrespective if above or below the ASK/BID respectively. Perhaps it only reports on the +10 and -10 order slots, but continually updates all in the market. Where can I find out more about this detail?
Can you help answer these questions from other members on NexusFi?
There are algorithms that trade in milliseconds constantly adding and removing their orders on the depth. This can give the appearance that price moves before all the limits are consumed, or that when it backticks and you see a lot of orders, it may appear they were already there.
Price can only move to the next level once there are zero limit orders left at the current level. Orders are being added and removed so fast, that it doesn't appear this way.
Think of it in terms of an auction: nobody is going to buy a vase for $10 is there is one available for $9. Likewise who would sell their vase for $9 if somebody is offering to pay $10?
The best resource for simply explaining how the market moves is the Jigsaw Trading website's free training section.
The DOM also has some update latency. 300 milli seconds would be typical. So you would not necessarily see a price level deplete to 0 before it moves to the next level.
1 - latency of data to your PC
2 - frequency of screen updates
At peak times, there can be 60,000 bid/offer updates in a minute. You obviously don't need to see them all and to avoid thrashing the CPU, there needs to be some sort of throttle.
Whether that adds latency or not depends on the architecture and how the throttling was implemented.
Most people in the US are 30-50ms from the exchange. I would estimate that total latency of 300 for someone in the US is on the high side.
If you have any questions about the products or services provided, please send me a Private Message or use the futures.io " Ask Me Anything" thread
I have 2 separate platforms, CQG and NinjaTrader, and the DOM updates appear to be considerably faster on the former - which is why I was questioning the blanket 300 ms statement.
