|
||||||||||||||||
Q: When I initiate a refresh, let's say 20 hours, it begins refreshing, I can see the refreshed periods in the top of the window. Then the readout changes to Ensign Windows, (no "Refresh finished" readout), and nothing happens on the chart. Sometimes, when I try it 4-5 times, I manage to refresh some hours, but not 20 hours.
A: IB implemented new behavior starting with version TWS 856.7. After issuing more than 60 backfill requests within 10 minutes, all subsequent requests fail with Error 162, “historical data request pacing violation”. Note that 60 requests means as little as backfilling one month back of 1-minute data for 12 symbols only (in one request you can ask for data maximum 5 days long). The 20-Hour refresh request issues 36 backfill requests (each hour of data requires 2 requests when refreshing any tick based chart).
The Pacing Violation error can also be triggered by making requests without a 1 second pause separation. The current version of Ensign Windows imposes a minimum 1 second spacing between requests to avoid triggering this Pacing Violation error.
You will have to make fewer refresh requests to avoid triggering the error with 60 requests within 10-minutes. You are encouraged to avoid Refresh | 2 Months on intra-day charts and Refresh | 20-Hours on tick based charts because these refreshes are accomplished using multiple backfill requests. The Refresh | Maximum for intra-day charts, and Refresh | Today (DTN) for tick based charts automatically switch over to download data from the DTN Market Access source. Significant improvements to the IB refresh were made in the new Ensign on 02-06-2008.
Two gauges on the Setup | Connection form show the status of the IB refresh for the capacity of the IB pacing restriction and the pending requests that will yet be made to complete the refresh for the chart. IB has a pacing restriction of 60 requests in a 10-min period, and that is reflected by the upper gauge. As requests are made the gauge moves toward the right. As time passes and earlier requests become more than 10 minutes in the past, the gauge moves leftward to indicate available capacity to send more requests. When the gauge is at 100% the limit maximum has been reached and Ensign Windows must wait for time to pass. Sending any requests when 60 have already been sent in the past 10 minutes would just be rejected by IB and trigger a pacing violation error. The requests are queued and will be sent by Ensign when permitted. When the refresh for a chart is initiated the lower gauge would be at 100% and as the requests are sent to IB the lower gauge will move leftward. The refresh is complete when the gauge reaches zero. With the improvements made on 02-06-2008, the IB refresh will process faster than it was, and be better at resuming after the max requests have been sent and time passes to avoid the pacing violation. The daily refresh from IB is also fast like in the old Ensign. All of these changes for IB refresh amount to being significant, and our IB audience is encouraged to upgrade and be happier about the IB refresh challenges. IB refresh is still much slower and more difficult to get than the refresh from other vendors.... but when they use IB they have not other choice if they do not want to use the DTN Market Access refresh DTN Market Access The advantage of the DTN refresh is its speed and the amount of back data. The disadvantage of the DTN refresh is the tick counts differ from the IB live feed, and it is through a delay requirement, and DTN does not cover all the markets covered by IB. DTN refresh should be used when possible because of the speed advantage, and it does not count toward the IB pacing restriction. Last modified 2/6/08 5:48 PM |
||||||||||||||||
