Keyboard Shortcuts
Likes
Search
QQQ 1 Minute Data >6years?
|
Hmm. I use no set timeouts and I do not cancel nor restart requests. But I perform historical data downloads in reverse time order (and I know several other members do that, too). When you make a request you specify the "end date and time" plus a duration, but you may or may not get data for that entire duration. So once you receive data, simply start the next request based upon the earliest time stamp you received. I am wondering whether your delays are caused because you make requests in ascending time order. That might go against the IBKRs ability of prefetching and pipelining the data for you. For a download of 1min data with 1day duration that started at 2018-06-03 and ended at 2018-05-01 (in reverse time order) I get the following delays between request and data arrival (in seconds): 1, 1, 6, 1, 7, 6, 7, 18, 19, 1, 1, 6, 6, 6, 7, 12, 24, 1, 1, 6, 6, 1, 6 That is the kind of pattern I see for longer downloads, too. 闯ü谤驳别苍 ? On Wed, Feb 5, 2025 at 10:16 AM, David Armour wrote:
|
|
Hi Dale,
?
Perhaps you missed it in the long discussion below, but that is exactly what was done. I am unable to get data before 5th June 2018.
?
Somehow, Jurgen is able to though.
?
I suspect there is some difference in the call to reqHistoricalData() somewhere. For example, I am using the UTC format YYYYMMDD-HH:mm:ss but I believe that Jurgen is using the format like "YYYYMMDD HH:mm:ss US/EASTERN" as he mentioned it below. Not sure why that would make a difference.
?
? |
|
Hi Jurgen,
?
How does that work when you get no data and no historicalDataEnd() callback? If you have no timeout then your code would just hang wouldn't it?
?
I used to download backwards, but it gave me other problems so I reversed it. I always check once I have received the historicalDataEnd() that I received the expected number of bars. So far, I have never had an error for missing bars. (I have a function to manage holidays and short trading days.)
?
I must say your delays seem long to me, but I have never checked mine other than they are all less than 15secs (based on my start latch timeout). I only ever got a timeout after 15secs with problems like the one I am facing now with QQQ. I have downloaded hundreds of symbols with long histories of 1min and 5min bars so this is not stated without some experience.
?
This is just one of those problems that IB throws at us now and again with data.
?
Going to sleep on it. May try using a different timestamp format tomorrow and see if that has any impact. Cannot really think of anything else to try.
?
? |
|
I can't believe that the date/time format has any impact. I went with the "Date/Time in the instrument's time zone" approach a long time ago. The only major difference between our approaches is the direction of time for a sequence of requests. I don't use historical data download that much, but I don't recall a case where a request would hang forever (in other words no historicalDataEnd() or error() callback). My client is entirely event driven and basically sends the next request upon the receipt of the previous request's historicalDataEnd() callback. Though the framework between the client and TWS API handles collecting bars and returning all bars for a request as a list of bars. 闯ü谤驳别苍 ? ? On Wed, Feb 5, 2025 at 11:03 AM, David Armour wrote:
|