Hello @sujith Total volume traded value will always increase, not decrease. What I have observed is that the volume traded is reduced. How is it possible? Is it a glitch, or what I observed is wrong? Also, sometimes the same value is duplicating multiple times. What is the reason for all this?
I just checked ticks log for the mentioned instrument and timestamp. The volume are in the correct order as per the exchange timestamp. eg: Volume1: 182324200 is at "2024-11-19T15:20:01" Volume3: 182324200 is at "2024-11-19T15:20:02" Volume2: 182337150 is at "2024-11-19T15:20:02" Volume4: 182342725 is at "2024-11-19T15:20:03" As, you can see vol 3, and vol 2, came at the same seconds, but in the correct order. You should store it accordingly in your db/store.
@rakeshr I have checked with TrueData ticks. I am using both Kite and Truedata, the same code I am using with Truedata, and I have been checking for 1 hour, and I am sure I am not getting volume-decreasing issues with Truedata.
I am converting to Unix timestamp before storing any ticks, so Unix is so accurate and giving it as a score, so no way it shows out of order.
The log time and streaming tick time are the same in your system? or after streaming the ticks, then it stores and sorts the time in the logs?
Yes, they are the same. We use the same data source for our charts as well. Please note that while there can be multiple ticks within the same second, but they will always be in the correct order. You might want to consider implementing a unique sorting identifier at your end to differentiate the sequence of ticks within the same second.
@rakeshr@sujith Please consider including milleseconds in the exchange timestamp so it will avoid these out-of-order issues. All other data providers (paid or free) have this feature, or they will pass the ticks only if they have sorted the ticks's order.
@Dileep Each tick has volume, so the issue arises when the two ticks with the same timestamp will create an out-of-order issue, so only the possible way from their end is to simply include milliseconds so each tick will be unique as milliseconds are different.Or they can do different unique sorting methods without including milliseconds.
Second time is enough when the tick frequency is lower, but now we get 3 to 4 ticks per second in a volatile situation. A millisecond is necessary to get clarity.
The best way is sorting the volumes in asending order
Not possible to do that. Volume cannot be sorted in ascending order because one tick has only one volume value, so it is not possible. Once stored in a DB, we can do the sorting or whatever we need.
eg: Volume1: 182324200 is at "2024-11-19T15:20:01"
Volume3: 182324200 is at "2024-11-19T15:20:02"
Volume2: 182337150 is at "2024-11-19T15:20:02"
Volume4: 182342725 is at "2024-11-19T15:20:03"
As, you can see vol 3, and vol 2, came at the same seconds, but in the correct order. You should store it accordingly in your db/store.
I am converting to Unix timestamp before storing any ticks, so Unix is so accurate and giving it as a score, so no way it shows out of order.
Second time is enough when the tick frequency is lower, but now we get 3 to 4 ticks per second in a volatile situation. A millisecond is necessary to get clarity. Not possible to do that. Volume cannot be sorted in ascending order because one tick has only one volume value, so it is not possible. Once stored in a DB, we can do the sorting or whatever we need.