@sujith Is there any delay in receiving ticks? I have noticed that there is a small 1 second delay in receiving ticks in my system. I have subscribed to just 62 tokens. Using Unix timestamps, the parsed last traded time is "last_trade_time," "1715852874", and the recorded time in my system is 1715852875. There is no code delay or unnecessary computation. I have checked the clock drift as well. I have observed in the Redis monitor
To sum up, I have noticed some instruments time differences are high, like a difference of 5 seconds or more. Is this definitely because of the last traded time of illiquid or far OTM instruments?
The last traded time will print when there is a last trade; otherwise, it won't print it, right? i.e., full mode depth will change when any changes, irrespective of trade occur. While streaming ticks, the last traded time and time of ticks I get will differ if the above is possible, right?
I need to make sure the time differ from my end. Can you investigate possibilities?
Today I noticed the same issue. I just added up the exchange timestamp, and it is 1 second below the ticks I am receiving. Some ticks show on time; both the current time in my system and the exchange timestamp are equal.
A half to one-second delay in the LTT time in the exchange broadcast would be expected. It would also depend on the instrument you are subscribed to and the liquidity in the option.
Any delay beyond this would require some investigation.
@themohammedfaisal Yes Agreed. LTT will vary depending on the instrument's liquidity. The current delay is beyond that; the current time and exchange timestamp should match, right? I have checked many times and tested with simple dummy code for time testing. I could see that time is not matching for some instruments, liquid or illiquid. If this issue is not from my end, then a 1 second delay must be resolved very quickly. Please check it out.
Local time: Sat 2024-05-18 11:35:16 IST Universal time: Sat 2024-05-18 06:05:16 UTC RTC time: Sat 2024-05-18 06:05:17 Time zone: Asia/Kolkata (IST, +0530) System clock synchronized: yes NTP service: active RTC in local TZ: no
It has been raised multiple times before They are not concerned about this because it doesn't matter for most of the traders Its a matter of time until someone better in the market provides better services and the crown would shift Simple economics
@sujith@rakeshr@themohammedfaisal If there is a few millisecond discrepancy in the timestamp between the current and exchange timestamps, it is acceptable and normal for retailer trading.
Please include milliseconds for all timestamps, as nowadays more ticks per second are normal. so it's easy to differentiate.
@tradernoob I have read all of your threads before in Q&A. If you are a pure seconds based trader and want to scale up, I think the current issues will kill your strategy.
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).
Which is the most efficient API for seconds based trading except the Kite Connect API? I need to receive ticks and place orders in milliseconds. As you mentioned, you had used many APIs . In my case, I don't want to subscribe to more than 100 tokens; that's enough for me. As of now, I am not facing scale up issues.
There is some contradiction here if we analyze it in a simple way:
>The Kite Connect team says that they are just relying on whatever ticks they get from exchange, then why is it delaying by 1 second? If they are relying on the same data, then why WS streams using this data structure that we are getting now?
>There might be some issues with their data conversion method or exchange and Zerodha's server delays. None of the others come to mind.
@ANL the contradiction you mentioned was exactly what I was trying to ask them previously, but it was not cleared up that time too.
As far as fast websockets are considered, I was getting better median latency with 5paisa. But the problem with them is that the connection quality was very delicate (it would break off randomly multiple times during the day) and also the jitter was too high (suddenly the latency spikes to more than 2 minutes at times, forcing you to reconnect).
I have moved away from such second based trading for now due to the reasons I mentioned, so I am not sure what the best provider today is.
All I am hoping for is that someone better comes in the market and raises the bar.
@tradernoob I had used the TrueData Velocity feature but not the API service, but it is widely used and I am not sure about the latency.
The main problem I am facing is that I am working on a trading strategy that needs the current issue to be solved. I can not move away from that logic; otherwise, It's hard for me.
The other thing is that the Kite team says the Kite API is not for latency based trades, but the real latency based trades are HFT, which can not be done by retailers. Kite API is for retailers So here are all the current issues or bugs running in the retail environment, not in the big players's environment. their game in nanoseconds to microseconds level that we can not imagine.
I am stuck if they don't solve that issue. I hope they will take the necessary action. As retailer traders, we guys are suppressed by a lot of regulations as well as institutions, so getting good API service is like a mirage !
@sujith It would be better to close this thread. I have decided to tweak my logic rather than the Kite Connect logic. You could have answered the question about whether it is possible or not.
The problem is raised several times, sometimes eveb discrepencies in NSE data happen, might be due to race condition, BSE data is reliable. But after checking everything, I came to conclusion that right now, kite's socket is most efficient and reliable.
In my initial days, I spent months to make ms based algos to work, but latency killed it. And co-location is only solution for that until and unless someone come up with better system (might be brokers start to provide co-location with there servers).
@kakush30 Latency is the main issue. The stability of the Kite Connect API is good, but there are some narrow range opportunities for sub minute scalping with the Kite Connect API that we need to dig deep.
There are other data vendors that provide tick data on time. I checked with GDFL and there is no delay; it's about a 10 ms delay, which is not a big issue for retailers. current second == server time. However, if you do sub minute trades, GDFL can also be considered. To conclude, the KIte Conenct API is at better pricing and provides a stable connection, but it is not efficient for sub minute trades. GDFL, or true data, provides less latency ticks, which are equal to the KiteConenct API's data.
@ANL I tried GDFL 4 years ago for quite some time, but what I found that placing a order also takes around 400-600 ms on average (this is from around covid), so a buy-sell time is around 1.5 sec , that was deal breaker to me.
In US, brokers provide co-location with there servers, which reduce this this time, but let see when that happen in india.
If you use the KIte API for order placement and GDFL for ticks, then the issue is solved, but it costs more. If you get a good trading income, then it's okay to manage.
I checked again, For 100 tokens they are charging 4400 + GST. This should be either FNO or EQ. Kite Connect is scalable and low-cost, but those who need less latency can try GDFL.
Is this definitely because of the last traded time of illiquid or far OTM instruments?
The last traded time will print when there is a last trade; otherwise, it won't print it, right? i.e., full mode depth will change when any changes, irrespective of trade occur.
While streaming ticks, the last traded time and time of ticks I get will differ if the above is possible, right?
I need to make sure the time differ from my end. Can you investigate possibilities?
tick time mismatch:
some ticks have same time:
A half to one-second delay in the LTT time in the exchange broadcast would be expected. It would also depend on the instrument you are subscribed to and the liquidity in the option.
Any delay beyond this would require some investigation.
Local time: Sat 2024-05-18 11:35:16 ISTUniversal time: Sat 2024-05-18 06:05:16 UTC
RTC time: Sat 2024-05-18 06:05:17
Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
They are not concerned about this because it doesn't matter for most of the traders
Its a matter of time until someone better in the market provides better services and the crown would shift
Simple economics
@tradernoob I am wondering why no one raised this as a serious issue, though a lot of people use the Kite API
If there is a few millisecond discrepancy in the timestamp between the current and exchange timestamps, it is acceptable and normal for retailer trading.
Please include milliseconds for all timestamps, as nowadays more ticks per second are normal. so it's easy to differentiate.
Both the issues, milliseconds for timestamps (especially order timestamps) and latency have been raised before:
1) Latency issue:
https://kite.trade/forum/discussion/13587/fast-market-data
https://tradingqna.com/t/room-for-improvement-in-zerodha-tick-speed/62993/43?page=2
2) Millisecond issue:
https://kite.trade/forum/discussion/13749/tick-frequency-details#latest (Last post)
https://kite.trade/forum/discussion/3759/timestamp-column-in-kiteconnect-3-0-doesnt-have-milliseconds
There is some contradiction here if we analyze it in a simple way:
>The Kite Connect team says that they are just relying on whatever ticks they get from exchange, then why is it delaying by 1 second? If they are relying on the same data, then why WS streams using this data structure that we are getting now?
>There might be some issues with their data conversion method or exchange and Zerodha's server delays. None of the others come to mind.
As far as fast websockets are considered, I was getting better median latency with 5paisa. But the problem with them is that the connection quality was very delicate (it would break off randomly multiple times during the day) and also the jitter was too high (suddenly the latency spikes to more than 2 minutes at times, forcing you to reconnect).
I have moved away from such second based trading for now due to the reasons I mentioned, so I am not sure what the best provider today is.
All I am hoping for is that someone better comes in the market and raises the bar.
The main problem I am facing is that I am working on a trading strategy that needs the current issue to be solved. I can not move away from that logic; otherwise, It's hard for me.
The other thing is that the Kite team says the Kite API is not for latency based trades, but the real latency based trades are HFT, which can not be done by retailers. Kite API is for retailers So here are all the current issues or bugs running in the retail environment, not in the big players's environment. their game in nanoseconds to microseconds level that we can not imagine.
I am stuck if they don't solve that issue. I hope they will take the necessary action. As retailer traders, we guys are suppressed by a lot of regulations as well as institutions, so getting good API service is like a mirage !
But after checking everything, I came to conclusion that right now, kite's socket is most efficient and reliable.
In my initial days, I spent months to make ms based algos to work, but latency killed it. And co-location is only solution for that until and unless someone come up with better system (might be brokers start to provide co-location with there servers).
There are other data vendors that provide tick data on time. I checked with GDFL and there is no delay; it's about a 10 ms delay, which is not a big issue for retailers. current second == server time. However, if you do sub minute trades, GDFL can also be considered. To conclude, the KIte Conenct API is at better pricing and provides a stable connection, but it is not efficient for sub minute trades. GDFL, or true data, provides less latency ticks, which are equal to the KiteConenct API's data.
In US, brokers provide co-location with there servers, which reduce this this time, but let see when that happen in india.
If you use the KIte API for order placement and GDFL for ticks, then the issue is solved, but it costs more. If you get a good trading income, then it's okay to manage.