Problem with OnMarketData()

March 18th, 2015, 12:06 PM

rleplae

Hello @ratfink

I am on IQfeed

Is there any risk that data comes in, that is back-fill data ?
I thought there was a mechanism, during a spike, when too much data comes, that IQfeed will try to catch
up with the most recent and then later fill in the gap ?

The code seems to build on the fact that data always comes in sequential

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.

Mike

March 18th, 2015, 12:27 PM

Big Mike

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.

Mike

@Big Mike,

Were you subscribed to the L2 data for all 200 symbols or just the L1?

March 18th, 2015, 01:50 PM

Hi Ron, @rleplae

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.

Cheers

March 18th, 2015, 02:01 PM

Hi Ron @rleplae,

This is my current adjustment I use with a dynamically allocated array system I use to talk elsewhere with:

Code

	DateTime t = Bars.GetTime(CurrentBar);
					
	// correct for Ninja's stupid use of future timestamps on time based series, other's are ok
	if (BarsPeriod.BasePeriodType == PeriodType.Minute)
	{
		t = t.AddMinutes(-BarsPeriod.BasePeriodValue);
	}
	else if (BarsPeriod.BasePeriodType == PeriodType.Second)
	{
		t = t.AddSeconds(-BarsPeriod.BasePeriodValue);
	}

There are other smarter ways I'm sure, but I need simple.

March 18th, 2015, 02:20 PM

NJAMC

... but with the Data/Depth tick data. The problem only occurs when you have MTF with the same instrument with different time periods. The BIP will not be updated properly on these calls.

Thanks for the heads-up, that's also irksome.

March 18th, 2015, 11:06 PM

NJAMC

@Big Mike,

Were you subscribed to the L2 data for all 200 symbols or just the L1?

L2

Sent from my phone

March 19th, 2015, 04:02 AM

TCP guarantees in-order delivery, so it is true.

March 19th, 2015, 04:10 AM

artemiso

If I understand your questions correctly, it is really three-fold: (1) You are asking if the "live" data is mixed with "historical data", and (2) if it is not mixed, you want to know if the "live" data is guaranteed to be in correct sequence. (3) Regardless of the order of data, you want to know if a "spike of data" is an issue.

Regarding (1), historical backfill and L1/L2 subscription are treated as different requests, so you will never receive a mix of historical and "live" data. In a C++ implementation:

Code

void IQLevel1Controller::subscribeToSymbol(const string &symbol) {
    boost::format formatter("w%1%\r\n");
    string message = str(formatter % symbol);
    tcpClient->write(message);
}

Code

void IQHistoricalLookupController::getHistoricalTickDataForSymbol(const string &symbol) {
    boost::format formatter("HTT,%1%,%2%,%3%,,,,1,%4%\r\n");
    string message = str(formatter % symbol % beginTimeString % endTimeString % DATA_MESSAGE_PREFIX);
    tcpClient->write(message);
}

Regarding (2), TCP has a handshake mechanism that guarantees in-order delivery, so it is true that the data always comes in a stream in the same sequence as it was sent to you.

Thanks Artisimo

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

regards,
Ron

March 19th, 2015, 04:21 AM

Big Mike

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.

March 19th, 2015, 04:31 AM

@rleplae You're welcome.

Problem with OnMarketData()

Discussion in NinjaTrader

Problem with OnMarketData()