||Apr 25, 2006 12:17 PM
||Yesterday @ 12:36 PM
||Today @ 08:21 AM
||DTNIQ Customer Support Representative
DTN_Tim Walter has contributed to 1198 posts out of 18633 total posts
(6.43%) in 4,496 days (0.27 posts per day).
20 Most recent posts:
I'll take a look at it today.
Sorry for the confusion it caused and thanks for the assist Altmany.
The problem is that the filtering of the data is done on your machine via IQConnect. So you are correct, that the t vs the w watch will not affect your incoming numbers. I do not have a way to limit this at the server level, but it would certainly have value to many so I will push it up to management on your behalf.
Q1. How do I join the Dev List so I can "TEST OUT" Beta products.
We send out beta notices to all active developers whenever a new version is available.
Q2. Can you provide a link to the LATEST "Options File" - i had the old one and Matt P helped me out on this one.
I am currently doing these manually about once a month, we will have an automated process in the future. They are always posted at the ftp link above. I have updated it per your request.
Q3. Any ETA on the list of the "traded products"
We are still probably a few months away unfortunately.
Correct, that port is only used for internal data and it is what we send the data feed out on, so that usage is expected.
Ok, well try to get me a screenshot of the send/receive numbers per tcp connection, that should give me a clue.
It looks like that number may include local traffic, but if you go to TCP Connections and add the Send and Receive columns to Resource Monitor, then you should be able to see which port is using that bandwidth within the app. I would expect there to be local bandwidth, so maybe that is all this is.
There is very little that IQ does with outbound traffic. Basically, unless you are doing a send, there is not a lot going on for outbound data. What are your applications doing with the data we send, is it maybe pushing data to a database?
Actually, the expiration date is the blank field, the other date is the last traded date.
I'll correct the email above to be accurate. Expiration can be inferred from the symbol, but we will look into that prior to release as well.
I asked for a header, we'll try to get that added to the file before it rolls out to production or at least get it documented.
I'll try to find out what the blank field is as well. But, it is probably security type specific is my guess.
Edited by DTN_Tim Walter on Aug 7, 2018 at 08:33 AM
Not sure what other users have done, but yes, the only way I have seen to run our application on Linux is with a Wine solution, but if anyone has another I would be happy to hear it as well.
Good morning, I just wanted to confirm the answer above is correct. As to the other, I will certainly let the server team know and place an enhancement request with management.
There is some work being done on our website currently and that bumped the automation back, but I did place a file up a couple weeks ago for everything that was expired up to that date if you want to take a look at it.
Good afternoon Frederic,
I will send an email with some detail in a moment,
That is certainly fair, that would also be useful for setting protocols and more.
We'll discuss it and see if it could be worked in sometime for a future release. Thanks for the idea.
Example Before Data
12th : $4.00 $13.00
13th : $4.50 $13.50
14th : $5.00 $14.00
15th : $2.50 $15.00
16th : ------ $15.50
Sure, given the prices above for two corn contracts, and leading up to a roll date on the 15th of Sept.
Up to the 15th @CU18 prices are used, but when the continuous contract rolls to the next month in line, @CZ18, we take the difference between the two closes, (15 - 2.5 = 12.5) and add it to all previous dates.
12th : $16.50 $13.00
13th : $17.00 $13.50
14th : $17.50 $14.00
15th : $15.00 $15.00
16th : ------ $15.50
This results in a chart that goes
12th : $16.50
13th : $17.00
14th : $17.50
15th : $15.00
16th : $15.50
As opposed to:
12th : $4.00
13th : $4.50
14th : $5.00
15th : $2.50
16th : $15.50
Let us know if you need any other clarification.
We do not have any scripts for this kind of thing. But as to the logic for daily, we use the last price of the two relevant contracts and adjust all historical data by the difference to move old data, up or down, to match.
Edited by DTN_Tim Walter on Jul 26, 2018 at 07:43 AM
The link now reads correctly. My apologies. Thanks for pointing it out.
This change was to bring us in line with what it felt like new developers were expecting from us. Many competitors do not provide an option of how to label their intervals and when comparisons were being done, there would invariably be off by one problems. This was to help eliminate that hurdle.
We felt that, since this would not affect any past protocols, that we could add this change without impacting users much. My expectation was that if someone was going to be editing their code anyhow, to update the protocol, then adding the additional parameter to the HIT, HIX, and HID requests would be acceptable.
My apologies if I underestimated that.
Here is a few good ones and an example of one where the exchange appears to be incorrectly labeling them.
These are valid spread trades for today
AKRX1820S12.5: 09:43:47.395378 Tick ID: 12232821 Price: 1.12 Mkt: 13 Size: 30
AKRX1820S7.5: 09:43:47.395386 Tick ID: 12232822 Price: 0.17 Mkt: 13 Size: 30
AKRX1821I17.5: 10:51:16.008986 Tick ID: 52043408 Price: 3.95 Mkt: 16 Size: 8
AKRX1821I27.5: 10:51:16.008986 Tick ID: 52043408 Price: 0.95 Mkt: 16 Size: 8
AKRX1817T12.5: 11:38:03.690677 Tick ID: 73915981 Price: 2.08 Mkt: 9 Size: 11
AKRX1821U10: 11:38:03.690677 Tick ID: 73915981 Price: 1.67 Mkt: 9 Size: 11
This one was flagged as a spread trade from exchange but is actually a BWRT order with a single option leg and stock
AKRX1817H20: 12:57:26.558378 Tick ID: 104690555 Price: 2.10 Mkt: 13 Size: 3
AKRX: 12:57:26.585558 Tick ID: 1126 Price: 15.15 Mkt: Size: 300
Actually, we did find another like the one you mentioned and only the single trade was sent by the exchange. So we do not believe we are missing any data that the exchange has sent.
What conditions cause them to send or not send two trades (in the case of a spread) I can't answer. We have to assume what the exchange is sending is correct when it comes to the input. We will attempt to do what we can from this end, but resolving this issue will be an exchange level issue it appears. If we get anything else back I will keep you in the loop.