|IB -- Why Dashes are on Your Vol/Tick Charts|
10:56 kf2: I am getting large blocks showing up on er2 which creates hash marks on my vol charts. I questioned it with IB because the blocks could not be matched with market depth showing . IB says those blocks are not coming through as shown in Ensign. I am wondering if you care to take this issue up?
10:57 Ensign Howard: kf2, we will insert a tick with a volume to catch up the incremental change in total volume. So as example, if they have total volume at 13,400 and then send 1 tick with volume of 10 but the total volume is now at 13,510 then we have detected a missing tick or ticks that would account for the change of 110 volume when only 10 is accounted for with the last tick, and we will insert another tick with 100 tick volume to 'catch up' the missing volume tick. Our one tick at 100 might be what you are seeing as the 'block' that they did not send. We have no way of knowing if the 100 was really 2 or more ticks, that summed to 100. But you want the volume charts to be right and so we insert a tick to account for the change in total volume
11:00 kf2: I am getting hash marks on my vol charts. the huge vol doesn't match with IB's time and sales and when I refresh with DTN they disappear
11:00 Ensign Howard: We all know already that IB does not send every tick on the feed, so this is our attempt to make the feed better than it is. Refresh by DTN changes the hash marks into bars by sending all the ticks
11:01 kf2: You are saying that they are sending ticks without volume?
11:02 Ensign Howard: No, did not say that at all
11:02 kf2: good
11:02 Ensign Howard: IB does not send all ticks. The example given was a good example. Total volume last seen at 13,400, then next tick total volume jumps to 13,510 but the tick volume is 10. So we have to do something to account for the missing ticks that would have accounted for the change from 13400 to 13510
11:03 kf2: So a cumulative block of vol of say 1000 comes across with no tick, so you insert the ticks?
11:04 Ensign Howard: We never receive volume except with a tick
11:04 kf2: I don't see how your example explains what I am seeing then. I apologize for my apparent density.
11:04 Ensign Howard: Will see TOTAL VOLUME has changed more than the Tick Volume will account for so we invent a tick with the difference in Total Volume as its tick volume
11:05 kf2: ok , that makes sense, the total vol increases without the supporting data
11:05 Ensign Howard: We will use as tick volume the change in total volume to catch up the volume, and use current price as the trade price. It is the constant tick charts that need this invented tick to stay current with the total volume
11:07 kf2: I am using constant volume charts
11:07 Ensign Howard: Yes, that I guessed already. So what you see is a result of the program trying to improve on the IB feed. IB is right in saying the did not send the block tick..... true, in fact, they did not send it or several ticks and that is the root of the problem... they should have sent all ticks but they don't
11:11 kf2: Does esignal do a better job of sending all the ticks?
11:12 Ensign Howard: yes, but you will pay a lot more money for the feed plus exchange fees
11:12 kf2: It was not an issue before yesterday - also esignal will have terrible lag was my experience
11:12 Ensign Howard: And I doubt it has become an issue
19:00 Ensign Howard: One workaround that applies to the tip is the click menu Setup| Charts and uncheck the Cap Constant Volume Bars check box. This way the big volume that causes the spawning of multiple volume bars at one price will be absorbed into a single bar and thus no sideways spawned bars will be on the chart.
Last updated 09/17/2006