Issue with Missing Current 1-Min Candle in Market Data Feed V3

Developer API
21

[2025-06-25 13:06:06] local.INFO: SKIPPED stale tick for NSE_EQ|INE602G01020: LTP=277.4, LTT=2025-06-25 13:04:55 (diff: 71s)
[2025-06-25 13:06:06] local.INFO: SKIPPED stale tick for NSE_EQ|INE919I01024: LTP=9.18, LTT=2025-06-25 13:03:42 (diff: 144s)
[2025-06-25 13:06:06] local.INFO: SKIPPED stale tick for NSE_EQ|INE642Y01029: LTP=35.1, LTT=2025-06-25 13:00:26 (diff: 340s)
[2025-06-25 13:06:06] local.INFO: SKIPPED stale tick for NSE_EQ|INE414D01027: LTP=294.2, LTT=2025-06-25 13:05:14 (diff: 51s)
[2025-06-25 13:06:06] local.INFO: SKIPPED stale tick for NSE_EQ|INE526E01018: LTP=2413.4, LTT=2025-06-25 13:05:03 (diff: 63s)
[2025-06-25 13:06:06] local.INFO: SKIPPED stale tick for NSE_EQ|INF204KC1022: LTP=130.87, LTT=2025-06-25 12:33:34 (diff: 1952s)
[2025-06-25 13:06:14] local.INFO: SKIPPED stale tick for NSE_EQ|INE634I01029: LTP=213.55, LTT=2025-06-25 13:05:21 (diff: 53s)
[2025-06-25 13:06:14] local.INFO: SKIPPED stale tick for NSE_EQ|INE526E01018: LTP=2413.4, LTT=2025-06-25 13:05:03 (diff: 71s)

Check this Logs..The Websocket not providing the Exact values of Stocks, seems like it providing prices late by 1-2 minutes.
My current code has Laters version Of PHP and Websocket .

Looking forward to a prompt response and resolution.

22

Hi @RENJITH_44369921

On speaking with top algo-traders and folks in the community, it led us to the insight that the most compute on algorithmic logic is done after the close of a candle, and not while its in progress.
Hence, we made this change while moving from v2 to v3.

Let me share on why it was made this way.

The full mode on V3 has the following structure:

  1. Ticker data
  2. Depth [5]
  3. Greeks
  4. OHLC - 1D and 1min [TBT accuracy]
  5. Other essentials - ATP, VTT, OI, IV and total buy/sell quantity for the day.

To maintain TBT standards delivered accurately, it required over 100MBPS of stable bandwidth for the sockets on the user end. We tested subscribing to 1000 instruments, and still lost 0.2% of the packets. Trust me - TBT data is quite heavy and super high frequency, especially on ATM contracts of indices.


To counter the heavy flow in data and streaming everything as quickly as it is updated from the exchanges, we designed a rather unusual but extremely efficient socket - where only the data that has updated is streamed and the rest remained the same.
This made caching and other services of great use. We could quickly send the data as we got from the exchange and wouldn’t need to add other “unchanged” parameters.

Now coming to the use case of the sockets. The Ticker data (1) part, can be used for your price sensitive logics. Realtime tick data can be accessed via this. Very close to TBT, but not fully on point (constrained as I explained above).

For technical logics, candle once formed is used rather than the live (current) candle which is still “forming”. Let me explain with a use case instance considering 1-min timeframe.

You would apply the logic on the candle the moment the candle is closed. This means that the accurate candlestick data is already formed and is N-1 (N minus 1) position. This N-1 candle is what we’ve made to match TBT data. On the first tick of the Nth candle, the N-1 is fully updated at TBT accuracy.


This resolves for any of the lost packets on the connection and still get TBT accurate data for your logic computation at the same timing as you would using v2, viz. on candle closing.


What has changed, is how you would handle the socket. I understand this is some effort to change what’s already working. But its worth the TBT accuracy that top algo-traders and funds rely on.


I hope this answers why the V3 is built in a different way than V2!

1 Like
Change in I1 1-Minute Candle Update Behavior in WebSocket Feed
Websocket market v3 full update only give last minute candle update , no realitme candle update
23

Thanks for the detailed explanation. But if you can provide separate web socket with both (N-1 and current) candles with limited instruments as there are many users who depends on both data but don’t use more than 10-15 instruments. Such as we subscribe only Nifty Spot, one call and one put option so total 3 instruments are subscribed so for this connection we can get both candles with low bandwidth or if you can provide live candle also within same connection if user has connected to limited instruments. That will be very helpful.

24

But its relatively simple to form the same candle using the LTPC (mode or structure from full).

We cannot maintain a socket for a relatively small use case here.

25

Yes it’s simple to form that and I have built that also but the problem occurs when you lost connection in between so your OHLC data will not form correct. but in live OHLC data received from websocket even if connection is lost we will get latest OHLC in next ticker.

Or if I can give suggestion that you can implement Server Side Event to push candle data as soon as it is completed which is currently not provided by any brokers, Many users can subscribe to it and get data as soon as it is generated. As per current scenario we are getting N-1 candle in websocket which is being passed repeatedly for 60 seconds and in 60 seconds their might be 1000 ticks, which we are using only once in a minute.

26

This is the N-1 candle itself na which is already being provided. Which is available as soon as the next tick is in place. And it stays such for 60 whole seconds, which give stability even in case you lose a few packets!

27

I was suggesting to implement Server side events for n-1 candle to replace live candle in web socket