Tool to monitor the latency of ticker update

Hi Team, I am doing the latency analysis of one data feed in our TREP env. The way i handle it is:

First, I run " ./rmdstestclient -S Source -h hostname -p 14002 -f /reuters/ads/demo/latency.ric -o 500 -ct rssl -t 2 -X -d 3 -m > output &"

Then I calculate the time difference between the data received time and the "BID_TIME" and use the result as the update latency for one ticker update.

My question is: is this the correct way to monitor/calculate the tick update latency? Coz what I notice is: even sometime the rmdstestclient results shows there is delay (~ 2 to 5 sed), our downstream application doesn't report any delay. Is it possible that the rmdstestclient itself will introduce some latency due to the server read/write capability or server resource capability?

If rmdstestclient is not the right tool to get the latency detail, what will be the correct tool I should us? or is there any parameter in the rmdstestclient command or system variable that i can tune to get a better performance?

If rmdstestclient is not the right tool, would you please help to advise what tool I should use to achieve my purpose?

Find more posts tagged with

trep

infrastructure

elektron

latency

refinitiv-realtime

rmds-test-client

Accepted answers

umer.nalla

Hi @nikita.ou

The rmdstestclient tool is a highly performant one written using a low latency API UPA/ETA - that it is why we use it for our performance testing.

If rmdstestclient is connecting to the same ADS across the same network + route etc as the downstream consumer then you should not be seeing much difference in time of receipt - if anything I would expect the downstream application to potentially process the data slightly later - unless it is also written in our low latency API (most are not).

If you are seeing 2-5 secs delays that is concerning and you should investigate with your internal market data team / network team and our TREP or Elektron Realtime support teams.

However, the apparent delay could be because you receive an Update which contains a field that has not actually changed since the previous update but has been included in the update for whatever reason. So, it may be that you had BID_TIME in a previous update a 2-3 seconds ago and the field + value is repeated in the most recent update even though it has not changed. Whilst the Elektron feed does generally not include an FID in an update unless it has changed there may be situations where this can happen.

When you are testing please log all the timestamps and when you do see a delay compare the value with previous values - to confirm it is indeed a unique field update. This data could also come in useful if you do need to investigate further with our support teams.

All comments

umer.nalla

Hi @nikita.ou

Not a TREP expert but I know that the TREP Performance documents explain their test methodology in considerable detail.

One example is the TREP 3.0.2 Performance results document e.g. a small extract:

For throughput testing, the sink_driven_src utility was used to generate update traffic, and the rmdstestclient utility was used to consume the updates....... The infrastructure was tuned for low latency and the publisher embeds timestamps into selected updates, which the subscriber uses for latency calculations. In this scenario, the publisher and subscriber must be running on the same node for accurate timestamps.

As you will note, having the consumer and provider on the same box ensures the timestamps are in sync.

You will need to create a MyRefinitiv login in order to download the above document.

UPDATE: There is also a link for a more recent Performance Document for the test done on more recent hardware.

nikita.ou

Hi Umer, thanks for the information. My question is more about what will be the proper tool that i can use to get the latency detail of the ticker update for a RIC. is rmdstestclient the right tool to use? I use the rmdstestclient to consume the realtime data of the data feed, and capture the ticker update. Then I do a manually calculation to get the latency of each RIC. But the result I got doesnt match with what downstream application saw.

Publisher and subscriber in the same node, does it mean to run the ads and the downstream app in the same box?

umer.nalla

Ji @nikita.ou

Apologies if I misunderstood your requirement. My take was that you were trying to measure the latency introduced by your TREP infrastructure as a tick traverses across the system - from the moment it is pushed out of the Elektron device to when it reaches the consumer. Using the method described above would have allowed publishing of dummy RICS with an embeded timestamp. By having the sink_driven_src(publisher) and rmdstestclient(consumer) on the same physical device you can ensure the time delta calculations are valid and not affected by clock differences between two devices.

If however, you are talking of the latency from when an exchange publishes an update to when it is received by a consumer at your site - IMHO there are too many other factors at play to arrive at a truly accurate latency measurement.

Please provide more details about exactly which latency measurement you are trying to calculate i.e from which start point to which endpoint.

However, assuming, you do wish to obtain some indicative or relative value, then a field such as BID_TIME would not be very accurate. You would be better off using an _MS or _NS field such as TIMACT_NS, BID_TIM_NS, QOUTIM_NS etc. which provide millisecond/nanosecond accuracy. However, these are not available for all RICs / exchanges etc.

You say you don't see the same result as what the downstream application sees. Is your rmdstestclient instance running on the same server as the downstream application? Does rmdstestclient show a greater latency that the other application or smaller latency? Please expand.

nikita.ou

Hi Umer,

Apologies. Latency might be not the right word to be used in here. But let's use it here for now. What I am trying to figure out is to see how long it will take for us to get the data update from the data provider.

I run the rmdstestclient in one server and connect to the ADS server to get data. The downstream application connects to the same ADS to get data too.

Below is an example of the data capture result I get by using rmdstestclient.

I minute 10:35:00.095 (data receive time) by 10:35:00:010 (BID_TIME). If the value is larger than 1 sec, it will be alert on our end.

I do see some data update has around 2~5 secs. But the downsteam application doest experience the latency. So it makes me to think, is rmdstestclient a good tool to monitor or calculate the latency.

nikita.ou

[Wed Apr 29 10:35:00.095] <updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="5" containerType="RSSL_DT_FIELD_LIST" flags="0x18 (RSSL_UPMF_HAS_MSG_KEY|RSSL_UPMF_HAS_SEQ_NUM)" updateType="1" seqNum="0" dataSize="96"> <key flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)" serviceId="4000" name="PCG." nameType="1"/></updateMsg>

BID_TIME: TIME 5 :[10:35:00:010]

BID_TIM_MS: UINT 4 :[38100010]

BIDSIZE : REAL 2 :[12]

BID : REAL 3 :[10.87]

BID_TONE: STRING 2 :[RA]

ASK_TIME: TIME 5 :[10:35:00:010]

ASK_TIM_MS: UINT 4 :[38100010]

ASKSIZE : REAL 2 :[1]

ASK : REAL 3 :[10.88]

ASK_TONE: STRING 2 :[RA]

TIMACT : TIME 2 :[14:35:00:000]

TIMACT_MS: UINT 4 :[52500000]

QUOTIM : TIME 5 :[10:35:00:010]

QUOTIM_MS: UINT 4 :[38100010]

umer.nalla

Hi @nikita.ou

The rmdstestclient tool is a highly performant one written using a low latency API UPA/ETA - that it is why we use it for our performance testing.

If you are seeing 2-5 secs delays that is concerning and you should investigate with your internal market data team / network team and our TREP or Elektron Realtime support teams.

EXPLORE OUR SITES