||Apr 22, 2012 10:27 AM
||Nov 1, 2017 12:20 PM
||Nov 2, 2017 10:27 AM
pedro01 has contributed to 16 posts out of 19044 total posts
(0.08%) in 2,554 days (0.01 posts per day).
20 Most recent posts:
I'd like to use the Symbol Download to grab a list of NASDAQ equities.
I am making a request for "ListedMarket" and filter value 5 (NASDAQ)
The first row returned is this:
NASDAQ .X 5 6 : SPDR S&P U.S. CONSUMER DISCRETIONARY SEL
The final row (number 9562) is this:
NASDAQ ZVZZC.TC.X 5 6 : NEXTSHARES ETMF TEST
I don't see any equities in there - just Security Type 6 rows.
Any idea what I'm doing wrong here?
I replied to your emails but didn't get any further responses.
Could you give me an update please?
I've been going back and forth with a client over the amount of trades "between" the bid offer based on the IQFeed level 1 feed from BM&F Bovespa. That has involved discussions with the exchange.
Let me show an example.
This screen shot is from the exchange.
As you can see from the book, we have 8 offers at 3122.50 totaling 45 contracts.
On the right, we see on the audit trail, a buy side order come in for 50 hitting into 3122.50. So the transactions took place at the offer price of 3122.50.
Bovespa explained that a buy order (ID 74261032171) come in on 11:11:51.366 and consumed eight sell orders (ID 74261031869 until 74261032159).
After that, there remained 5 lot of original buy order. Then a sell order (ID 742610312175) come in and consumed it.
Now we look at the data from IQFeed (using Ninja).
We can see a couple of things.
1 - when the order came in @ 22.50, the bid/ask according to IQFeed is 22.5/23. It's as if the bid/ask got updated before we got the order message and not vice-versa. So what should have been "at ask 22.50" is shown at bid 22.50
2 - We can see the top order on time & sales is reported between the bid/ask when Bovespa are saying otherwise.
We've been through a lot of these scenarios over the past weeks and I think there is a glitch in the data which is causing both between trades that are not between as well as trades reported at bid that are really at ask.
I would not be reporting this if I had not gone through it with my client and also had him walk through the trades with the exchange.
Is this something you could take a look at?
Edited by pedro01 on Jun 9, 2015 at 11:24 PM
That's very much appreciated guys!
So let me get this right.
If there are errors in your data you will never fix them as you presume people will have already coded around them? I don't agree with that presumption. I think what you will find is people are simply not using ExchangeRoot because it doesn't make sense to 'fix' it programmatically.
Think about it - how do you think people will have coded around this specifically? People will have made their own mappings, not taken your incorrect symbols and decided to add characters that you removed at random.
You DO have a few of options here.
1 - you could add another field showing the correct id
2 - you could poll the developer partners to see if anyone objects to putting it right.
People use IQFeed to write trading systems. We cannot place trades thru IQFeed, so you must understand that to map symbols to broker feeds, the Exchange Root is all we have. Without that being correct, you leave us with a ton of work on manually creating mapping tables - because you don't give us that either.
Option 3 of course is to give us mapping tables for all products that we could incorporate into our software.
I think "can't do anything" is not the best way to handle this.
And this is just a string - how can there be a "system limitation" of 3 characters on what is one of the most important pieces of information about an instrument? Your description isn't limited to 3 characters
Edited by pedro01 on May 26, 2015 at 08:30 AM
Thanks Tim - it really does look like the "F"s have been taken out....
No F'in symbol....
Here's the documentation on the "Fundamental Message Format"
As you can see the last item in the list is "Exchange Root" and the description is "The root symbol that you can find this symbol listed under at the exchange."
I don't think you are following me.
on IQFeed the bund is "BL" - I get that, understand it 100%.
But you have a fundamental data download on your API. It gives us a number of properties for an instrument - 50 or so properties.
So for BL, I can do a fundamental data request and it'll give me a bunch of properties. One of the properties is Exchange Root. And for BL you have that as GBL instead of FGBL.
You seem to have dropped the "F" off most of the symbols -funny thing is - you seem to have dropped the F wherever it is in the symbol. So your "CO" (EUREX SWISS GOV BOND CONF) on Eurex has an exchange Root of "CON" instead of CONF.
So it appears your developers have cut the "F" from the Exchange Root wherever it appears. whilst most Eurex Futures do have an exchange Root beginning with "F", they don't all have it.
This is not about IQFeed unique symbols - this is where you store the Exchange Root...
Edited by pedro01 on May 26, 2015 at 07:02 AM
I am using the "Exchange Root" from the fundamental data for Eurex symbols.
For some reason the exchange roots are different from those given out by Eurex themselves.
So for the BOBL, the code on Eurex is "FGBM" but according to the fundamental data download the Exchange code is "GBM".
Is there any reason for it or is this a glitch in the data? There is no GBM trading on Eurex.
This is the case for many Eurex instruments. Is there some method by which you are coming to these adjusted exchange symbols or is it just a glitch in the data?
Here's the codes: http://www.eurexchange.com/exchange-en/products/int/fix/government-bonds/Euro-Bobl-Futures/15644
And here's the fundamental data message:
Let me know
Edited by pedro01 on May 25, 2015 at 11:55 AM
Edited by pedro01 on May 25, 2015 at 08:56 PM
Can you clarify something
"if you look at the current feed and see multiple trades at the same time and price (but different sizes), those will typically be bundled into a single trade going forward with MDP 3.0"
When you say time price - what price granularity is that? Is it trades at the same second, millisecond or other?
Also - is it only trades hitting the same side too? So for instance if a trade hits the offer at 2000 and price ticks up and the next trade hits the bid at 2000 is there a chance they will be bundled?
Thanks for that Todd - if you need any help with testing that, I'll be happy to spend time on it.
It's not really a view, Todd. It's the way the contract is traded and the way people analyse historical data, especially with products such as I/RT and MarketDelta.
I can't use the July contract because I'm using I/RT with the volume profiles & therefore I need a continuous contract so that I can work with current data on the active contract and also see historical data going back a few years.
Is this something you are or aren't going to address? I ask that because the person on support I spoke to said it was something being worked on whilst you imply this is just my opinion.
The historical data will be spotty too because for people that use volume profiles, there's going to be 2-3 weeks of low volume when next contract starts being traded.
Right now the continuous Corn contract is still looking at the May-12 contract prices.
It's 11:00 EST an the volumes for the day so far are:
ZC 05-12 - 2,190
ZC 07-12 - 46,120
Obviously, May is done now. I spoke to support and apparently, we won't see the continuous reflecting Junes prices until the May contract closes. That's almost 2 weeks.
Is there anything I can do about this?
I hear you.
It's a bit frustrating. The "filtered" feeds out there are more in synch but their Time & Sales data is out.
The ideal service for anyone using order flow would be an unfiltered L1 feed combines with a filtered L2 feed. No-one needs every depth message.
Is there any way to throttle back the L2 feed? For example, you don't really need every change to every level. You do need to know when price moves but you could filter out a lot of the L2 messages....
Edited by pedro01 on Apr 24, 2012 at 08:49 AM
Thanks for the reply.
Does that mean I just have to live with the issue and that you guys are not looking into it?
Watch this video from 1:15-> 2:00
For a day trader/scalper, it's impossible to trade from it.
Even when I cut down to just 1 DOM for the ES, all other data off, it is like this. The bandwidth utilization on my end is very low when this occurs too.
I hate to make my first post here a whine but....
I'm using Ninja & I/RT. I've been using Ninja and your data for quite a while. From 9:30am EST I am focused mostly on the ES..
In extreme cases, the L2 feed drops behind the L1 feed. You can see trades on Time & Sales going through many ticks away from the inside bid/offer. You can also see the last traded price on the DOM way off the inside bid/offer too and you can see that price being actively traded. This happens when there's news and a lot of trades are going through.
The past 2 weeks though, it has been pretty rough, every little surge of trading causes this issue. I managed to grab a picture (attached) which shows the Ninja DOM - this was during market hours and you can see the inside bid/offer is 1366/1366.25 and the trading is going on a few ticks above.
The machine I'm running this on is an i7 with 8GB of Ram. It was running at about 4% CPU Utilization when I took the picture. I had I/RT off and I had all other instruments off too, basically it was just Ninja and the ES.
I was watching bandwidth utilization, it was very low but the internal loopback connection for iqfeed was about 4 times higher than the external bandwidth, which I thought odd.
Like I said, this was happening all last week. I spoke to a fellow trader who's been a DTN.IQ customer for a month and he was under the impression this was normal. I have been using Kinetick for the past year and although I have had this issue, it's been at times I wouldn't trade anyway, it's not been each time there's a flurry of trading.
Anyway, it seems that something was definitely off last week and I have looked into it being on my side but have drawn a blank so far.
Edited by pedro01 on Apr 22, 2012 at 10:46 AM