Getting wrong data for premiums in bank nifty options.. wrong data is coming since 5 10 minutes. Huge difference in premiums shown. Token nums used are 13297410, 13297666
Same thing is being observed by me as well. If I restart my client, then for some time the price matches. And after a few mins I can see it getting delayed.
Thanks Sujith, There was or is definitely something abnormal today. I do understand it would be a difficult to investigate, but keep an eye if anyone else reports any issues that could be connected with the delay happening or happened today morning.
Not only today I Observed this before as well. Just watch the premiums continuously, price whatever is shown on the ticker is getting stuck for a while in a range. Today when the premium of 41800CE was 61 on the kite app it was showing 71- 76 moving in the same range for 5-10 minutes. The same happened to me last week, I don't remember the strike but the screen price was 148, and the ticker was stuck at that time showing premiums of the same strike in the 182-190 range. Initially, I thought something wrong with the code that's why I was carefully watching it today. Please look into this on priority.
I'm logging ticker data since the last hour for 13297410(BANKNIFTY2291541800CE) , but still can't see the difference in last_price field of kite websocket vs kiteconnect ticker. Can you paste tick logs with timestamps for the same instrument 13297410, where you see the difference?
I do not see any issue in my test environment. That socket has subscribed to just one symbol. But when I compare prices from my test environment kite client with my production environment kite client....I see quite a lot of difference.
My production client has one open connection with around 1000 scrips subscribed. But this is common production subscription count since few months. So was there any change on the limitations subscriptions per connection.
So in short the issue can be observed under following scenarios: 1. The connection must be open for some time for the delay to be observable 2. The connection must have a lot symbols subscribed
Hello Sujith, You can ignore that file, as it will most likely match with kite website. However as mentioned in my previous comment, this data was taken from my local test environment. I do not see any delay there.
The delay is observed on my production machine. There is no provision on production machine to take a csv ltp dump. But on production I can visually see a difference of 10 to 15 rupees on BANKNIFTY SEP FUT contract.
So based on my observations, the steps to reproduce the issue are: 1. The connection must be open for some time for the delay to be observable 2. The connection must have a lot symbols subscribed
This issue has popped up again. Please try to reproduce it today with the following steps:
Steps to reproduce the issue are: 1. The connection must be open for some time for the delay to be observable 2. The connection must have a lot of symbols (Say around 1000) subscribed 3. Sample contract where we see delay is (BANKNIFTY SEP FUT)
Please note additional points in reproducing this: 1. The connection must be open for some time for the delay to be observable 2. The connection must have a lot of symbols (Say around 1000) subscribed 3. Print system time along with tick time & then compare it with Kite Connect time & LTP. There is definitely a lag. It is either in the Tick Time or in the Received Time (i.e. tick time might be correct, but the ticks are being received delayed) 4. Sample contract where we see delay is (BANKNIFTY SEP FUT)
I tried reproducing this today, subscribed to 1000 contracts including BANKNIFTY SEP FUT(9604098), and logged FULL mode tick(that has timestamp) for the same, until 15:30, I was not able to see any difference.
Could you please confirm if you checked both tick time & system time. Because if ticks are delayed then there will be difference in tick time & system time/internet time.
And I haven't encountered any difference in that day's tick, except for few ticks at random with few ms difference w.r.t system time(this is acceptable for stream over the internet). Eg: 2022-09-21 14:20:07,754 - Ticks: {'tradable': True, 'mode': 'full', 'instrument_token': 9604098, ..... 'exchange_timestamp': datetime.datetime(2022, 9, 21, 14, 20, 6), .....}]}}
That's very strange. For us, I am observing significant delay every day now....since this issue has been reported. Before that it worked absolutely fine.
My server is on Google cloud mumbai data center, so it is definitely not a network issue/lag for sure.
There is definitely a lag given recreation steps that I had mentioned. But I understand it may not be reproducible.
You can close this issue for now, but just keep it at the back of your mind .... may help if someone else reports something similar.
I need get data from one more source... Unfortunately, I cannot rely on just one source anymore.
Mode Full, comparing LTP with Zerodha kite app.
As mentioned in my earlier comment, if I restart my client. The delay goes away for a few mins & then it comes back again.
There was or is definitely something abnormal today. I do understand it would be a difficult to investigate, but keep an eye if anyone else reports any issues that could be connected with the delay happening or happened today morning.
13297410(BANKNIFTY2291541800CE), but still can't see the difference inlast_pricefield of kite websocket vs kiteconnect ticker. Can you paste tick logs with timestamps for the same instrument 13297410, where you see the difference?This data is from test env & i dont see delays visually. Please see next comment.
I do not see any issue in my test environment. That socket has subscribed to just one symbol. But when I compare prices from my test environment kite client with my production environment kite client....I see quite a lot of difference.
My production client has one open connection with around 1000 scrips subscribed. But this is common production subscription count since few months. So was there any change on the limitations subscriptions per connection.
So in short the issue can be observed under following scenarios:
1. The connection must be open for some time for the delay to be observable
2. The connection must have a lot symbols subscribed
You can ignore that file, as it will most likely match with kite website. However as mentioned in my previous comment, this data was taken from my local test environment. I do not see any delay there.
The delay is observed on my production machine. There is no provision on production machine to take a csv ltp dump. But on production I can visually see a difference of 10 to 15 rupees on BANKNIFTY SEP FUT contract.
So based on my observations, the steps to reproduce the issue are:
1. The connection must be open for some time for the delay to be observable
2. The connection must have a lot symbols subscribed
Just did some checks in the morning & not seeing any issues today. Maybe it was a one off.
However, I will keep on monitoring.
Thanks!!!
Steps to reproduce the issue are:
1. The connection must be open for some time for the delay to be observable
2. The connection must have a lot of symbols (Say around 1000) subscribed
3. Sample contract where we see delay is (BANKNIFTY SEP FUT)
Any update of this? This is still happening.
Please note additional points in reproducing this:
1. The connection must be open for some time for the delay to be observable
2. The connection must have a lot of symbols (Say around 1000) subscribed
3. Print system time along with tick time & then compare it with Kite Connect time & LTP. There is definitely a lag. It is either in the Tick Time or in the Received Time (i.e. tick time might be correct, but the ticks are being received delayed)
4. Sample contract where we see delay is (BANKNIFTY SEP FUT)
This one would be difficult to trace.
Could you please confirm if you checked both tick time & system time. Because if ticks are delayed then there will be difference in tick time & system time/internet time.
Eg:
2022-09-21 14:20:07,754 - Ticks: {'tradable': True, 'mode': 'full', 'instrument_token':9604098, ..... 'exchange_timestamp': datetime.datetime(2022, 9, 21, 14, 20, 6), .....}]}}
My server is on Google cloud mumbai data center, so it is definitely not a network issue/lag for sure.
There is definitely a lag given recreation steps that I had mentioned. But I understand it may not be reproducible.
You can close this issue for now, but just keep it at the back of your mind .... may help if someone else reports something similar.
I need get data from one more source... Unfortunately, I cannot rely on just one source anymore.
Thank you!