huge delays when subscribing to L2 data for Chinese markets
We have noticed the following issue, that can be reproduces by using the rfa-tutorials/step8 app.
- We subscribe to about 1,300 names on Shanghai and Shenzhen markets (e.g 000001.SZh, 603997.SS etc) before the markets open (8 am Beijing time)
- We get L2 data passing the 'marketByOrder' parameter
- After open we can see big delays when receiving data (+5 minutes!)
- The delay peaks at around 9:45 am (China time, about 5-6 min delay) and then the delay goes down.
Example of delayed RFA message:
(the log timestamp is in EST, 20:45 ==> 9:45 Beijing time):
2020-02-25 20:45:43.909416: Received MARKET_BY_ORDER Message for '300315.SZh'
Message type : Update
MANIFEST:
Sequence Num : 40848
PAYLOAD DATA:
MAP (count=1):
Map Summary Data:
FIELDLIST (StandardDataCount=2):
FieldEntry SEQNUM (1021): 20114710187
FieldEntry TIMACT_MS (4148): 6343000
Map Entries:
Map Entry Action: Add
Map Entry Key: '2011-4710187'
Map Entry Data:
FIELDLIST (StandardDataCount=9):
FieldEntry LV_TIM_NS (14268): 01:40:41.860
FieldEntry OR_TIM_MS (6524): 6041860
FieldEntry ORDER_TN (13439): 1->"Not provided"
FieldEntry PR_TIM_MS (6520): 6041860
FieldEntry ORDER_SIZE (3429): 300
FieldEntry ORD_TONE (8591): '2'
FieldEntry ORDER_SIDE (3428): 1->"BID"
FieldEntry ORDER_PRC (3427): 7.02
FieldEntry ORDER_ID (3426): '2011-4710187'
Event dispatched. Approximate pending Events:12
How can the discrepancy between 'TIMACT_MS' and 'PR_TIM_MS' be explained?!
(5 min)
FieldEntry TIMACT_MS (4148): 6343000
FieldEntry PR_TIM_MS (6520): 6041860
Can someone check if our setup (on Reuters side) is optimal?
Best Answer
-
One thing to note here is that the fields you receive as part of a Payload are populated by the Elektron feed. Therefore, any supposed time differences in payload fields you see would not be related to any local setup.
Secondly, the question you have would be classed as a Content issue and not an API issue - therefore the best route to get an explanation would be to raise a Content Type ticket for the Elektron Realtime product you are using - don't mention API to ensure your query goes to a Content specialist.
However, as a non content expert, I would explain your observations as follows:
TIMACT_MS is present in the Summary data section, which contains data common to the whole orderbook and therefore represents the most recent activity to any order on the instrument’s order book.
PR_TIM_MS is the Priority Time Stamp of each individual order and is used to rank the order relative to its peers e.g. when sorting the OrderBook for display purposes - see this article for general guidance on sorting order books. So, in your example the value 6041860 is related to the specific BID side order at price 7.02 & size 300 - relative to other orders in the book.
Therefore, since TIMACT_MS represents the full order book and PR_TIM_MS is related to a single order, it is quite feasible to see differences in the timestamp for the most recent activity vs an older order present in the book.
As mentioned, I am not a content expert, so I recommend you seek fuller clarification from the content team.
0
Answers
-
Thanks for reply. We've already sent the request to the content team.
I agree with your distinction between TIMEACT_MS referring to any order.
The value for this field seems accurate (as it is in sync with the log timestamp)
Issue is the delay in sending the "action = Add" part: the PR_TIM_MS shows we receive a notification about adding an order +5 min after it happened.
0 -
Hi,
Sorry, you are right - that does need explanation...I missed the Message type : Update bit at the start of your snippet and reply was in context of a RefreshMsg.
Hopefully, the content team can explain the disparity.
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛