- ago
Scenario:
WL8 Build 31
Provider is TD Ameritrade, using build 11
TD Ameritrade token is up-to-date
Cleared internal request tracking info per Eugene's instructions in another post.
Scale is one minute.
Existing data set has only one symbol - RBLX.
RBLX had existing 91,025 bars of data
Ran a very simple test strategy, as a back test, that just buys at market and sells 100 bars later. The back test itself ran fast, it was the data fetch that was slow...
Data was 6 bars behind being current. That is, it had only 6 minutes (bars) of missing data.
Fetching the data took 2 minutes, 10 seconds to get what was eventually 8 bars.
Data Manager, data set update, exhibits similar performance issue.

So, I tried another symbol APVO and deleted its existing data. The data update was very fast (sub one second). That fetch was around 3000 bars.

So, it seems the more bars that already exist in the dataset then the longer the update takes, even if its only a few bars behind being current.

0
205
Solved
3 Replies

Reply

Bookmark

Sort
Cone8
 ( 24.57% )
- ago
#1
The TDA Provider isn't a problem. Even if TDA was serving data too slowly (it's not), we can't change that.

Probably you've checked bunch of Event Providers and that will result in delays. Uncheck Event Providers that you don't need to trade (or test) with.
1
Best Answer
- ago
#2
Unchecking all Historical Data providers except TD Ameritrade, and unchecking all event providers solved the issue (don't use the events, anyhow). Response is now typically sub-second even with 121,000 existing bars for a symbol. Thanks.
0
Cone8
 ( 24.57% )
- ago
#3
Great.
You can leave checked the historical providers that you want to use. Just put them in your priority order top to bottom. After querying the provider from the "linked DataSet" first for updated data... if that fails... WealthLab will use the first checked provider in the list that has the data.
0

Reply

Bookmark

Sort