question

Upvotes
Accepted
petru.marginean avatar image
1 ●0 ●0 ●1

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.


  1. 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)
  2. We get L2 data passing the 'marketByOrder' parameter
  3. After open we can see big delays when receiving data (+5 minutes!)
  4. 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?

elektronrefinitiv-realtimeelektron-sdktreprfarfa-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

1 Answer

Upvotes
Accepted
umer.nalla avatar image
20.3k ●73 ●10 ●20

Hi @petru.marginean

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

petru.marginean avatar image petru.marginean

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.


umer.nalla avatar image umer.nalla petru.marginean

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.

Click below to post an Idea Post Idea