Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
IQFeed always delivers ticks in sequence. It's also over TCP, so guaranteed delivery. Other broker type feeds like Rithmic for example don't guarantee in-sequence ticks, and also use UDP. That particular feed also routinely drops Level 2 updates, sacrificing quality for speed (since it is a broker execution feed, not a data feed).
There should never be a "spike" with "too much data". I've documented elsewhere on the forum that even running 200 concurrent symbols will still use minimal bandwidth, IIRC it was less than 1 Mbps. Now, if your platform is not threading correctly or is delayed by bad code (indicator) then of course it just means things will get slow, but the issue is definitely not with IQFeed in this case.
Just in case this is causing any confusion it is worth a mention/reminder of the stupid timestamping issue in Ninja, remember that Ninja time-based bar series get timestamped with a *future* timestamp. This is annoying, to say nothing of being inconsistent with both it's own other bar types and the real world.
So, for example, the first tick of a new bar in a 15 minute series opening at 16:00 will be timestamped 16:15:00, and that timestamp will not change for any subsequent ticks in that same bar. In the meantime the first tick of a new bar in a 5 minute series will get 16:05:00 and same for subsequent, the first and subsequent ticks for the new 1 minute series will get 16:01:00, the first tick of a 12 second series will get 16:00:12, the first tick of it's next bar will get 16:00:24, etc, etc. So you can appear to be getting backfilling data across different series, but you aren't, tedious isn't it, but at least easy to handle/correct for the external world once you know.
The 'apparent' time of other bar type series events is also not guaranteed or consistent either, e.g. a 200 volume series can appear to open before a 1 or 5 volume series, so assume nothing and be not disappointed. Likewise order of bar processing across charts is not preseved across Ninja saves/restores, so again, make no assumptions.
I was aware about IQfeed back-fill capability (that was the reason for me to take IQfeed,
because of OFA indicator, that seemed to work best with that data stream), but have not
been coding it low level enough.
You clearly explain how it works.... as another stream
I did not run into any issue, but because i knew back is possible, but didn't know how it
worked i was just checking if my work would still work in live.
The answer is clearly yes from all sides
Now, if your platform is not threading correctly or is delayed by bad code (indicator) then of course it just means things will get slow, but the issue is definitely not with IQFeed in this case.
Also, just to clarify, there's very little that your program can do to optimize this further.