||Mar 26, 2008 09:40 AM
||Dec 2, 2020 07:46 AM
||Dec 2, 2020 07:46 AM
Roberts has contributed to 29 posts out of 19969 total posts
(0.15%) in 4,690 days (0.01 posts per day).
20 Most recent posts:
If it's turned on, you'll get an incomplete BU message whenever a new tick has a trade in it.
.. but you'll get that message only after the Update Interval. Sure, we can put that at 1 second and have at most a 1 second delay, which is acceptable, but it certainly complicates the adapter. Instead of just passing along the final result when it arrives, we'll have store the last BU message, and, if the BC message doesn't come in before 1 second after the interval, we use the last BU data, and, later have to ignore the next BC message. Not joy, but it is what it is.
Thanks for the link. Now I understand BU much better, because that was unclear too. (If I had requested 15 second updates, I was expecting updates at :00, :15, :30 and :45 seconds every minute, which is not how that works either.)
Quoting Tim Walter from your first link, "The answer, due to the impossibility of syncing all clocks involved and the random latencies between connections, was to say that a bar complete message is only sent when a new message, with a time that is outside of the current bar, is received. So that is why BC messages are not timely."
It's understandable that DTN wants the data to match perfectly, but it sure doesn't seem like a good design decision based on the tradeoffs that require the consumer to use a work-around that is even less perfect and that still doesn't provide a timely bar without building one ourselves using updates. IQFeed already provides a TimeMessage that we use as a heartbeat to "close" intervals precisely on time so that strategies can be executed. We've used this design for 20 years in streaming charts and sure seems like an easy solution to implement for a "BC" message too. If the 99% of the user base expects this, what's the problem?
Our solution may be to toss the whole concept and simply subscribe to hundreds of streams instead. That's worse for the user's cpu and has gotta be worse for the DTN backend.
I actually think I see what's happening. TTD doesn't print it's complete interval until a full lot trade occurs in the next interval. There's got to be a way around that, right?
Oh my gosh, thank you. You hit the nail on the head!
In these initial tests, I'm watching just 2 symbols, AAPL and TTD, at 1 minute intervals. Very commonly, I'll see AAPL update 1 or 2 seconds after the end of interval (good), but TTD's update for the same bar interval will come maybe to 60 seconds later (not good). I'm just looking at the Debug prints from the callback, so I'm not sure how my program could create that delayed effect. Does that sound like something to expect?
I've got 2 different implementations in 2 applications performing Bar Watches (BW) without any problem. But I'm having trouble with a new, 3rd implementation, and I'm looking for clues.
1. I'm connecting to the Derivative port 9400.
2. IQFeed returns "S,SERVER CONNECTED" in the socket's callback
3. Example: "BW,IBM,60,,,,,,req1,,,0
... and then nothing else is returned in the callback. No errors, nothing.
I've played around with the optional fields in the BW message, but nothing changes. Any ideas?
Would you process the 4:1 split on 3/24/2016 in the Daily series for DRIP, please?
And TREX charts at TDAmeritrade are still not adjusted. Another conspiracy theory out the window!
2 days after ex-date. TREX daily history is still not adjusted. I'm looking at it in TDAmeritrade and it's not adjusted there either. Really strange this one!
TREX when ex-split today. The partial daily bar from today, reflects the split (of course). However, the history bars prior to the ex-date are not split yet. Why is that? When does that happen and does it depend on the exchange?
Looks good now. SF2 is empty. Thanks.
I just grabbed the message after reading your post and got this:
F,XLF,7,,57698000,31.3800,17.4900,31.3800,17.4900,2.4700,0.1516,0.6115,06/25/2020,06/22/2020,,,,,FINANCIAL SELECT SECTOR SPDR,,,1.20,,186563.0,,,,744245,0.81 09/19/2016,1231.00 02/22/2008,...
Indeed, Split Factor 1 was corrected, but Split Factor 2 should be empty. The factor 1231 is an artifact of the divisor for Split Factor 1 (1000/1231 = approx. 0.81), and its date is fictitious.
Is this a good place to report data errors?
The fundamental message returned just now for XLF begins like this, with the record truncated after Split Factor 2
F,XLF,7,,57698000,31.3800,17.4900,31.3800,17.4900,2.4700,0.1516,0.6115,06/25/2020,06/22/2020,,,,,FINANCIAL SELECT SECTOR SPDR,,,1.20,,186563.0,,,,744245,1000.00 09/19/2016,1231.00 05/04/2007,...
An hour earlier, this came in...
F,XLF,7,,57698000,31.3800,17.4900,31.3800,17.4900,2.4700,0.1516,0.6115,06/25/2020,06/22/2020,,,,,FINANCIAL SELECT SECTOR SPDR,,,1.20,,186563.0,,,,744245,1000.00 09/19/2016,1231.00 07/01/2002,....
I only noticed this because a customer reported that the date he got for Split Factor 2 was 10/12/2010.
Besides the changing date for this "split", a bigger problem is that there has never been a second split for XLF. There should only be the first on 9/19/2016, whose factor should be 1000/1231 (approximately). In reality, the factor should be 1/1.23167675 which is really a back-adjusment for a special dividend of $4.44346/share.
Thanks Gary. It's good to know. Despite that inconsistency, I've figured out a way to keep it all straight anyway by recording the first time a new split appears in the message and comparing it to the last data file write time. Knowing the Date/Time of end of the session before the ex-date, we can process a split for intraday data when appropriate.
Can you explain the Fundamental message for TREX then? Split Factor 1 is "0.50 09/15/2020".
Checking other sources, this one is curious because the "Record Date" is 8/19/2020, but the Ex-Date is 9/15/2020. Most often record dates are on or even 1 day after the ex-date. Does the record date influence when the split appears in the Fundamental Message?
Apologies for the hassle, but I'm trying to determine a method to split intraday history using Split Factor 1 (and other meta data).
Thanks teresa. Let me run something else by you...
On Monday 31 Aug, TSLA and AAPL will both start trading ex-split. Here's the problem - I just checked today (Saturday morning 29 Aug) that the splits don't appear in the Fundamental Message.
Our customers generate trading alerts based on the closed session's data. Imagine an alert to by 25 shares of AAPL at a $490 limit. This order will be transmitted to the broker (and if the broker doesn't automatically cancel it) this order will execute at market. We need to adjust the data before the ex-date. Consequently, adjusting for the 4:1 split, the strategy would correctly generate an order to buy 100 shares at $122.50.
The best solution would be post that adjustment before the ex-date - it could even be days before. Just like DTN does for pending dividends, post a pending split in the Fundamental Message so clients can adjust as required and when required. This would be a GREAT help!
Thanks Stephen. Really appreciated.
I just discovered that the Split Factor 1 and 2 items in the Fundamental Message are limited to 2 decimal precision! That's too imprecise for common 1.5:1 or 3:1 splits (and also 6:1, 7:1, etc). I use these values to adjust the intraday data and the Daily cache when a new split arrives.
Take the 7:1 AAPL split on 6/9/2014. The factor given is 0.14 instead of 0.142857143. However, the IQFeed daily data appears to be adjusted using more precision - even though the data are only precise to 4-decimals.
Can IQFeed increase the decimal precision of the split factor to at least 8 decimals? 6?
Heads up for AAPL and TSLA on 8/31 ;)
fwiw, I second the motion for a variable LAN IP. Many of the customers we're sending to IQFeed now run Wealth-Lab on two machines simultaneously.
This morning is 8/19/2020 and I'm requesting data for 3 stocks whose split ex-date was *yesterday* 8/18/2020. QLD (2:1), SSO (2:1), and SQQQ (1:5). The first two are still not returning split data and their splits are not identified in the Fundamental message. SQQQ, however, is okay. When can we generally expect splits to be processed?
SSO Split Factor 1: 0.50 05/20/2015
SSO Split Factor 2:
QLD Split Factor 1: 0.50 07/17/2017
QLD Split Factor 2: 0.50 05/20/2015
SQQQ Split Factor 1: 5.00 08/18/2020
SQQQ Split Factor 2: 4.00 05/24/2019