EaaS quick start - test senario demo tool needed

Dear team,

Could you please advise how to make time comparision with client local time with time in our EaaS feed? Client suspect there is 1~2 second delay in EaaS data, by monitoring the gap between our FID 3854/3855 whichever comes the latest, with their local server time. They use active RICs like IBM.NB or AAPL.NB. Under normal circenstances, the gap should be fixed number e.g. 56, which indicate time difference between their system and ours. However they found sometimes the gap changes to e.g. 57 or 58 for 30min to 2hours thus comes suspect their is delay.

To find root out api causes, can we modify the Python test mentioned in quickstart guide:

https://community.developers.refinitiv.com/questions/ask.html?space=72

Could you please advise what modification needed to replicate, if existed, the delay on client by using the pythong demo? Client OS is windows. Thank you.

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

Accepted answers

Jirapongse

@Xiaorong

If the client is using EMA Java with RSSL connection. It is better to test with the rmdstestclient tool. It has an option (-m) to add a timestamp to the output.

rmdsTestClient.exe -S DIRECT_FEED -ct rssl -m -f rics.txt -X -d 3

The output looks like this:

[Wed Mar 03 16:14:06.690] <updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="5" containerType="RSSL_DT_FIELD_LIST" flags="0x0" updateType="0" dataSize="39">
</updateMsg>

TRDPRC_1             : REAL           2   : [1.09]
BID                  : REAL           2   : [1.08]
ASK                  : REAL           3   : [203.12]
ACVOL_1              : REAL           5   : [100000.00]
NETCHNG_1            : REAL           3   : [203.15]
ASK_TIME             : TIME           3   : [16:14:06:000]

Therefore, we can compare timestamps with data in FID 3854/3855.

All comments

Jirapongse

@Xiaorong

If the client is using EMA Java with RSSL connection. It is better to test with the rmdstestclient tool. It has an option (-m) to add a timestamp to the output.

rmdsTestClient.exe -S DIRECT_FEED -ct rssl -m -f rics.txt -X -d 3

The output looks like this:

[Wed Mar 03 16:14:06.690] <updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="5" containerType="RSSL_DT_FIELD_LIST" flags="0x0" updateType="0" dataSize="39">
</updateMsg>

TRDPRC_1             : REAL           2   : [1.09]
BID                  : REAL           2   : [1.08]
ASK                  : REAL           3   : [203.12]
ACVOL_1              : REAL           5   : [100000.00]
NETCHNG_1            : REAL           3   : [203.15]
ASK_TIME             : TIME           3   : [16:14:06:000]

Therefore, we can compare timestamps with data in FID 3854/3855.

Xiaorong

Thank you Phuriphanvichai. Client is also test with Python as per our quick start guide. Is it possible to add a timestamp there? Thanks.

umer.nalla

Hi @Xiaorong

How many instruments is the client consuming using their Python client - and by EaaS I assume you mean direct feed? Or are they using Refintiv Real-Time Optimized (ERT in Cloud)?

Xiaorong

Hi Nalla

Client is taking full Nasdaq Basic data, about 9000 US equity instruments. Yes direct feed via EaaS.

umer.nalla

Hi @Xiaorong

Given that the customer is consuming 9000 RICs, can you confirm if the 1~2s delay is noticeable immediately after they start consuming the data or after a period of time? If after a period of time, does the delay become greater as time goes on e.g. starts as 1s and then increases to 2s?

If so, this could be because of what is referred to as 'slow consumer' scenario - where the consumer cannot process the updates in a timely manner and they start to buffer up. As time goes on the buffer size increases and the event is waiting for 1~2s in the buffer to be processed - hence the delay.

EMA Java itself is certainly capable of consuming several thousand instruments. However if the application code is spending some time processing the events in the callback methods e.g. onUpdateMsg() - then this can result in the slow consumer scenario.

Please see the following previous replies for more information

ema slow reader application - Forum | Refinitiv Developer Community

Elektron EMAConfig.xml Consumer Buffer tuning - Forum | Refinitiv Developer Community

Decoding time for EMA - Forum | Refinitiv Developer Community

I have also come across a single instance of a slightly different scenario where the consumer was receiving delayed data. According to the support ticket we raised - the Bandwidth limits on the client's EDGE device were being breached around the market open time - resulting in the delayed data.

EXPLORE OUR SITES