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:
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.
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.
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
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.