I have observed that the market data latency (on average 800ms-1second) is too high compared to the network delay (~30ms for me). Seems like when the exchange packet is received at Zerodha servers, it is being processed and then being broadcast. Can this be accelerated? (First broadcast the packet as it is and then process it; Maybe a separate websocket endpoint can be added for raw exchange packets) This would help extremely and I would be willing to pay for this feature.
@tradernoob, We just relay the tick that is received from the exchange. We don't throttle ticks. We get Level 2 data from the exchange an we send the same to the users. You can check out Nithin's reply on this thread to know more about how ticks streaming works. If you are looking for tick by tick data then you need to be colocated at the exchange and connect via LAN to receive more ticks.
PS: Kite Connect is not meant for HFT or latency based strategies. We suggest getting colocation server at the exchange for the same. It might cost around 20 lakh+ per annum for a setup like this.
@sujith Sorry for mistagging, couldn't delete the tag.
The exchange sends fields like sequence number which are not there in the packets relayed by Zerodha. Which shows that some processing is being done at Zerodha end.
I wasn't saying that you throttle the tick flow, I was saying that due to processing at your end, there is a delay added. And no, I am not talking about the TBT order and trade data. I am talking about exchange L2 data only. If there was throttling, the latency would have kept increasing. But no, the latency is constant, but way more than the network delay.
This points out that there is some kind of processing delay at your end. And exactly like you mentioned, getting a colocated setup is not feasible for retailers and small/growing businesses. That is exactly the reason, my post is a small request to look into the processing delay and overcome it if possible.
Ideally, the flow of the packet should be: Exchange ---(few millis at max)--> Zerodha Server (which decides which clients to send the data to) --(30 ms ~ network delay)--> Client (me). The bottleneck should be the network delay between the client and zerodha servers, right?
And again, if a feature like this needs computational upgrades at your end, I am sure many latency sensitive traders like me would be ready to pay for this.
PS: I look up to Zerodha as the leading stock broker in the API space. And I have used many broker APIs. Some of the broker APIs provide fast market data (in orders of network delay), the problem with them is that they are not scalable. If I subscribe more than 100-200 tokens, jitter increases. (Latency gets variable). I have observed that there are no jitter issues with Zerodha, the latency is constant, just a bit high. Hence I believe that Zerodha can definitely be the pioneer in this regard too and bring fast market data to us individual traders.
Hey @tradernoob, sorry for the late reply. As Sujith said earlier, we simply relay ticks that we receive as is. Any additional fields you've mentioned aren't available over our WS, but that isn't an indicator of any processing of ticks.
We just relay the tick that is received from the exchange. We don't throttle ticks. We get Level 2 data from the exchange an we send the same to the users. You can check out Nithin's reply on this thread to know more about how ticks streaming works.
If you are looking for tick by tick data then you need to be colocated at the exchange and connect via LAN to receive more ticks.
PS: Kite Connect is not meant for HFT or latency based strategies. We suggest getting colocation server at the exchange for the same. It might cost around 20 lakh+ per annum for a setup like this.
Sorry for mistagging, couldn't delete the tag.
The exchange sends fields like sequence number which are not there in the packets relayed by Zerodha. Which shows that some processing is being done at Zerodha end.
I wasn't saying that you throttle the tick flow, I was saying that due to processing at your end, there is a delay added. And no, I am not talking about the TBT order and trade data. I am talking about exchange L2 data only.
If there was throttling, the latency would have kept increasing. But no, the latency is constant, but way more than the network delay.
This points out that there is some kind of processing delay at your end.
And exactly like you mentioned, getting a colocated setup is not feasible for retailers and small/growing businesses. That is exactly the reason, my post is a small request to look into the processing delay and overcome it if possible.
Ideally, the flow of the packet should be:
Exchange ---(few millis at max)--> Zerodha Server (which decides which clients to send the data to) --(30 ms ~ network delay)--> Client (me).
The bottleneck should be the network delay between the client and zerodha servers, right?
And again, if a feature like this needs computational upgrades at your end, I am sure many latency sensitive traders like me would be ready to pay for this.
PS: I look up to Zerodha as the leading stock broker in the API space. And I have used many broker APIs. Some of the broker APIs provide fast market data (in orders of network delay), the problem with them is that they are not scalable. If I subscribe more than 100-200 tokens, jitter increases. (Latency gets variable).
I have observed that there are no jitter issues with Zerodha, the latency is constant, just a bit high.
Hence I believe that Zerodha can definitely be the pioneer in this regard too and bring fast market data to us individual traders.