Support Board
Date/Time: Tue, 26 Nov 2024 10:48:23 +0000
[User Discussion] - Problem with market depth desapearing
View Count: 4100
| [2015-03-31 04:16:17] |
| |
|
And we know that TWS sending an update or insert message with a price and size of 0 will not be solved by this code: if (TempDomStructure.Price == 0 && TempDomStructure.Volume == 0) break; // no more DOM Levels So it has to be established that they are actually doing that to begin with as being the source of the problem. The way we see this, is there is too much tolerance to substandard programming from an external service and because of the uncooperative nature of the external service, the problem gets dumped on us as if it is our problem. If we can do something to solve it, we will. So we will see about implementing what you have said. But it is not very likely that is the only problem or possibly even the problem at all. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-03-31 04:41:16
|
| [2015-03-31 05:04:04] |
| i960 - Posts: 360 |
|
Whether they update with a level of 0 or not, the code has to be resilient against that. Regardless of what IB is sending (where they make *no* guarantee they won't send 0.0) it should be ready for anything. Also, I'm not talking about spread contracts, I'm talking about the spread between bid/ask and missing levels because there are legitimately *no* bids or asks there. The way the insert portion of the code is working is that it's assuming a contiguous arrival of data. It should not assume this - it should assume it's working with sparse data because event orders are never guaranteed. There's a lot of pre-optimization going on here with no actual measurement of the amount of inserts vs deletes vs updates. The vast majority of market depth data for futures contracts is most likely going to be updates. Inserts and deletes are probably a very low percentage of the actual messages so if the for loop has to check up to MAX_NUM_DOM_LEVELS in order to be *correct* it should just do that. I bet if the code were profiled very little time would even be spent in the insert or delete cases. Like I said, if you want to increase the efficiency of that loop processing, simply use a separate tracking variable for used size rather than iterating all the way up to MAX_NUM_DOM_LEVELS on deletes. Checking for price or volume equal to 0 is not robust. But also like I said, the micro efficiency improvement might not be worth the additional complexity if it lends itself to incorrectness of brittleness. I'm curious to see what the TempDomStructure.Volume change actually does in the real world, but I suspect any 0 price 0 size messages for a given position might still screw up elements that are after that position because the insert loop will break earlier than it should. |
| [2015-03-31 05:07:46] |
| i960 - Posts: 360 |
|
The way we see this, is there is too much tolerance to substandard programming from an external service and because of the uncooperative nature of the external service
This is the real world. All code must assume defensiveness to a certain degree. I do not think IB is sending you raw trash data that's unworkable 100% of the time. I think there are issue, of course, but absolutely nothing that cannot be worked around. I do think the SC client code is making assumptions about how the data is being sent that it shouldn't be making - because those assumptions lend themselves precisely to this scenario happening. Even then, it does not matter, because this is not about what we think of IB's datafeed. If SC achieves a stronger and wider userbase because it also supports IB in a solid fashion that's only to your and our benefit. Just comment out the break and the problem will most likely go away at very little performance impact due to the most likely low occurrence of inserts vs updates. It's a code path that's only used by people who set clear out of order to false anyway (atleast that I know of). Date Time Of Last Edit: 2015-03-31 05:10:03
|
| [2015-03-31 05:17:33] |
| i960 - Posts: 360 |
|
Also, if you want to provide me a dev version that simply logs all market depth data (mainly the args that function to a file) I can run that and provide back any details when I see things go awry. It would probably help too if it dumped the Price and Volume members of each level of the DomToUpdate array on modifications. I suspect that data along with the input args would show pretty much what's going on.
|
To post a message in this thread, you need to log in with your Sierra Chart account: