||Mar 26, 2008 09:40 AM
||Apr 23, 2021 01:37 PM
||Apr 24, 2021 04:25 AM
Roberts has contributed to 37 posts out of 20340 total posts
(0.18%) in 4,923 days (0.01 posts per day).
20 Most recent posts:
Unfortunately, the data guys got the ex-date wrong. It's today 04/23/2021, not 04/22/2021. Can you get them to adjust that, please?
F,VXX,12,,58583000,45.0300,9.7300,21.7600,9.7300,0.0000,,,,,,,,,IPATH SER B S&P 500 VIX SHORT-TERM FUTURES ETN,VXX1,,1.00,,11570.0,,,,101585,4.00 04/22/2021,,14,4,,52.88,1,18,06/12/2020,04/16/2021,01/29/2021,04/16/2021,16.7900,,,,,0,,,,,,USD,,,,,BBG00JQ5JWB5,3,
Disregard the split in 2017. That one was for the previous VXX series, which was delisted.
I'm looking at both! You should know me by now ;)
I understand that only Daily is adjusted by IQFeed. We use the Fundamental message to adjust our intraday data too.
VXX reverse split 1:4 today, 04/23/2021
And, the Fundamental string isn't returned the penultimate split either - 1:4 on 08/23/2017:
F,VXX,12,,58583000,45.0300,9.7300,21.7600,9.7300,0.0000,,,,,,,,,IPATH SER B S&P 500 VIX SHORT-TERM FUTURES ETN,VXX1,,1.00,,11570.0,,,,101585,,,14,4,,52.88,1,18,06/12/2020,04/16/2021,01/29/2021,04/16/2021,16.7900,,,,,0,,,,,,USD,,,,,BBG00JQ5JWB5,3,
A customer is having trouble with streaming data for Indices, like VIX.XO and VIX3M.XO. From the description, there appear to be no updates, which are expected at least every 15 seconds for these instruments.
Is it possible that these are updated only as a "P" Summary message? (Our Dev feed doesn't have perms for these indices.)
Yes! Getting it now, thanks.
FNGU is still missing its recent 10:1 split event on 2/12/2021. Can you add that to the Fundamental message, please?
(The Daily data are adjusted, but we need that Split event to adjust the intraday properly.)
Edited by Roberts on Apr 15, 2021 at 04:56 AM
Edited by Roberts on Apr 15, 2021 at 04:56 AM
Newman! (said like Jerry Seinfeld)
Thanks for spamming my topic with your completely unrelated opinion.
But since we're doing that, let's do some more shameless promotion and make sure to visit https://www.wealth-lab.com after March 1st, 2021 to get your all-new Wealth-Lab Version 7. It will most certainly "help to improve and improve the efficiency of trading" (sic.) with auto-trading connections to stock, futures, and crypto-currency brokers, multi-core optimizations, intraday strategy monitoring of complete watchlists, and much, much more.
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.