|
|
Home
Search
Register
Login
Recent Posts
| Viewing User Profile for: Pierre845 | |||||||||||||||||||||||||
| About | Contact | ||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
| Post Statistics | |||||||||||||||||||||||||
|
Pierre845 has contributed to 5 posts out of 21185 total posts
(0.02%) in 1,957 days (0.00 posts per day).
20 Most recent posts:
Data Questions »
Same Timestamp with different TickID Jun 2, 2020 08:04 AM
(Total replies: 12)
Thanks Gary_Stephen for you input on TickIDs, a refresher on how they work is always useful, even though in this case it doesn't address what I was talking about. Indeed in the case I explained, it would actually be the opposite, as it looks as if the two trades across the Bid/Ask change should be the same one (perhaps only nanoseconds could clarify); it looks like the only reason they're different is because the Bid/Ask moved (which made the agressor code change, which I believe should stay at 2 instead of 1). As you've been working / communicating with CME, they're likely to give you an explanation. Unless it's market making action, placing two different opposite trades (at the same time to the microsecond, but with a time hierarchy to the nanosecond), first one to get the Bid/Ask down, second to hit the Ask .. but I don't see the point. Edited by Pierre845 on Jun 2, 2020 at 08:06 AM
Data Questions »
Same Timestamp with different TickID Jun 1, 2020 08:46 AM
(Total replies: 12)
Thanks Stephen, so do you mean that in essence the Agressor Field is useless? indeed in that case we would just need to comapre Bid/Ask/Last Price and work it out without the need of another data field. Nevertheless, the fact that Trade TickID 272584027 occurs at the same price AND with the same timestamp, without being bundled by CME (I understand you unbundle, which creates same TickIDs), makes me wonder if this is an actual new trade (which would make the timestamp different if we had nanoseconds - could you please check that with CME maybe?), OR that this is the way the CME reports trades in this case, when the Bid/Ask moves but the trade is executed at Ask in this case instead of Bid (market Makers / HFT actions?), meaning the agressor code should stay to 2 and not 1. This happens a few times during the day (>20 times), and I find that the likelihood of two traders, one bid agressor, and one ask agressor, to place their trade at the same time (to the microsecond) WHEN the Bid/Ask moves, is very low.
Data Questions »
Same Timestamp with different TickID Jun 1, 2020 07:01 AM
(Total replies: 12)
yes, it's in column 'Symbol' of the file I uploaded: @ESH20
Data Questions »
Same Timestamp with different TickID Jun 1, 2020 06:44 AM
(Total replies: 12)
Sure, please see the attached. It's rounded (3055.8 is actually 3055.75)
Data Questions »
Same Timestamp with different TickID May 30, 2020 11:28 PM
(Total replies: 12)
Hi All, While in the process of analysing data for efficient storage purpose (eliminating redundant or unecessary data) I encountered occurences where there is a serie of Timestamps of same value (to the microsecond). Within it there is the same TickID to a point (also same Bid/Ask and same agressor). Then the TickID changes, Bid/Ask as well, and also agressor, ss follows: Seconds | Last | LastSize | Bid | Ask | TickID | Agressor 7.013979 | 3055.5 | 1 | 3055.50 | 3055.75 | 272584026 | 2 7.013979 | 3055.5 | 1 | 3055.50 | 3055.75 | 272584026 | 2 7.013979 | 3055.5 | 1 | 3055.50 | 3055.75 | 272584026 | 2 7.013979 | 3055.5 | 1 | 3055.25 | 3055.50 | 272584027 | 1 <--------- 1. So Bid is hit 3 times - and I believe it's unbundled data hence the same TickID, but how come at the same timestamp the bid/ask goes lower 0.25 pt, and a new buyer comes to hit the offer? 2. I was thinking .. is it the same agressor who was hitting the bid, but CME/IQfeed classify it as an offer agressor because the bid/Ask went down, and they calculate the agressor flag as 'last price at bid' or 'last price at ask' (and in this case the agressor field is useless as we can calculate it easily (redundant for data storage purpose). 3. Can it be explained otherwise if we had nanoseconds? as the timestamp might actually be different to the nanosecond? |
|||||||||||||||||||||||||