Support Board

I have had amazing experience with dxFeed data feeds. They do not provide execution, however. Being based in Asia, I cannot use Denali for realtime data - both Rithmic and CQG have been much better in this regard. By better I mean that data is coming in very fast, whereas Denali is very slow and skips prices.

It would be amazing to be able to use dxFeed for data and, for example, CQG for execution...

That is exactly what I meant. Not missing data for certain prices, but jumping to the final price. From reading the tape perspective, prices are skipped because I can't see how the market moved, just the end result. It makes trading my system impossible.

so it's obviously not our network connection like sc team keeps accusing ppl of.

both of us are using the same network connection

And you are also making reference to a post more than a year old. There could have been problems, at that time, due to Internet peering issues that no longer exist.

It does not matter what your immediate Internet connection is like. That is completely irrelevant.
The server is far away in the US Midwest, and there is degraded Internet connectivity between your location and the server. Inevitably there is going to be packet loss, which will result in delays and the stopping of the data feed even for brief periods of time. If you notice stopping of the data feed, you have packet loss.

You are in Japan and that user is in Thailand:
both of us are using the same network connection
You are in different locations.

hey ivory, i noticed this too. when you're in asia, denali feed feels nothing like rithmic/cqg in terms of snappiness. both of us are using the same network connection when using denali vs rithmic/cqg so it's obviously not our network connection like sc team keeps accusing ppl of. like you said, it feels like denali is "jumping" to the final price like it's trying to not fall behind...as someone who also reads the tape, our way of trading is basically made impossible with denali in asia so i've been searching for alternative like you.

We recommend trying the New Zealand server and see if that helps:

You are in Japan and that user is in Thailand

which platform are you using to view dxFeed, even if it's only for data? does it also support ultra-low chart update intervals like sierra? there are many good execution platforms so finding an alternative for order routing is no problem.

Glad I am not the only one to see this. I would be more glad if it didn't happen ;) but at least it's not just me.

At this point I am interested in switching over to Asian Futures, but there are issues with access to Historical Data. In the past Denali offered Asian exchanges, but that hasn't been the case for a few years now. CQG offers only 30 days of Time and Sales data... and I haven't found anything else. It's possible to get the data and manually create scid files, but it's more of a hack than anything else. If you know about a provider that works with Sierra, I'd be happy to hear about it.

i believe that was barchart and not denali, whose service sierrachart used prior to ditching them once they launched their own feed (denali). if you need a provider that works with Sierra for asian futures, you're limited to only CQG, IQfeed, and interactive brokers, right? Rithmic doesn't provide Asian Futures data and i think the only APAC exchange that IQfeed has is the singapore exchange so that's probably out. And interactivebrokers doesn't provide true tick data. if you must use sierrachart, the only option is buying the tick data from CQG (expensive!) and stitching them into scid files but CQG data has a lot of errors from my experience so i guess it depends on how clean of a dataset you need.

if you must use sierrachar

Acknowledgments (ACKs) are sent with a sequence number by the receiver of data to tell the sender that data has been received to the specified byte. ACKs do not imply that the data has been delivered to the application, they merely signify that it is now the receiver's responsibility to deliver the data.

Reliability is achieved by the sender detecting lost data and retransmitting it. TCP uses two primary techniques to identify loss. Retransmission timeout (RTO) and duplicate cumulative acknowledgments (DupAcks).

When a TCP segment is retransmitted, it retains the same sequence number as the original delivery attempt. This conflation of delivery and logical data ordering means that, when acknowledgment is received after a retransmission, the sender cannot tell whether the original transmission or the retransmission is being acknowledged, the so-called retransmission ambiguity.[38] TCP incurs complexity due to retransmission ambiguity.[39]