ZenFire lag

[Big D]

I just let Pat at ZenFire know about this. I'm sure someone knowledgeable will pipe in soon.

[eDanny]

13 seconds @ 14:23 here. That is after restarting the chart @ 13:00 with the new indicator version. Lot's of lag earlier on the old version.

[Big D]

Here is my theory to the lag problem.

I always have my broker's trading app open (Rithmic Trader) at the same time as Ninja Trader. During fast market conditions, if a limit is filled, Rithmic will display the fill immediately, but Ninja will be delayed a little bit. The delay isn't much, usually around 1-2 seconds...it depends on the amount of data streaming in during the fast market conditions. Sometimes, the Ninja DOM will not show the bid/ask prices near my limit order, but I've already seen the fill from Rithmic. Remember this is only during fast market conditions. During normal times, everything works fine.

Rithmic and Ninja both use the same computer, the same internet connection, and the exact same broker connection, ie ZenFire. The only thing different is the application. I think the problem is Ninja and not the other links in the chain.

I've been told Ninja version 7 is much better during fast market conditions. So one more reason, of many, for Ninja to finish the version 7 beta soon.

[Alfred]

NQ current tick lag...

Using VTtraders' TickTimePlot2...in the NQ today with ZF data it looks like over 99% of ticks range between almost 0 and 1 second lag. Very few exceed 1 second..the average looks to be around 0.4 / 0.5 second.

[Alfred]

Here is a larger incident of apparent lag today using TickTimePlotV2...anyone else see something similar ??... Is the indicator accurate, or could this be caused by my computer or is it the data ??...did not see CPU above 50% around the apparent large lag period...

Thanks

[Alfred]

Apparent major tick lags show today at identical times and in identical amounts of lag in the NQ & TF. MY CPU & memory OK.

Is this the indicator, my machine handling ticks or the data ??

[JS999]

Apparent tick lags show today at identical times in NQ & TF. CPU OK.

Is this the indicator, my machine handling ticks or the data ??

I would think that both sets of data are coming in on exactly the same connection to ZenFire, so it would make sense that both are showing the same values...

[Alfred]

JS999...what is your view on the possible root cause of this apparent lag...??

Is this the indicator, my machine handling ticks or the data ??

[JS999]

JS999...what is your view on the possible root cause of this apparent lag...??

Is this the indicator, my machine handling ticks or the data ??

It could be the indicator to some extent... I am not 100% sure how accurate it is. The only way to know for absolutely sure is to place a few small live trades and see how it goes. You should be able to detect a one second lag based on where you are getting filled.

I don't think it's your machine, unless your CPU load was very high. The other possibility is that it really is the data itself, either due to internet lag or the zen-fire servers. But like I said, the only way you will really know is to place some test trades and see what your fills are.

[Alfred]

Here is another example...at 09 24 04 there was an apparent minor burst of lag in both NQ & TF...how it then unfolded on the indicator in each was slightly different.

In post #80 below the screen shot there showed 17 / 18 seconds apparent lag at one point...

My feeling is this is not a case of internet lag (usually) as these lag periods generally happen at a chart point where one would expect a burst of action...seems it must be the indicator or the way NT handles the indicator or the data itself....??

[VTtrader]

I posted before that the indicator can NOT be accurate to the sub-second level, due to the fact that the timestamp only has 1 second accuracy. Each additional tick within that second will appear to have a longer lag. To address that issue, I changed it to be used with 1 second charts, and takes only the first tick, making the assumption that tick will be the one with the least "lag". There is no way of knowing if it really occurred at the beginning of the second or towards the end. The result is, that anything under 1 second is only an approximation based on the assumption I mentioned.

As for the multi-second results, my feeling is that it is showing a lag, between the timestamp and the time it's processed at your computer (although still with accuracy, no better than 1 second). There can be many reasons for this lag.

First would be the PC clock and/or the time syncing process itself. There is an inherent inaccuracy in that process as well. You can get close, but how close is close, and how close is it synced to the ZF server? But again, I don't think it explains multi-second lags, certainly not all of it.

As for the datafeed itself, ZF delivers unfiltered data, so the sheer amount of data is quite high compared to other feeds. About a year ago I compared ZF feed to both TradeStation and and DTN/IQ. All seemed to do pretty well, although with TradeStaion I did see some times where it seemed like it was "catching up" with the data, it seemed like it was "buffered" somewhere along the line, and then supplied the missing ticks when it had a chance. When I compared ZF to DTN/IQ, I found that there were up to 15-30% more tick bars between a given swing high and low, showing that ZF is simply supplying more data. Most datafeeds filter, aggregate, drop or buffer ticks during busy periods, so that the data can "keep up", ZF doesn't.

This unfiltered data creates an overhead that stresses the entire data delivery system during heavy volume periods, especially with the flash and high frequency trading methods. It creates an extra load at the ZF servers, and at every router, at every hop along the route to your ISP, in addition to the load that it puts on your ISP's routers and your home network. It can also be affected by shared bandwidth limitations from users in other locations with a cable internet system.

Now ZF does have an obligation to keep their servers and network adequately maintained and sized to accommodate the traffic, but it is only one leg of getting that data to your computer, and there is no way of knowing where the lag comes from. Alternatively, they could filter the ticks like other feeds, but to me, that is not the best solution.

One further recent change is the way that the CME has unbundled their ticks, that has increased the amount of data that has to be delivered.

I pointed out in another post that my purpose for using the indictor is to give me an idea of when my data is lagged, and that it is probably not a good time to place an order, since there is really no way of knowing where the actual market is at the time, then I can choose not to trade at those times. I use it basically like "pinging" the server (although you can't ping ZF servers) to determine the amount of latency. At those times, I don't really know or care where the lag comes from, I just know not to trust the data, and to not trade.

It was pointed out earlier in this thread from Ray, that ZF had detected a bottleneck, and was making the needed changes. He also mentioned that it was a problem "only for interent customers", that gives some insight to the situation. ZF obviously has many customers that do not connect via the "internet", their connections are going to be MUCH faster, and your internet connection will never be that fast...but that is your competion. Trading over the internet is an imperfect solution at best, but the weaknesses are the reality you have to trade under. I prefer to keep my powder dry during periods when I know my data is stale. If someone absolutely has to trade during those times, then it's best to buy a seat on the exchange and trade from there, since that is the only place you have a fighting chance during those times.

Just my opinion.

VT

[Big D]

Remember...broker's software (Rithmic) has no delays, Ninja has occasional delays. Both use ZF. Both use the internet. Same computer. Only thing different is the compiled code, ie the app. I think it's that simple.

[Alfred]

VT & Big D...thanks for the detailed info...so now can see how when ticks speed up at critical points that a later tick can make things seem like more lag than is actually happening....in a way this in itself might be a good indicator perhaps...

Basically feel things are running acceptably now...also..understand NT7 processing is to be faster.

Wonder if many guys have T1 lines or are hardwireded to Zen servers in Chicago for an edge... ??


Thanks...

[Big D]

"Wonder if many guys have T1 lines or are hardwireded to Zen servers in Chicago for an edge... ??"

There are 2 reasons to lease or put your box near the broker's server.

Both should only involve fully automated or partially automated systems.

1) You want close to 100% uptime...no power outages...no internet drops.

2) Performance really matters. ie, you're shooting for 1 tick profits. Queue position is important, you trade 100s if not 1000s of times a day.

If the box is in Chicago, you will have to remote-in to manage it. If you are 100% manual, you don't stand to gain much, because the pixels still have to travel from Chicago to you before you make a decision.

Also, remote management and multiple displays do not work together. Anything more than 2 screens is a big hassle.

[VTtrader]

Great Job!

Great Job on NT7 performance enhancements Ray and all!

Just had my first ES open with NT7 using the TickTimePlot indicator and the improvement is remarkable. In the past it was showing lags up to 16 seconds on the open, see the attached picture for the results with NT7.

Pre-open there is one spike (about 2.5 senonds) when I loaded an indicator in another chart prior to the open. The generally higher values prior to the open are due to the fact that with slower price action, there is no way to tell if the first tick of the second was at +0 ms or +999 ms. Once the market is open and the ticks are coming faster, you're more likely to have the first tick of the second being closer to +0 ms.

Average lag using NT7 when the market is open is averaging around .2 seconds. A major improvement!

Glad to report such good news.

VT