We have noticed the following issue, that can be reproduces by using the rfa-tutorials/step8 app.
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?!
FieldEntry TIMACT_MS (4148): 6343000 FieldEntry PR_TIM_MS (6520): 6041860
Can someone check if our setup (on Reuters side) is optimal?
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.