QTusers Forum
February 11, 2012, 04:49:11 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Welcome to the QuoteTracker Users Discussion Forum
Latest QuoteTracker Version is 3.9.7
Released on April 13th 2010

 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: IB (Interact. Brokers) backfill volume problem  (Read 282 times)
itebakchai
Just Visiting

Posts: 1


« on: March 08, 2010, 04:56:53 AM »

There is a (afaik) well-known problem with the Interactive Brokers backfill:

When performing a historical backfill there will most of the time (in my setup nearly every time) be an artificial volume spike.

This happens obviously when market data is coming in while the backfill takes place.


This is very disturbing to the usage of QT since I need "volume candlestick" charts for my trading approach. The spikes completely disrupt the picture.

Sometimes I can handle the problem by editing the data (press ctrl+D). Sometimes this does not work in the first place, then I have to clear the erroneous data completely, then backfill, then try again to edit.
And sometimes it is even impossible to use (ctrl+D) - the data may not be edited by the user (didn't find out under which conditions, I always have Filter OFF).
This is all quite a bit of work which I have to repeat every day over and over.


Therefore, please:
Think about fixing this problem.

I know that there can be issues with the IB historical backfill.
But: When I look at QT's internal data (through ctrl+D) I can easily see the problem usually.
The volume spike is mostly looking like: Big negative number (which is impossible by definition), big positive number, normal data.
Therefore in my view it should be possible to eliminate the bad data in the program (without having to edit it manually).


Perhaps this link could also be helpful to the QT programmers in order to find a work-around:
http://finance.groups.yahoo.com/group/TWSAPI/message/19921
(Thread: reqMktData and reqHistoricalData requests replied in queue's order?)


A partial yet helpful solution that would already help all the users that struggle with this would be to make sure that the data may be edited (ctrl+D) in any case and QT never get into the way and block the user from editing.
Logged
jd777
Trader
***
Posts: 41


« Reply #1 on: March 11, 2010, 12:55:01 AM »

This problem is YEARS old and will likely not be fixed or addressed.

 The excuse has always been that QT is compensating for the total volume reported VS the actual bar volume for the day.  In other words of the total is 100,000, and the bars add up to only 90,000, they tack on 10,000 to the last bar.

 Im pretty sure thats the nature of the problem.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.7 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!