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.
Thanks @ANL & @rakeshr . So i think from the exchange it self the tick data is not coming in asending time frame. Below is the sample API response. In the above if "timestamp"(in tick data the parameter name is "Exchange timestamp") parameter contains micoseconds as well that will be good. The question is 1. who will include the microseconds to the "timestamp" parameter? whether the Exchange or the Zerodha(broker). 2. By including microseconds, it is not guarantee that "timestamp" of the streaming ticks is in asending order(But actually it should stream in asending order). Please correct me if i am wrong.
1. who will include the microseconds to the "timestamp" parameter? whether the Exchange or the Zerodha(broker).
I don't know the format of tick data they are getting from the exchange. If the exchange provides milliseconds, they can just include. if not,
Zerodha can't easily include milliseconds to the each tick data, as if they rely on whatever ticks are coming from the exchange. Exchange time is when exchange passing ticks to the broadcast channel. Mr. Rakeshr has to explain if it is possible.
By including microseconds, it is not guarantee that "timestamp" of the streaming ticks is in asending order(But actually it should stream in asending order). Please correct me if i am wrong.
As I said before, each tick has only one value for all params, not multiples. The logic is they can add whatever, but it matters only how they pass ticks and how we collect those ticks.
For the Python client, the tick data is coming as a dictionary in a list of combined/series of ticks, so when we extract through, then there is a chance that it will be out of order or crop up other issues; otherwise, we have to do some other logic inside our code.
@rakeshr Is it possible to remove the series of ticks in a list? Each tick should be a single tick in a list, and it will solve all issues customers are facing. So while streaming ticks, it will collect all ticks in a proper way. If you look around, all other data vendors provide it in this method.
As a paying customer, I expect minimal overhead and increased satisfaction. Before passing the ticks to the customer, a company should be thoroughly checked for all possible logic and issues.
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.
In the above if "timestamp"(in tick data the parameter name is "Exchange timestamp") parameter contains micoseconds as well that will be good.
The question is
1. who will include the microseconds to the "timestamp" parameter? whether the Exchange or the Zerodha(broker).
2. By including microseconds, it is not guarantee that "timestamp" of the streaming ticks is in asending order(But actually it should stream in asending order).
Please correct me if i am wrong.
Here are some issues that I observed: I don't know the format of tick data they are getting from the exchange. If the exchange provides milliseconds, they can just include. if not,
Zerodha can't easily include milliseconds to the each tick data, as if they rely on whatever ticks are coming from the exchange. Exchange time is when exchange passing ticks to the broadcast channel. Mr. Rakeshr has to explain if it is possible. As I said before, each tick has only one value for all params, not multiples. The logic is they can add whatever, but it matters only how they pass ticks and how we collect those ticks.
For the Python client, the tick data is coming as a dictionary in a list of combined/series of ticks, so when we extract through, then there is a chance that it will be out of order or crop up other issues; otherwise, we have to do some other logic inside our code.
@rakeshr Is it possible to remove the series of ticks in a list? Each tick should be a single tick in a list, and it will solve all issues customers are facing. So while streaming ticks, it will collect all ticks in a proper way.
If you look around, all other data vendors provide it in this method.
As a paying customer, I expect minimal overhead and increased satisfaction. Before passing the ticks to the customer, a company should be thoroughly checked for all possible logic and issues.